SBOM — Software Bill of Materials Vocabulary

SBOM (US Executive Order 14028 mandated for federal software): a structured list of all software components (direct and transitive dependencies), their versions, licenses, and supplier information. Enables: vulnerability management (which products are affected by CVE-X?), license compliance (are we using GPL code in a proprietary product?), and supply chain risk assessment.

SPDX (Linux Foundation, ISO/IEC 5962): comprehensive standard covering licenses, copyrights, and component relationships. CycloneDX (OWASP): security-focused SBOM standard optimized for vulnerability management, integrations with CVE databases, and DevSecOps tooling. Many tools support both formats. US CISA recommends either.

Transitive dependency risk: when Log4Shell (CVE-2021-44228) was disclosed, many organizations did not know they were vulnerable because Log4j was a transitive dependency — not something they directly imported. An SBOM reveals transitive dependencies, enabling rapid impact assessment when a new vulnerability is disclosed.

Dependency confusion attack (Alex Birsan, 2021): if your code depends on an internal package named company-auth, an attacker publishes a public package with the same name. Package managers that prefer public registries will download the malicious version. Mitigations: private package registry with scoped namespaces, dependency pinning, registry verification in CI.

Software provenance (SLSA Framework): 'who built this artifact, when, from which source commit, using which build platform?' Provenance attestations (signed metadata) allow consumers to verify the artifact they are running matches the source code they audited. Key for preventing the SolarWinds-type attack where build infrastructure was compromised.