Understanding SBOMs
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of software components and dependencies, along with their relationships. Much like a list of ingredients on food packaging, an SBOM provides transparency into what a piece of software contains.1
ARMOR/RED delivers complete SBOMs with every container image. Know exactly what runs in your infrastructure. Compare our hardened images against upstream sources. Achieve compliance, accelerate incident response, and eliminate blind spots in your software supply chain.
Why SBOMs Matter
SBOMs have emerged as a critical component of software supply chain security. They enable organizations to:
- Identify vulnerabilities rapidly: When a new CVE is published, organizations can immediately determine which of their systems contain the affected component, without manual investigation.
- Ensure license compliance: SBOMs document the licenses of all included components, enabling legal and compliance teams to verify adherence to licensing requirements.
- Enable incident response: During a security incident, SBOMs provide the information needed to assess exposure and prioritize remediation.
- Meet regulatory requirements: Executive Order 14028 (2021) requires SBOMs for software sold to the U.S. federal government, and similar regulations are emerging globally.
SBOM Formats
Three primary formats have emerged as industry standards for representing SBOMs.
SPDX (Software Package Data Exchange)
SPDX is an open standard developed by the Linux Foundation since 2010. It became an ISO/IEC international standard (ISO/IEC 5962:2021) in 2021, making it the first SBOM format to achieve this recognition.2
Key characteristics:
- Machine and human-readable formats (JSON, RDF, YAML, tag-value)
- Strong emphasis on license information and compliance
- Comprehensive license list maintained by the SPDX Legal Team
- Widely adopted in open source communities
CycloneDX
CycloneDX is a lightweight SBOM standard developed by OWASP and standardized by Ecma International (TC54). It was designed specifically for security use cases and has grown to support multiple types of bill of materials.3
Key characteristics:
- Supports 260+ tools across 20+ programming languages
- Multiple BOM types: SBOM, HBOM (Hardware), SaaSBOM, CBOM (Cryptography), and AI/ML BOM
- Native support for vulnerability information (VEX)
- Extensive tooling ecosystem for container environments
- Used by governments, medical device manufacturers, and defense industries
SWID Tags (Software Identification)
SWID Tags are defined by ISO/IEC 19770-2:2015 and focus on software asset management. They follow a lifecycle model where tags are added during installation and removed during uninstallation.4
Key characteristics:
- Designed for enterprise software asset management
- Integration with NIST National Vulnerability Database (NVD)
- Supports patch management and compliance verification
- Complements rather than replaces SPDX and CycloneDX
Vulnerability Detection with SBOMs
One of the most powerful applications of SBOMs is rapid vulnerability detection across entire software ecosystems.
How It Works
- Component Inventory: The SBOM provides a complete list of components with their versions, package URLs (purls), and checksums.
- CVE Correlation: Security tools cross-reference these components against vulnerability databases (NVD, OSV, vendor advisories).
- Transitive Analysis: Because SBOMs capture dependency relationships, vulnerabilities in deeply nested dependencies are identified.
- Ecosystem Scanning: Organizations can scan their entire portfolio of applications in minutes rather than days.
VEX (Vulnerability Exploitability eXchange)
VEX is a companion specification that provides attestations about whether a product is affected by a specific vulnerability. This reduces false positives by allowing vendors to declare that a vulnerability in a component is not exploitable in their specific implementation.1
Scanning Tools
Several open source tools enable SBOM-based vulnerability scanning:
- Syft: Generates SBOMs from container images and filesystems
- Grype: Vulnerability scanner that consumes SBOMs
- Trivy: All-in-one security scanner with SBOM support
Practical Usage
Generating an SBOM from a Container Image
Using Syft to generate SBOMs in different formats:
Scanning an SBOM for Vulnerabilities
Using Grype to scan an existing SBOM:
Extracting SBOM from OCI Images
Many registries now support attaching SBOMs directly to images:
ARMOR/RED and SBOMs
ARMOR/RED provides SBOMs with each container image, enabling users to understand exactly what components are included in both hardened and locked variants.
What We Provide
Each ARMOR/RED image includes:
- Hardened/Locked SBOM: The complete bill of materials for the ARMOR/RED image, documenting all components after hardening modifications.
- Upstream SBOM: The bill of materials for the original upstream image, enabling direct comparison of what changed during the hardening process.
This dual-SBOM approach provides transparency into the hardening process and allows security teams to audit the modifications made to upstream images.
Comparing SBOMs
By comparing the hardened SBOM against the upstream SBOM, users can identify:
- Components removed during hardening (attack surface reduction)
- Components updated or patched
- Configuration changes affecting the software inventory
- License implications of any modifications
References
CISA. "Software Bill of Materials." https://www.cisa.gov/sbom
Linux Foundation. "SPDX Specification." https://spdx.dev/about/
OWASP Foundation. "CycloneDX." https://cyclonedx.org/
NIST. "Software Identification (SWID)." https://csrc.nist.gov/projects/Software-Identification-SWID