Software supply chain · DEP · v1.0.0 · draft
Third-party package dependencies
How an organization consumes open source and third-party packages from language ecosystems: where packages come from, how long a new release waits before use, how installs are locked and verified, how new dependencies are vetted, and how vulnerable or malicious packages are found and handled. Tool-neutral: each control describes the expected state, not a product.
Current state of the main branch, drafts included. Not released yet.
01
Controls
| ID | Control | Severity | Assessment | Profiles |
|---|---|---|---|---|
CB-DEP-AGE-001 | Wait a minimum age before installing a new package version draftPackage versions can be installed minutes after they are published | high | partial | baseline |
CB-DEP-AGE-002 | Wait a minimum age before adopting a new package draftPackages that appeared on the registry days ago can be added as dependencies | medium | partial | hardened |
CB-DEP-AGE-003 | Grant release-age exceptions explicitly and for a limited time draftThe release-age rule is bypassed without trace or without end date | low | manual | baseline |
CB-DEP-CI-001 | Install dependencies in a step without secrets draftDependencies are installed in an environment that holds secrets | high | partial | baseline |
CB-DEP-CI-002 | Use read-only registry credentials in pipelines draftPipelines hold registry credentials that can publish packages | high | partial | baseline |
CB-DEP-CI-003 | Limit network access of builds to approved registries draftBuild environments can reach any host on the internet | medium | partial | hardened |
CB-DEP-CI-004 | Separate dependency caches by trust level draftUntrusted builds can write to caches used by trusted builds | medium | partial | baseline |
CB-DEP-EXEC-001 | Block install-time scripts except for an allowlist draftAny dependency can run code when it is installed | high | partial | baseline |
CB-DEP-EXEC-002 | Prefer prebuilt packages over packages built from source at install draftInstalling a dependency runs its build code on the machine | medium | partial | hardened |
CB-DEP-EXEC-003 | Do not run on-demand packages without a pinned version draftScripts and pipelines download and run the latest version of a package | medium | partial | baseline |
CB-DEP-INV-001 | Produce and keep an SBOM for every release draftReleases have no record of the components they contain | medium | partial | baseline |
CB-DEP-INV-002 | Know where any package version is used within a set time draftThe organization cannot quickly tell which systems use a given package | medium | manual | baseline |
CB-DEP-INV-003 | Verify provenance and signatures when the ecosystem provides them draftPublished provenance and signatures of packages are ignored | medium | partial | hardened |
CB-DEP-IR-001 | Have a response procedure for compromised dependencies draftThere is no plan for when a malicious dependency has been installed | high | manual | baseline |
CB-DEP-LOCK-001 | Commit a lockfile for every deployable application draftApplications are built without a lockfile | high | partial | baseline |
CB-DEP-LOCK-002 | Install from the lockfile without modifying it in builds draftBuilds may resolve versions different from the lockfile | high | partial | baseline |
CB-DEP-LOCK-003 | Verify package integrity against recorded hashes draftDownloaded packages are not checked against a known hash | high | partial | baseline |
CB-DEP-LOCK-004 | Allow only approved sources in lockfiles draftA lockfile change can introduce packages from an unexpected source | medium | partial | baseline |
CB-DEP-LOCK-005 | Pin direct dependencies of applications to exact versions draftApplication manifests use version ranges | low | partial | hardened |
CB-DEP-SRC-001 | Resolve all packages through an organization-controlled registry draftPackages are downloaded directly from public registries | medium | partial | baseline |
CB-DEP-SRC-002 | Bind internal package namespaces to the private registry draftInternal package names can be resolved from a public registry | high | partial | baseline |
CB-DEP-SRC-003 | Reserve internal package names on public registries draftInternal package names are free to register on public registries | medium | manual | hardened |
CB-DEP-SRC-004 | Declare dependencies only from a registry draftDependencies are pulled from direct URLs, source repositories or local paths | medium | partial | baseline |
CB-DEP-SRC-005 | Use authenticated, encrypted transport to registries draftPackages are downloaded without TLS or without certificate verification | high | partial | baseline |
CB-DEP-SRC-006 | Keep package manager configuration in the repository draftPackage manager behaviour depends on each machine's local settings | low | partial | baseline |
CB-DEP-UPD-001 | Propose dependency updates automatically draftDependencies are only updated by hand, when someone remembers | medium | partial | baseline |
CB-DEP-UPD-002 | Require human review for risky updates draftRisky dependency updates are merged automatically | medium | partial | baseline |
CB-DEP-UPD-003 | Do not fall more than a set number of major versions behind draftDependencies are several major versions behind their current release | low | partial | baseline |
CB-DEP-VET-001 | Review every new direct dependency before merge draftNew dependencies can be added without review | medium | partial | baseline |
CB-DEP-VET-002 | Evaluate new dependencies against written criteria draftDependencies are chosen without any trust evaluation | medium | manual | baseline |
CB-DEP-VET-003 | Remove unused dependencies draftThe project declares dependencies it does not use | low | partial | baseline |
CB-DEP-VET-004 | Ship only production dependencies draftDevelopment and test dependencies are installed in production artifacts | low | partial | baseline |
CB-DEP-VULN-001 | Scan dependencies for known vulnerabilities continuously draftKnown vulnerabilities in dependencies are not detected | high | partial | baseline |
CB-DEP-VULN-002 | Block packages known to be malicious draftPackages flagged as malicious can still be installed | critical | partial | baseline |
CB-DEP-VULN-003 | Fix vulnerable dependencies within set deadlines draftVulnerable dependencies stay in production indefinitely | high | manual | baseline |
CB-DEP-VULN-004 | Track unmaintained, deprecated and end-of-life components draftThe product depends on components that no longer receive fixes | medium | partial | baseline |
No control matches these filters.
02
Profiles
- Baseline
baseline - What every team consuming third-party packages should do. Low friction. 30 controls.
- Hardened
hardened - For critical or exposed software, and teams that publish software others depend on. Adds review and isolation overhead. Extends
baseline: applies every one of its controls too. 36 controls.
03
Domains
- Sources & registries
CB-DEP-SRC-NNN - 6 controls.
- Release age & quarantine
CB-DEP-AGE-NNN - 3 controls.
- Locking & integrity
CB-DEP-LOCK-NNN - 5 controls.
- Install-time execution
CB-DEP-EXEC-NNN - 3 controls.
- Dependency vetting
CB-DEP-VET-NNN - 4 controls.
- Vulnerabilities & malicious packages
CB-DEP-VULN-NNN - 4 controls.
- Updates
CB-DEP-UPD-NNN - 3 controls.
- Inventory & provenance
CB-DEP-INV-NNN - 3 controls.
- Build environment
CB-DEP-CI-NNN - 4 controls.
- Incident response
CB-DEP-IR-NNN - 1 controls.
04
Versions
A release is the git tag dependencies/v<version>: a zip with the controls, their translations, bundle.json and index.json.
05
Written from
- NIST SP 800-218 - Secure Software Development Framework (SSDF) 1.1 NIST, standard
- SLSA specification v1.0 OpenSSF, standard
- Secure Supply Chain Consumption Framework (S2C2F) OpenSSF, guide
- Package Manager Best Practices OpenSSF, guide
- OWASP Top 10 CI/CD Security Risks OWASP, guide
Maintained by Alice. Content under CC BY 4.0, _standard.yml.