Supply Chain Security¶
The supply-chain-security pack enforces rules based on SLSA, NIST SSDF, and CISA guidance for CI/CD pipeline hardening, dependency integrity, build provenance, and credential hygiene.
Enable¶
Rules¶
The pack includes 20 rules across code enforcement and documentation obligations:
Code rules (16)¶
| ID | Clause | Severity | Description |
|---|---|---|---|
| SCS-CI-001 | SLSA Build L2 | critical | Piping remote scripts directly into a shell bypasses integrity checks and enables supply chain attacks |
| SCS-CI-002 | SLSA Build L2 | critical | Piping wget output into a shell enables remote code execution without integrity verification |
| SCS-CI-003 | SLSA Build L3 | high | GitHub Actions referenced by mutable tag (e.g. @v3) can be silently replaced with malicious code |
| SCS-CI-004 | NIST SSDF PO.5.1 | high | Running CI jobs in privileged mode allows container escapes and host compromise |
| SCS-CI-005 | NIST SSDF PW.6.1 | critical | Hardcoded secrets in CI configuration files are exposed to anyone with repository access |
| SCS-CI-006 | NIST SSDF PW.7.2 | medium | Marking security scanning steps as allow_failure lets vulnerabilities pass undetected into production |
| SCS-DEP-001 | SLSA Source L2 | medium | Installing Python packages without version pins allows silent dependency substitution |
| SCS-DEP-002 | SLSA Source L2 | medium | npm install without a lockfile can resolve to different (potentially compromised) dependency versions |
| SCS-DEP-003 | SLSA Source L3 | high | Install commands with --extra-index-url are vulnerable to dependency confusion attacks |
| SCS-DEP-004 | SLSA Source L2 | high | Wildcard or latest version specifiers allow arbitrary dependency resolution |
| SCS-DEP-005 | SLSA Build L3 | high | Docker images without digest pinning can be silently replaced with compromised versions |
| SCS-BUILD-001 | SLSA Build L2 | high | Disabling package signature verification removes a critical supply chain integrity check |
| SCS-BUILD-002 | NIST SSDF PW.4.1 | medium | Disabling npm install scripts removes protection against malicious postinstall hooks |
| SCS-BUILD-003 | SLSA Build L2 | high | Dockerfile ADD with a URL downloads remote content without integrity verification |
| SCS-SEC-001 | NIST SSDF PW.6.1 | critical | Private keys committed to source control can be extracted by anyone with repository access |
| SCS-SEC-002 | NIST SSDF PW.6.1 | critical | AWS access keys in source code enable unauthorized access to cloud infrastructure |
| SCS-SEC-003 | NIST SSDF PW.6.1 | critical | GitHub tokens in source code allow repository manipulation and data exfiltration |
Documentation obligations (4)¶
| ID | Clause | Description |
|---|---|---|
| SCS-DOC-001 | EO 14028 Sec 4(e) | A Software Bill of Materials (SBOM) must be generated for every release to enable vulnerability tracking |
| SCS-DOC-002 | NIST SSDF PW.4.1 | New dependencies must be reviewed for license compatibility, maintenance status, and known vulnerabilities before adoption |
| SCS-DOC-003 | NIST SSDF RV.1.1 | A supply chain incident response plan must exist for compromised dependencies or build infrastructure |
| SCS-DOC-004 | SLSA Build L2 | Build artifacts must have verifiable provenance linking them to source code and build environment |
Use case¶
Any team shipping software through CI/CD pipelines. The pack provides:
- Pipeline hardening -- Catches curl-pipe-bash, unpinned GitHub Actions, privileged containers, hardcoded CI secrets, and bypassed security gates
- Dependency integrity -- Flags unpinned pip/npm installs, dependency confusion via extra-index-url, wildcard versions, and unverified Docker base images
- Credential hygiene -- Detects private keys, AWS access keys, and GitHub tokens committed to source control
- Compliance documentation -- SBOM generation, dependency review, incident response, and build provenance obligations appear in reports for auditors