Ryan Gutwein

Cybersecurity Leader & Visionary

3 minute read

Originally published on GoOptimal.io

Introduction

The software supply chain has transitioned from a niche security topic to executive-level priority remarkably quickly. Executive Order 14028, signed in May 2021, mandated that organizations selling software to the federal government must provide a Software Bill of Materials. However, creating an SBOM and using it effectively for risk reduction are distinct challenges. Nearly five years later, many organizations generate SBOMs purely for compliance purposes while failing to leverage them as operational security tools.

What the Executive Order Actually Requires

Executive Order 14028, titled “Improving the Nation’s Cybersecurity,” tasked NIST with establishing SBOM guidelines and software supply chain security standards. Key requirements include:

  • Minimum elements: Supplier name, component name, version, unique identifier, dependency relationships, SBOM author information, and timestamp
  • Machine-readable formats: SPDX and CycloneDX are the accepted standards
  • Frequency and delivery: SBOMs must accompany each new release or major update
  • Vulnerability disclosure: Suppliers must maintain vulnerability programs and correlate SBOM contents with CVEs upon request
  • Attestation: Software producers must attest to NIST Secure Software Development Framework (SSDF) conformity

A crucial distinction is that the executive order treats SBOMs not as static compliance documents, but as operational security tools. The intent enables agencies to ingest SBOMs, cross-reference vulnerabilities, and make informed procurement decisions.

The SBOM Generation Problem

Generating an SBOM involves significant challenges across different software ecosystems. The two dominant formats serve different purposes:

  • SPDX: Originated in open-source licensing, emphasizing license identification and provenance
  • CycloneDX: Purpose-built for security, with native vulnerability references and cryptographic hash support

Popular tools include syft, trivy, cdxgen, and Microsoft’s sbom-tool, each with different approaches:

  • Manifest-based tools: Fast but miss vendored dependencies and statically linked libraries
  • Binary analysis tools: Catch more components but run slower with higher false positives
  • Multi-language monorepos: Require different analysis strategies for Go, Python, npm, and container images

The practical recommendation is employing multiple tools simultaneously and merging outputs for comprehensive coverage.

Operationalizing Your SBOM Program

Four pillars support an effective SBOM program:

Integrate Generation into CI/CD Pipelines

SBOM generation should be automated within build pipelines, placed after dependency resolution but before artifact publication.

Automate Vulnerability Correlation

Cross-referencing SBOM components against vulnerability databases transforms the document into a security tool. Platforms like Dependency-Track enable continuous CVE matching against NVD, OSV, and vendor feeds. Configuration should suppress false positives and route critical findings to ticketing systems.

Track License Compliance

SBOMs contain license information for every component. Copyleft licenses like GPL-3.0 and AGPL can conflict with proprietary distribution models. Automated policy gates should flag restricted or unknown licenses before builds complete.

Monitor Dependency Drift Over Time

Comparing SBOMs across releases reveals unexpected component inventory changes. Drift detection identifies version jumps, unvetted new components, and reappearance of patched vulnerabilities — catching supply chain anomalies that vulnerability scanning alone might miss.

SBOM as a Living Document

The distinction between snapshot and continuously maintained SBOMs is the difference between compliance theater and actual security. Living SBOMs require:

  1. Artifact-to-deployment mapping: Correlate SBOMs with running instances through Kubernetes labels or deployment manifests
  2. Continuous re-evaluation: Re-assess stored SBOMs against updated vulnerability feeds daily
  3. VEX integration: Formally declare vulnerability exploitability status — whether vulnerabilities are “not affected,” “under investigation,” or “fixed”

Federal requirements increasingly demand VEX documents alongside SBOMs, particularly in defense and intelligence sectors.

Key Takeaway

SBOMs transcend compliance requirements when organizations integrate them throughout development and security operations, enabling continuous vulnerability tracking and supply chain visibility. The gap between generating JSON files and running mature SBOM programs spans tooling, CI/CD integration, vulnerability correlation, license enforcement, drift detection, and continuous evaluation.

Organizations should start with CI/CD integration, add vulnerability correlation, and expand from there. Those investing in SBOM operationalization now will be best positioned to respond when supply chain incidents demand immediate answers.

Updated:

You May Also Enjoy