[JENKINS-47392] Audit mode for script security execution

As a user of script security and especially pipeline code, it is frustrating to have to run code multiple times to identify all cases where methods need whitelisting. 

Instead, I'd like to be able to run code ONCE in an "audit mode" that listens for script security violations and generates a list of methods that may be whitelist-approved to permit the script to run inside the sandbox.  Additionally, we should log the violations (either in the build log or to an audit file), and note any blacklist violations (which should not be eligible for whitelisting).

Technical note: because the code is Turing Complete and in the case of Groovy the method dispatch is complex, it's impossible to identify all methods that might be invoked before running.  Thus this is likely the best we'd be able to do.

---
Originally reported by svanoort, imported from: Audit mode for script security execution

• status: Open
  
• priority: Major
  
• component(s): script-security-plugin, workflow-cps-plugin
  
• resolution: Unresolved
  
• votes: 5
  
• watchers: 10
  
• imported: 2025-12-07
  

As a user of script security and especially pipeline code, it is frustrating to have to run code multiple times to identify all cases where methods need whitelisting. 


Instead, I'd like to be able to run code ONCE in an "audit mode" that listens for script security violations and generates a list of methods that may be whitelist-approved to permit the script to run inside the sandbox.  Additionally, we should log the violations (either in the build log or to an audit file), and note any blacklist violations (which should not be eligible for whitelisting).


Technical note: because the code is Turing Complete and in the case of Groovy the method dispatch is complex, it's impossible to identify all methods that might be invoked before running.  Thus this is likely the best we'd be able to do.


 

Start by reviewing the script-security-plugin and workflow-cps-plugin components referenced in the issue, focusing on how sandbox violations and blacklist decisions are currently handled. Define the audit mode's execution and logging behavior, including the distinction between whitelist candidates and blacklist violations; done means one run produces an actionable audit without requiring repeated executions.

Written by the indexing model from the issue text.