Your Jenkins instance runs untrusted pipeline scripts from multiple organizations. A junior DevOps engineer disabled the Groovy sandbox globally after hitting "unapproved method" errors. Your security team flags this as a critical vulnerability. How do you re-enable sandbox security without breaking existing pipelines?
Re-enable the sandbox via Manage Jenkins > Script Security > "Enable" toggle. For breaking pipelines, whitelist required methods through Script Approval console or script security exemption list. Use `@NonCPS` annotations for approved script blocks. For large-scale remediation: enable audit logging, identify failing calls via logs, then create a Script Security exemption policy. Alternatively, enforce pipeline validation through a shared library that pre-validates scripts before execution. This ensures security without disruption.
Follow-up: A Jenkinsfile uses `new java.io.File()` which is blocked by sandbox. Your team can't modify the script. What's your solution without disabling sandbox?
Your pipeline fails with "Scripts not permitted to use method java.lang.ProcessBuilder.start()". The script needs to execute shell commands dynamically for deployment automation. You need this approved without undermining security posture.
Use the `sh` step instead: `sh 'command'` is a whitelisted wrapper around ProcessBuilder. If the script must use ProcessBuilder directly, approve it via Manage Jenkins > In-process Script Approval. But best practice: refactor to use Pipeline DSL steps (sh, bat, etc.) which are pre-approved and audited. For legacy scripts requiring direct Java API access, create a custom shared library function that wraps the call and gets code-reviewed before approval. This maintains security while enabling functionality.
Follow-up: How would you implement a centralized approval policy for your entire organization's Jenkins fleet?
You're migrating to a hardened Jenkins with strict sandbox enabled. Auditing existing pipelines reveals 47 scripts with unapproved method calls. Manually approving each is unsustainable. Design a solution.
Export script approvals via Jenkins Script Console: `Jenkins.instance.getExtensionList(ScriptApprovalLink.class)`. Analyze patterns of calls, then create a shared library with pre-approved wrapper functions for common operations. Migrate pipelines to use the library incrementally. Run parallel environment: production with strict sandbox, staging with audit logging but no blocking. This identifies missing approvals before production. Use Jenkins Configuration as Code (JCasC) to export approved scripts in code, enabling version control and propagation across instances.
Follow-up: How do you prevent malicious actors from escalating privileges through the Script Approval console?
A developer's Jenkinsfile imports a third-party Groovy library that uses reflection to bypass sandbox restrictions. Your audit detects this during code review. What's your security response?
Reject the Jenkinsfile immediately. Implement a pre-commit hook that scans for reflection APIs (java.lang.reflect, ProxyGenerator, ExpandoMetaClass). Block pipeline execution with clear error message. For approved use cases, create a whitelist entry in Script Security. Use GroovyShell restrictions: disable ExpandoMetaClass, enforce method lookups. Implement a Plugin Metadata Library Analysis (PMLA) phase that statically analyzes all library imports before execution. Log and alert on all reflection attempts. Consider mandating that third-party libraries provide sandbox-compatible versions or implement equivalent functionality using only approved APIs.
Follow-up: Design an automated scanning pipeline to detect sandbox bypass attempts across all Jenkinsfiles in your Git repos.
Your Jenkins runs on a multi-tenant architecture where teams can create their own pipelines. Team A's script triggers a resource exhaustion attack via infinite loop in a sandbox-allowed operation. How do you prevent this?
Sandbox alone doesn't prevent resource exhaustion. Implement: (1) Timeout guards: wrap all script executions with timeout limits via `timeout(time: 30, unit: 'MINUTES')`. (2) Parallel step limits: restrict concurrent pipeline stages. (3) Queue throttling: limit jobs per team via job queue plugins. (4) Resource quotas: use Kubernetes agents with CPU/memory limits. (5) Groovy AST transformation to inject timeout checks into compiled scripts. (6) Monitor CPU/memory during pipeline runs; auto-kill runaway builds. For multi-tenant: enforce resource isolation at infrastructure level (container limits), not just script level.
Follow-up: How do you distinguish between legitimate long-running builds and resource exhaustion attacks?
You inherit a Jenkins instance with sandbox enabled, but no approved methods listed. Pipelines fail with vague sandbox errors. Users complain they can't see what's actually blocked. Build a debugging strategy.
Enable verbose sandbox logging: set log level for org.jenkinsci.plugins.scriptsecurity to DEBUG. Capture full method signatures being blocked. In Script Console, query approvals: `Jenkins.instance.getExtensionList('com.cloudbees.jenkins.plugins.kubernetes.credentials.ParamValueExpander')`. Use Jenkins UI > In-process Script Approval to view pending approvals. Create a test job that runs isolated scripts to safely test sandbox behavior. Export audit logs: `JENKINS_HOME/logs/sandbox-audit.log`. Use Job DSL or Groovy console to programmatically query what's allowed: `Jenkins.instance.extensionList.get(ScriptApprovalEngine)`. Communicate findings to teams with clear "approved methods" documentation.
Follow-up: How would you create a runbook for your team to safely request new method approvals?
A production pipeline runs with @Grab annotations to download external Groovy libraries. Your security team wants to audit and control all external dependencies. How do you enforce this?
The @Grab annotation bypasses dependency management and can pull untrusted code. Implement: (1) Disable @Grab globally if not needed. (2) If required, whitelist specific artifacts via pom.xml or Artifactory. (3) Use Jenkins Shared Libraries instead of @Grab—they're version-controlled and reviewed. (4) Implement proxy caching via Artifactory/Nexus; block external repos. (5) Use AST transformation to intercept @Grab calls and log them. (6) In JCasC, disable experimental groovy runtime features that support @Grab. (7) Audit all downloads: monitor network calls for external library pulls. Best practice: entirely replace @Grab with explicit shared library imports and dependency declaration.
Follow-up: How do you handle legacy pipelines that legitimately need dynamic library loading?
You're implementing a zero-trust security model for Jenkins. Sandbox restrictions alone are insufficient. Design a defense-in-depth approach for Groovy script execution.
Layer 1 - Sandbox & Approval: Enable sandbox, implement strict script approval, whitelist only necessary methods. Layer 2 - Shared Libraries: Enforce all scripts use pre-reviewed shared libraries; disallow direct Jenkinsfile script blocks. Layer 3 - AST Analysis: Static code analysis on all pipelines pre-execution; reject scripts with suspicious patterns. Layer 4 - Runtime Monitoring: Execute scripts in Kubernetes pods with CPU/memory limits; monitor system calls. Layer 5 - Audit & Compliance: Log all approvals, track execution, alert on policy violations. Layer 6 - Access Control: Role-based access for Script Approval console; require multi-approval for sensitive approvals. Implement Jenkins Configuration as Code to codify all security policies and version-control them.
Follow-up: How do you detect a compromised admin account attempting to approve malicious scripts?