Comment by jmyeet

This particular vulnerability relied upon passing the require function to a scope to allow the loading and running of arbitrary code. This is what I tend to call a blacklist approach. You're saying in this sandbox certain features can't be used because they will allow escape.

The alternative is a whitelist approach. Instead of disallowing dangerous features you're enabling only the features you need.

So a build system like Gradle or Maven (same thing really) has a limited set of primitives it is allowing access to. It's not loading, say, the entire JVM and all the Java core libraries and then listing all those you can't use.

You see the difference? If nothing else, the blacklist approach is going to fail when the virtual machine (or whatever) adds a new API call upstream and it's added without intent to the sandbox by simply doing an update where nobody has thought to disable it.

Another way of looking at this is Gradle isn't being compiled into Java bytecode and run in the same environment as the IDE (sandboxed or otherwise). That is inherently riskier.