Software Bill of Materials (SBOM)

SBOM lists what's in your software.

Generate

A Software Bill of Materials (SBOM) lists every dependency that goes into a software artifact: direct dependencies, transitive dependencies, version pins, license information. It is the equivalent of an ingredients label for software. SBOMs went from "nice to have" to "required" in the past few years as supply-chain attacks (SolarWinds, Log4Shell) showed how few organizations could answer "do we use the affected package, and where?"

What SBOM generation looks like in practice:

• Generated at build time.: The SBOM is produced as part of the artifact build. Every container image, every package, every binary has a corresponding SBOM that lists what is inside it. The SBOM is a build output alongside the artifact, not a separate manual artifact.
• Multi-format support.: The two dominant formats are SPDX (Linux Foundation, broader scope) and CycloneDX (OWASP, security-focused). Most tools can produce both. Customers and regulators may specify; producing both keeps options open.
• Standard tools available.: Syft (Anchore), cdxgen, npm sbom, pip-audit with sbom output, Microsoft sbom-tool, GitHub's dependency export. The tooling is mature and free. There is no excuse in 2026 for not having SBOMs.
• Per-language depth.: Each language has its own dependency manager (npm, pip, Maven, Cargo, Go modules) and its own SBOM tooling. The build pipeline runs the appropriate tool per language. Polyglot artifacts produce SBOMs that combine multiple language ecosystems.
• Signed and attached.: The SBOM is signed by the build process (sigstore, GPG) and attached to the artifact (OCI artifact attachments for containers, package metadata for libraries). The signature proves the SBOM came from your build, not from a tampered source.

SBOM generation is configuration work, not custom development. Most teams can adopt it within a sprint. The hardest part is integrating SBOMs into the existing build pipeline; the easiest is using one of the standard tools.

Scan

An SBOM that sits in storage and is never read provides no security value. The point of SBOMs is to enable continuous vulnerability scanning: when a new CVE is published, you can immediately query whether you use the affected package and where. Without SBOMs, that question takes hours or days to answer; with them, it takes seconds.

• SBOM scanned daily for new CVEs.: The vulnerability database (NVD, OSV, GitHub Advisory Database) updates continuously as new CVEs are disclosed. The scanner runs daily against every SBOM in the inventory and flags any artifact that contains a newly-vulnerable dependency.
• Continuous coverage.: The scan is automatic and runs without intervention. The team learns about Log4Shell-class issues within hours, not days. Speed matters because attackers also have access to the CVE feed and start exploiting within hours of disclosure.
• Per-environment scanning.: Production artifacts get scanned with the highest priority. Staging next. Dev last. The scan results are surfaced per environment so the team knows whether the vulnerable artifact is actually serving customer traffic or just sitting in dev.
• Severity-based response.: Critical CVEs get paged; high CVEs get a ticket within 24 hours; medium and low get added to the backlog. The response cadence matches the severity. Treating every CVE as urgent desensitizes the team; treating none as urgent misses the real ones.
• Remediation tracking.: Each flagged CVE gets a remediation ticket with an owner and an SLA based on severity. The ticket closes when the dependency is upgraded or the artifact is rebuilt. The cycle is closed-loop; nothing falls through.

Daily SBOM scanning is the operational discipline that makes SBOMs valuable. Teams that generate SBOMs and never scan them are checking a box; teams that scan continuously catch the next supply-chain incident before it lands.

Share

SBOMs are also increasingly required to be shared with customers and regulators. The federal government's Executive Order 14028 mandated SBOMs for software sold to federal agencies; the EU Cyber Resilience Act expanded the requirement to consumer products. The trend is clear: SBOMs are becoming required artifacts, not optional ones.

• Customers may require SBOMs.: Enterprise procurement increasingly asks for SBOMs as part of vendor due diligence. The customer's security team wants to verify the dependency tree they are about to take on. Vendors who can produce SBOMs win procurement decisions; vendors who cannot lose them.
• Regulators increasingly demand them.: Federal contracting (US), Cyber Resilience Act (EU), various sector-specific rules (medical devices, critical infrastructure). The regulatory landscape is moving toward "SBOM required" as the default. Companies that prepare now will not need to scramble when the requirement applies to them.
• Compliance frameworks expect them.: SOC 2, ISO 27001, and PCI DSS increasingly reference supply-chain controls that SBOMs directly satisfy. The certification process goes faster when SBOMs are routinely produced and available.
• Customer-shareable form.: The SBOM you share with a customer may be different from the internal one. Strip internal-only metadata; redact license-sensitive information if needed; produce in the format the customer wants. The discipline is having a process to produce sanitized SBOMs on request.
• Public for open-source projects.: If you publish open-source software, the SBOM should be public alongside the release. Downstream users can verify the dependency tree without contacting you. This is the convention for serious open-source projects in 2026.

SBOMs are the supply-chain transparency artifact that the industry has converged on. Nova AI Ops integrates with SBOM generation tools, runs continuous CVE scanning across the SBOM inventory, and surfaces the cases where a newly-disclosed vulnerability affects production artifacts so the security team can respond at the speed the threat requires.