Re: Groovy sandboxing

Sandboxing has been an on-going and evolving landscape. With the
removal of the Security Manager, Oracle's position is to run your code
in a container, which will be a good option for many folks, but we
could look at other options. Here is some of the history:

- **Champeau, "Customizing the Groovy compilation process," 12 May
2011** =E2=80=94 the 1.8 origin:
https://melix.github.io/blog/2011/05/12/customizing_groovy_compilation_proc=
ess.html
- **Kawaguchi, "Groovy SecureASTCustomizer is harmful," 27 Apr 2012**
=E2=80=94 https://kohsuke.org/2012/04/27/groovy-secureastcustomizer-is-harm=
ful/
- **Kawaguchi, "POTD: Groovy Sandbox," 29 Apr 2012** =E2=80=94
https://kohsuke.org/2012/04/29/potd-groovy-sandbox/
- **Champeau, "Improved sandboxing of Groovy scripts," 27 Mar 2015** =E2=80=
=94
the author disowning it for security:
https://melix.github.io/blog/2015/03/sandboxing.html
- **jenkinsci/groovy-sandbox** =E2=80=94
https://github.com/jenkinsci/groovy-sandbox ; Script Security plugin =E2=80=
=94
https://github.com/jenkinsci/script-security-plugin
- **Jenkins sandbox-bypass advisories** =E2=80=94 2019-01-08, 2019-03-06,
2019-09-12, 2020-02-12 (CVE-2020-2110/`@Grab`), 2022-10-19 (implicit
casts), 2026-06-24 (`extensions=3D`). Index:
https://www.jenkins.io/security/advisories/
- **JEP 411** (deprecate SM, JDK 17) https://openjdk.org/jeps/411 =C2=B7
**JEP 486** (permanently disable, JDK 24) https://openjdk.org/jeps/486
=C2=B7 Oracle summary:
https://docs.oracle.com/en/java/javase/24/security/security-manager-is-perm=
anently-disabled.html
- **GraalVM sandboxing** =E2=80=94
https://www.graalvm.org/latest/security-guide/sandboxing/
- **Real-world denylist bypass, Apache OFBiz OFBIZ-12571** =E2=80=94
https://lists.apache.org/thread/zcxxb9tsyx60t3h2pmngv5dt6n5gj0g4

We spoke with the Jenkins folks several times in the past about
potentially upstreaming some of their sandboxing technology. Their
feeling was that even if Groovy implemented something along those
lines, they would still have to "close the gap" between where general
sandboxing finished and the parts needed for their specific domain
began; this wouldn't really save them much effort. But these days with
AI, maybe it is worth exploring again.

Cheers, Paul.

On Sun, Aug 2, 2026 at 7:34=E2=80=AFAM ski n <[email protected]> wro=
te:
>
> Groovy has always been a powerful scripting language. Now with agents (fo=
r example created with Spring AI or Langchain4j) it's becoming
> more common to run Groovy scripts from for example Java or Kotlin.
>
> The question is when third-party generated scripts from agents (or just a=
 script written by other developers)
> run these scripts, how to run it safely and securely? For example by not =
giving it access to the file system, socket or environment.
>
> I recently read the documentation of GraalVM on sandboxing:
>
> https://www.graalvm.org/latest/security-guide/sandboxing/
>
> There you can have guest code (JavaScript, Python, Wasm etc) that is a sa=
ndbox when started from the JVM/GraalVM. This works because guest languages
> run in a separate VM, truffle VM, where these restriction policies can be=
 applied.
>
> Groovy as being a JVM language itself, runs natively on the JVM, and is v=
ery much integrated with other JVM languages such as Java. Historically the=
re have been several approaches to run Groovy restrictly such as:
>
> SecureASTCustomizer
> custom classloaders
> SecurityManager (now removed from Java)
> bytecode rewriting
> custom compilation restrictions
>
> Unfortunately, after the removal of the Java Security Manager, there is n=
o robust, built-in JVM mechanism for securely sandboxing arbitrary Groovy c=
ode.
>
> Are there any plans to allow strong sandboxing for Groovy embedded in ano=
ther JVM Language?
>
> Raymond