Software Bill of Materials or dependency tree reviewed
Why it matters
Without an SBOM, you cannot answer the question 'are we affected?' when a new CVE is announced for a transitive dependency. OWASP A08 (Software and Data Integrity Failures) and NIST 800-53 SA-10 require that organizations track and control the software components they use. SLSA L1 requires provenance; CycloneDX SBOM is the standard artifact format. License violations in transitive dependencies — a GPL-licensed package pulled in silently — can also create legal liability that only SBOM review surfaces. Projects with 45+ direct npm dependencies commonly have 500+ transitive dependencies with no systematic review.
Severity rationale
Info because SBOM absence is a process gap rather than an immediate technical vulnerability, but it means CVE exposure and license risks in transitive dependencies go undetected.
Remediation
Generate a CycloneDX SBOM and check license compliance in CI:
# Generate SBOM
npx @cyclonedx/cyclonedx-npm --output-format JSON > sbom.json
# License compliance check
npx license-checker --summary --failOn 'GPL-2.0;GPL-3.0;AGPL-3.0'
Add to .github/workflows/sbom.yml:
- name: Generate SBOM
run: npx @cyclonedx/cyclonedx-npm --output-format JSON > sbom.json
- name: License check
run: npx license-checker --failOn 'GPL-3.0;AGPL-3.0' --excludePrivatePackages
Commit sbom.json to the repository or store it as a CI artifact so it is available for vulnerability correlation when new CVEs are published.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Hardening Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- owasp:2021 · A08 — Software and Data Integrity Failures
- nist:rev5 · SA-10 — Developer Configuration Management
- slsa:1.0 · L1 — Provenance exists
- cyclonedx · SBOM — Software Bill of Materials
- soc2:2017 · CC7.1 — Detection and monitoring of configuration changes and vulnerabilities
- soc2:2017 · CC9 — Risk mitigation
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-hardening·automated
- 2026-07-06·v1.0.1·Add SOC 2 TSC mapping (CC7.1, CC9) from the verified compliance crosswalk register (docs/compliance/).·by soc2-mapping-enrichment-ship-2