Technology Portfolio Management (TPM) Best Practices

Overview

A Software Bill of Materials is a formal, machine-readable record of all the open source and third-party software components that compose a software product or technology artifact, including both the components directly declared as dependencies and the transitive dependencies of those components. SBOM is a foundational governance artifact for open source governance: without it, the organization cannot know what open source components it is using, what licenses they carry, what security vulnerabilities they contain, or what supply chain risk they represent. SBOM has moved from a voluntary best practice to a regulatory requirement in several significant governance contexts: the EU Cyber Resilience Act mandates SBOM for products with digital elements sold in the EU market, and US Executive Order 14028 established requirements for SBOM in software sold to the US federal government. (Sources: EU Cyber Resilience Act; US Executive Order 14028, Improving the Nation’s Cybersecurity, 2021.)

Best Practice

Maintain a current Software Bill of Materials for every application, software product, and technology component that includes open source dependencies, integrating SBOM generation into the CI/CD pipeline as an automated step rather than as a periodic manual exercise. SBOM generation should capture: the package name, version, and license for every direct and transitive dependency; the relationships between components, distinguishing direct dependencies from transitive dependencies; the source repository and download location for each component; and the cryptographic hash of each component artifact to support integrity verification. Produce SBOMs in both SPDX and CycloneDX formats. SPDX is maintained by the Linux Foundation and CycloneDX is maintained by the OWASP Foundation; both are widely adopted SBOM standards and both are referenced in regulatory requirements and customer security assessments. (Sources: The Linux Foundation, SPDX Project; OWASP Foundation, CycloneDX Project.) Store SBOM artifacts in a governed repository that connects to the Open Source Components Inventory, enabling automated license compliance checking and vulnerability scanning against the SBOM data.

Benefit(s)

Automated, continuous SBOM generation and maintenance provides the component-level visibility that makes all other open source governance disciplines effective at scale. License compliance checking against SBOM data is automated rather than manual, covering the full transitive dependency tree rather than only the direct dependencies that developers typically declare consciously. Vulnerability scanning against SBOM data identifies affected components immediately upon vulnerability disclosure rather than requiring a manual discovery exercise for each new vulnerability. And the organization can respond to SBOM requests from customers, regulators, and security partners with current, accurate, machine-readable SBOM artifacts rather than manually assembled approximations.