Security

If you have found a security vulnerability in SCons, you can report it by emailing to [email protected].

However, before you report something, it may be useful to understand some things about the SCons security model.

The TL;DR version is: build scripts are code and need to be treated accordingly.

Think of SCons as a specialized Python interpreter for build recipes. The build is not data-driven (as from static json or xml files), but code, executed when you run SCons. You should apply the same trust considerations as with any other interpreted code you might run.

A good security scanner might surface a number of possible concerns:

• use of exec() / eval(), because it means code is being executed from data.
• site_scons loading means extra code on disk can affect the build.
• Saved Variables files being executed means configuration is not purely data.

These concerns are entirely valid from the viewpoint of a scanner, which cannot know whether the data entering at these points is trusted or not. However, these are not hidden vulnerabilities, but intentionally designed features: SConstruct/SConscript are executed as Python in order to make the power of a full programming language available to the build recipes; site_scons is a plugin/extension mechanism that allows adding project-specific code without modifying SCons itself; and Variables files can contain not only Python assignments but also run code when additional setup is deired. Building safely means enforcing a trust boundary with the data inside.

In typical usage, SCons runs locally on a developer's machine or in a controlled CI/CD environment. It is not a network-facing service where an unauthenticated attacker can "inject" code.

SCons operation is not sandboxed. That would be very tricky, since, as a build tool, its entire purpose is to manipulate files and execute processes, typical things sandboxing protects against. However, SCons only does those things on behalf of your own user identity, and never itself asks to escalate privilege. Be extremely wary of (a) instructions which tell you to run scons escalated ("sudo scons", for example), and (b) running external commands that do privilege escalation. If you don't fully trust a build, run it isolated (e.g. in a container).

Note that these concerns aren't unique to SCons: many build systems are designed with similar capabilities and thus have similar concerns.

Here are some suggested safety practices:

• Review SConstruct / SConscript / site_scons before building code from unknown sources
• Prefer builds from repositories or vendors you trust
• Use isolated environments or containers for untrusted builds
• Take care when using and external (rather than project-controlled) site_scons
• Avoid exposing secrets or write-access to sensitive host data during build

The final item might need a bit of elaboration: the scope of SCons is primarily to track sources and their dependencies as well as derived targets, and turn the former into the latter as needed. While it is convenient to include additional steps around a build project such as fetching the sources from an external location, installing the results, or pushing a build artifact to a remote host, those operations all may involve the use of "secrets" that SCons is not specifically designed to manage safely, such as privilege escalation to copy files and data to system-scoped locations, ssh keys or API tokens to push/pull data across the network, etc. Extra care should be taken with such operations. Don't store secrets in the project.