SBOM (Software Bill of Materials)
The machine-readable inventory of software components, dependencies, and provenance data now required for federal contracts and increasingly demanded across critical infrastructure sectors.
A Software Bill of Materials (SBOM) is a formal, machine-readable record of the components, libraries, and modules that make up a software product, along with their relationships and provenance. The two dominant SBOM formats are SPDX (Software Package Data Exchange, ISO/IEC 5962:2021) and CycloneDX (OWASP, currently version 1.6). NTIA's 2021 minimum elements specification defines the baseline data fields required for a valid SBOM: supplier name, component name, component version, component unique identifier, dependency relationships, SBOM author, and SBOM timestamp. EO 14028 and OMB M-22-18 made SBOM delivery a contractual requirement for software sold to the US federal government. CISA's SBOM sharing and consumption guidance (2023) extended minimum elements to include known vulnerabilities (via VEX — Vulnerability Exploitability eXchange) and software lifecycle status.
Generating SBOMs in a modern engineering environment requires integrating multiple toolchain components. Source composition analysis (SCA) tools — Syft, FOSSA, Snyk, Black Duck — scan source code and build artifacts to enumerate direct and transitive dependencies. Container SBOM generation (using tools like Syft or Trivy with SBOM output mode) captures the OS package layer, language runtime layer, and application dependency layer separately. For compiled binaries without source access (commercial off-the-shelf components, firmware), binary analysis tools perform component extraction. The complete SBOM for a containerized microservice application typically has three layers: the container base image SBOM, the application dependency SBOM, and the infrastructure-as-code dependency SBOM — all of which must be linked into a system-level SBOM hierarchy.
SBOM utility extends beyond compliance into operational security. When a new CVE is published — for example, Log4Shell (CVE-2021-44228) — organizations with current SBOMs can query their inventory to identify affected components within hours rather than days of manual scanning. This requires an SBOM management platform (e.g., Dependency-Track, GUAC — Graph for Understanding Artifact Composition) that ingests SBOMs, maintains a vulnerability database feed, and generates prioritized remediation queues. The emerging VEX standard allows software publishers to assert that a known vulnerability is "not exploitable" in their specific product configuration, reducing false-positive alert noise. FDA's September 2023 cybersecurity guidance for medical devices under the Consolidated Appropriations Act 2023 Section 3305 also mandates pre-market SBOM submission, extending SBOM requirements into healthcare.
We integrate SBOM generation into every stage of the CI/CD pipeline — generating SBOMs at build time, attesting them with Sigstore/cosign for cryptographic provenance, and publishing them to a centralized SBOM management platform. We implement VEX workflows to reduce CVE alert noise and build automated SBOM delivery pipelines that satisfy federal contract deliverable requirements in both SPDX and CycloneDX formats.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.