Consuming Open Source Software
Consuming open source is an engineering and risk process, not a download. This domain tests intake decisions: how you evaluate a component before adoption, how you track it afterwards, and how you respond when a vulnerability lands.
Evaluation before adoption
Check the license and its obligations, release cadence and time-to-fix for past CVEs, the number of active maintainers (bus factor), issue and pull-request responsiveness, test coverage and CI, and whether signed releases and checksums exist. OpenSSF Scorecard automates several of these signals, including Branch-Protection, Pinned-Dependencies, Signed-Releases, Maintained, and Dangerous-Workflow.
Tracking after adoption
- Generate an SBOM per build in SPDX or CycloneDX so transitive dependencies are visible, not just direct ones.
- Resolve versions through lockfiles, but remember that pinning is not patching: you still need a working upgrade route.
- Verify provenance with signed artifacts (Sigstore/cosign, GPG), published checksums, and SLSA provenance levels.
- Scan continuously against CVE, GHSA, and NVD data, triaging with EPSS or reachability analysis rather than a base CVSS score alone.
Worked example
A scanner flags a critical remote-code-execution CVE in a transitive dependency four levels deep. The direct dependency's maintainer has not responded in months. Confirm the vulnerable function is reachable from your code, look for a patched fork or a fixed release of the direct dependency, and if neither exists force the fixed version through a registry override or a local patch. Record the override in the SBOM and risk register, assign an owner, set a review date, and re-run the license review if you swap components.
Traps
- Scanning direct dependencies only.
- Trusting CVSS without exploitability or reachability context.
- Clearing direct licenses while ignoring transitive packages.
- Accepting an abandoned package because it "still works."