Sandbox and supply chain

Security topics

This page summarizes execution isolation for code review and SIGMA's supply chain model for package-backed submissions. For architecture-wide trust boundaries, see Verification and trust boundaries and Assembly and reputation.

Sandbox isolation

When SIGMA executes submitted code, the execution environment enforces the following isolation properties:

Network isolation. The execution container has no internet connectivity. Code that attempts an outbound network connection encounters an immediate failure, which is intercepted and logged. This prevents data exfiltration and prevents the code from downloading additional payloads during the test.

Filesystem isolation. The container filesystem is read-only. The code can only write to a small in-memory temporary directory. It cannot modify the host filesystem.

Privilege isolation. The container runs as a non-privileged user. All Linux capabilities are explicitly dropped. Privilege escalation is blocked at the kernel level.

Resource limits. The container is subject to hard memory, CPU, and process count limits. A memory hog cannot exhaust the server. A fork bomb is contained before it reaches the process table limit.

Execution timeout. If the code does not exit within 30 seconds, the container is forcibly terminated. The submission is not blocked; the council proceeds with the static analysis data and records that execution timed out.

Complete cleanup. After every execution, the container and its built image are deleted. Nothing persists between submissions.

More context: Code review (Senior sandbox), Backend routes and workers.

Supply chain model

A code certificate that only covers the developer's own files does not cover what executes on the user's machine. Modern Python and Node.js projects run code from dozens of third-party packages that the developer imported. SIGMA's supply chain model addresses this.

For CODE+PACKAGES submissions, SIGMA certifies each direct dependency independently. Packages are fetched from official public registries, their distribution files are integrity-verified by comparing the downloaded SHA256 against the registry's published value, and their source code is reviewed by a SIGMA council. Package certificates are stored in the shared Package Trust Registry and reused for all future submissions that include the same package at the same version.

The submission certificate includes a complete package manifest: every direct dependency, its certification status, its security level, and any council-retained warnings. SIGMA also tracks transitive dependencies up to L3, keeps parent attribution, and shows which transitive packages were certified, flagged, or left uncertified because of the transitive audit cap.

A blocked package affects submissions differently depending on depth. A blocked direct dependency or L1 transitive blocks the submission before code execution begins. A blocked L2/L3 transitive is surfaced to the council as a warning rather than an automatic blocker, so depth and developer context can still be considered.

See also: Dependency requirements, Code certificate structure.