Summary
Dependency curation protects the organisation from open-source supply chain risk by enforcing automated, policy-driven governance on every open-source package before it enters development, build, or production use across the SDLC, much like a firewall.
Description
Open-source and third-party packages are fetched continuously during development and CI — from public registries (npm, PyPI, Maven Central, RubyGems, NuGet, crates.io, and others), private feeds, and cached remote repositories. Without curationcontrolling at the point of acquisition, malicious, tampered, vulnerable, or non-compliant packages can enter the estate before later controls (SBOM generation, vulnerability scanning, deployment gates) ever run.
Dependency curation is the practice of controlling which package versions may be downloaded or resolved, evaluated against security and compliance policies at fetch time, and blocked or substituted before they are used in the SDLC. It operates as pre-download OSS governance: the first line of defense in the software supply chain timeline, distinct from post-build scanning or runtime detection.
A curation process SHOULD cover all paths by which open-source dependencies enter the organisation, including developer workstations and IDEs, CI/CD dependency resolution, and organisation-managed binary and package repositories. Policies SHOULD be expressed in terms that security and legal teams can own (severity thresholds, license deny lists, allowlists, malicious-package blocks, immaturity or deprecation rules) while remaining enforceable automatically for developers.
Curation complements Component Inventory (what is actually shipped) and Vulnerability Scanning - Dependencies (known CVEs in code already in the pipeline). Curation reduces the chance that compromised or policy-violating packages enter the graph in the first place and help reduce fix effort that increase as release process progresses; inventory and scanning remain necessary for transitive visibility, drift, and newly disclosed vulnerabilities.
Requirements
- The organisation MUST define and maintain curation policies for open-source packages used in the SDLC, covering at minimum: known malicious or compromised packages, severity-based vulnerability thresholds, license compliance, and criteria for unapproved or restricted packages.
- Curation policies MUST be enforced automatically at package acquisition for all supported ecosystems and entry points used by the organisation (developer pulls, CI resolution, and organisation-managed package repositories), not solely by periodic manual review.
- Package repositories that proxy public or third-party registries MUST be connected to the curation control plane so that policy evaluation occurs before packages are cached or consumed downstream.
- Curation decisions MUST be logged and retained in accordance with the organisation’s audit and record-retention requirements.
Examples & Commentary
- Pre-download vs post-build: Blocking a typosquatted or malicious npm package at the remote repository prevents every developer and pipeline from caching it; relying only on a weekly SCA scan on
mainleaves a window where the package is already in lock files and build caches. - License governance: A policy that blocks copyleft or unknown-license packages at download prevents legal review debt and last-minute release blocks; pair with component inventory SBOMs for attestation of what shipped.
- Developer experience: Integrate curation signals into CLI and IDE workflows so developers see policy outcomes at resolution time rather than only at failed pipeline stages.
- Relationship to deployment gating: Curation at acquisition does not replace Deployment Gating or provenance controls; it narrows what can enter the supply chain graph that those later controls must trust.
Links
- NIST SP 800-53r5 SR-3: Supply Chain Controls and Processes
- NIST SP 800-53r5 SR-11: Component Authenticity
- NIST SSDF SP 800-218 (PO.3)
- OWASP SCVS (Guidance: Open Source Policy)