What is Software Bill of Materials (SBOM)

Software supply chain attacks increased 742% between 2019 and 2022, according to Sonatype's State of the Software Supply Chain report. Organizations now manage applications containing hundreds of open-source components, each potentially introducing security vulnerabilities or compliance risks.

SBOMs emerged as the standard mechanism for documenting software composition. Much like ingredient labels on food products, SBOMs list every component within an application—from major frameworks to minor utilities. This transparency enables security teams to rapidly identify affected systems when new vulnerabilities emerge and helps legal teams track license obligations across the software portfolio.

For GRC analysts managing third-party risk, SBOMs represent a fundamental shift from trust-based to evidence-based vendor assessment. Rather than accepting vendor attestations about security practices, you can analyze the actual components within their software and cross-reference them against vulnerability databases and license requirements.

Core Components of an SBOM

An SBOM contains seven minimum data fields as defined by the NTIA (National Telecommunications and Information Administration):

1. Supplier Name - Entity that created the component
2. Component Name - Designation assigned by the supplier
3. Version String - Identifier to specify a specific release
4. Other Unique Identifiers - PURL, SWID, or other tracking IDs
5. Dependency Relationship - How components relate to each other
6. Author of SBOM Data - Who compiled this SBOM entry
7. Timestamp - When the SBOM record was created

SBOM Formats and Standards

Three primary formats dominate SBOM implementation:

SPDX (Software Package Data Exchange)

• ISO/IEC 5962:2021 international standard
• Maintained by Linux Foundation
• Supports JSON, YAML, RDF/XML, and tag-value formats
• Includes extensive license expression syntax

CycloneDX

• OWASP project focused on security use cases
• Native support for vulnerability tracking
• Includes hardware bill of materials (HBOM) extensions
• Preferred by security tool vendors

SWID (Software Identification Tags)

• ISO/IEC 19770-2:2015 standard
• XML-based format
• Built into Windows and supported by major software vendors
• Primarily used for software asset management

Regulatory Requirements and Framework Alignment

U.S. Federal Requirements

Executive Order 14028 (May 2021) established SBOM requirements for federal software suppliers. NIST's Secure Software Development Framework (SSDF) incorporates SBOM generation in practice PW.4.1: "Create and maintain provenance data for all components of each software release."

The FDA's medical device cybersecurity guidance (April 2022) requires manufacturers to provide:

• Software bill of materials including open-source software
• Support timeline for each component
• End-of-support dates for included software

International Standards

The EU Cyber Resilience Act (expected 2024) will mandate SBOMs for software products sold in European markets. Article 10 requires manufacturers to "identify and document vulnerabilities and components contained in the product."

ISO 27001:2022 control 8.30 (Outsourced development) aligns with SBOM practices by requiring organizations to "direct, monitor and review the activities related to outsourced system development."

Practical Implementation in Vendor Risk Management

Initial Vendor Assessment

Request SBOMs during the RFP process. Vendors unable to provide SBOMs likely lack mature DevSecOps practices. Analyze provided SBOMs for:

• Component age: Libraries over 24 months old indicate poor maintenance
• License mix: GPL components in proprietary software create legal risk
• Dependency depth: Deep dependency trees increase attack surface
• Known vulnerabilities: Cross-reference with NVD and vendor advisories

Ongoing Monitoring

Integrate SBOM analysis into your continuous monitoring program:

1. Vulnerability Correlation: When CVEs emerge (like Log4Shell), query your SBOM repository to identify affected vendors within hours instead of weeks
2. License Compliance: Track copyleft licenses that might create intellectual property obligations
3. Component Lifecycle: Monitor for end-of-life components requiring migration
4. Supply Chain Mapping: Build dependency graphs showing critical component suppliers

Control Mapping Examples

Framework	Control	SBOM Application
SOC 2 CC7.1	System monitoring	Monitor components for vulnerabilities
ISO 27001:2022 8.30	Outsourced development	Verify third-party code composition
NIST CSF ID.AM-2	Software inventory	Maintain component-level inventory
PCI DSS 12.3.1	Vendor management	Assess vendor software security

Common Misconceptions

"SBOMs are only for software vendors" False. Any organization using third-party software benefits from SBOM analysis. Even if you're not developing software, understanding your vendors' software composition reduces supply chain risk.

"SBOMs expose proprietary information" SBOMs list components, not source code. Most components are open-source libraries already public. Proprietary components can use identifiers without revealing implementation details.

"Generating SBOMs is too complex" Modern CI/CD pipelines generate SBOMs automatically. Tools like Syft, SPDX-sbom-generator, and CycloneDX generators integrate with existing build processes.

Industry-Specific Considerations

Financial Services

Regulators increasingly expect granular software inventory. The OCC's Third-Party Risk Management guidance emphasizes understanding "concentration risks" — impossible without component-level visibility SBOMs provide.

Healthcare

Beyond FDA requirements, HIPAA Security Rule 45 CFR 164.308(a)(8) requires tracking information system components. SBOMs satisfy this requirement while enabling rapid response to medical device vulnerabilities.

Critical Infrastructure

CISA's Software Bill of Materials guidance specifically addresses critical infrastructure sectors. Water, energy, and transportation systems must track industrial control system (ICS) components where vulnerabilities can cause physical harm.

Frequently Asked Questions

How detailed should an SBOM be?

Include all distributed components down to individual libraries. The NTIA baseline requires "all software components that the supplier has knowledge of" — generally interpreted as anything the build process touches.

Can SBOMs replace traditional vendor security questionnaires?

SBOMs complement but don't replace questionnaires. They provide objective component data while questionnaires assess processes, controls, and organizational maturity.

What's the difference between SBOM and software composition analysis (SCA)?

SBOMs are the standardized output format. SCA tools analyze code to generate SBOMs and provide additional vulnerability and license analysis.

How often should vendors update their SBOMs?

At minimum, with each software release. Critical applications warrant monthly updates even without releases to capture newly discovered vulnerabilities in existing components.

Do SBOMs apply to SaaS applications?

Yes. While you don't receive the software directly, SaaS vendors should provide SBOMs to demonstrate security practices and enable rapid vulnerability response.

How do I verify SBOM accuracy?

Cross-reference with multiple sources: vendor attestations, penetration test results, and independent SCA scans. Discrepancies indicate incomplete SBOMs or shadow IT within the vendor's development process.

What tools can consume and analyze SBOMs?

SBOM analysis tools include OWASP Dependency-Track, Anchore Grype, Microsoft SBOM Tool, and commercial platforms like Snyk, Sonatype, and Black Duck.