Software Supply Chain Security: What an SBOM Buys You in an Audit

An auditor asks what's running in production. The honest answer, for most early-stage teams, is "let me check with engineering and get back to you." That gap, between what you're actually running and what you can document on demand, is what software supply chain security comes down to during a first audit.

A software bill of materials, or SBOM, is a machine-readable inventory of every third-party and open-source component in a piece of software: the libraries, packages, and modules it's built from, with version and origin attached. Neither SOC 2 nor PCI DSS names "SBOM" by name, but both have criteria that assume you can produce exactly this.

SOC 2's CC7.1 and CC7.2 require detection and monitoring for new vulnerabilities. PCI DSS 4.0.1's Requirement 6.3.2 requires a maintained inventory of bespoke, custom, and third-party software components. An SBOM is how you satisfy both without inventing a new process for each.

By the end of this, you'll know exactly what an SBOM is, which specific SOC 2 and PCI DSS criteria it satisfies, what a usable one actually contains, and how to generate one without a dedicated supply-chain security team. Here's what's ahead:

• What an SBOM actually is, and how it differs from a vulnerability scan
• Why this matters the first time an auditor asks for it
• The exact SOC 2 and PCI DSS criteria an SBOM satisfies, with control IDs
• What belongs in one, and which formats auditors actually accept
• How to generate one without a platform-engineering budget
• What an audit like this actually reveals, and the mistakes that undermine it

Software bill of materials compliance isn't a separate certification you pursue. It's evidence that satisfies requirements two frameworks already have.

Software Supply Chain Security 101: What an SBOM Actually Is

An SBOM is a structured list of every component that makes up a piece of software: every open-source library, every third-party package, every internal module, each with its version and where it came from. Think of it as an ingredient list for your codebase, one specific enough that a machine, not just a person, can read and query it.

This is the foundation software supply chain security is actually built on. You can't secure, patch, or monitor a dependency you don't know you have. A team that's never generated one usually discovers this the hard way: a new CVE gets disclosed for a popular logging library, and the honest first question, "do we even use this?", takes half a day to answer instead of thirty seconds.

SBOM vs. Vulnerability Scan vs. Dependency List

Three artifacts get used interchangeably in conversation and shouldn't be, since an auditor treats each one differently:

A package.json or requirements.txt file is not an SBOM. It only shows direct dependencies, not the transitive ones pulled in underneath them, and it carries none of the version-pinning, integrity, or build-provenance detail an SBOM format requires.

Why Software Supply Chain Security Gets Tested the First Time an Auditor Asks

An auditor testing a vulnerability-management or change-management criterion needs to know what's running before they can test whether you're actually monitoring it. That's not a formality. It's the starting condition for the rest of the test.

Picture the scenario: you're three weeks into fieldwork, and the auditor asks for a current inventory of the software components running in your production environment. If the honest answer is a spreadsheet last touched two quarters ago, or "let me check with engineering," that's a finding, not a delay. It tells the auditor your monitoring process has a gap at its foundation.

Without a usable software component inventory audit trail, three things happen, in roughly this order: the test scope narrows to what you can actually document, the auditor requests remediation before the report gets issued, and the whole engagement runs longer than it needed to. None of that is a technicality. It's the direct cost of not having the answer ready.

SBOM SOC 2 and SBOM PCI DSS: The Exact Criteria an SBOM Satisfies

Neither SOC 2 nor PCI DSS uses the word "SBOM." Both have criteria an SBOM is accepted as evidence for, and knowing the exact ones matters more than a general "auditors like this" claim.

This is sbom soc 2 and sbom pci dss compliance in the most literal sense: one artifact, generated once per build, that satisfies an inventory requirement three separate frameworks already have, worded three different ways. Software bill of materials compliance, in practice, means treating the SBOM as the single source of truth each of those requirements points back to, rather than maintaining three separate spreadsheets that inevitably drift apart.

Source: SecurityMetrics' guide to PCI DSS 4.0.1's new requirements confirms Requirement 6.3.2's mandatory-inventory scope; AuditFront's CC7.1 implementation guide confirms the asset-inventory foundation SOC 2's detection and monitoring criteria assume.

What Belongs In a Software Component Inventory Audit

A usable SBOM needs more than a list of names. What a credible one actually contains:

• Component identity and version — the exact package and version, not "roughly the latest 2.x release"
• Dependency relationships — both direct dependencies your team chose and the transitive ones pulled in underneath them
• Licensing metadata — what license governs each component, since this is a legal question as much as a security one
• Integrity markers — a cryptographic hash confirming the component you inventoried is the component actually running
• Build traceability — where and how the component was produced, so a question about provenance has an answer

SPDX vs. CycloneDX

Two formats cover nearly every real-world SBOM: SPDX (a Linux Foundation standard, stronger on license-compliance detail) and CycloneDX (an OWASP standard, built with security and vulnerability analysis as the primary use case). Both are machine-readable, both are accepted as audit evidence, and picking between them mostly comes down to which use case you'll lean on more, license tracking or vulnerability correlation, not which one is "more official."

SBOM Tools for Compliance: Generating One Without a Dedicated Team

You don't need a platform-engineering team to start. The sbom tools for compliance that actually matter are the ones tied directly to your build, not a separate manual process:

1. Pick a generator tied to your build process. A container/binary-focused scanner for anything shipped as an image, or ecosystem-native tooling (pip-audit for Python, npm sbom for Node) for anything shipped as source.
2. Generate on every build, not as a one-time exercise. An SBOM produced once for an audit and never regenerated is a snapshot of a moment that's already passed by the time anyone reads it.
3. Store it somewhere versioned and queryable. A PDF buried in a shared drive defeats the entire point of a machine-readable format.
4. Feed it into a vulnerability scanner that consumes SBOMs directly, rather than one that re-discovers your dependencies from scratch every time it runs.

These are the sbom tools for compliance that earn their place: tied to the build pipeline, run automatically, and feeding a system that consumes their output. Dependency vulnerability management compliance only works when the SBOM and the scanner reading it are wired together this way; a general software-supply-chain-security product bought and never connected to the pipeline doesn't do any of that on its own.

What a Software Supply Chain Security Audit Actually Reveals

A software supply chain security audit, done properly, surfaces gaps that a policy document alone never would: dependencies nobody on the team currently owns, components that show up in the SBOM but were never actually risk-assessed, and the space between the policy ("we track our dependencies") and the practice (the SBOM on file is four months out of date).

Each of those gaps is sbom audit evidence in its own right, not just a finding to fix quietly. An auditor treats a stale SBOM differently from a current one, and treats a component nobody owns differently from one with a named accountable engineer.

A credible SBOM looks boring: current, queryable, and tied to an actual build. A compliance-theater one looks impressive and was generated exactly once, the week before the audit started. — Upendra Varma, CTO at ComplyJet

How ComplyJet Fits Into Your Software Supply Chain Security Program

ComplyJet doesn't generate SBOMs itself. Its Vulnerability Management product picks up where an SBOM-fed scanner leaves off: it integrates directly with the scanners most teams already run, Snyk, AWS Inspector, Dependabot, and Wiz, pulling findings automatically with no manual imports or CSV uploads.

From there, it tracks each finding against a severity-based remediation deadline your team defines (critical in 7 days, high in 30, for example), links findings to the specific compliance controls they affect, and surfaces open vulnerabilities in your risk register automatically. For an auditor, the output is a full scan history, every scan, every finding, every remediation action, every closure date, sitting in one place as audit-ready evidence across SOC 2, ISO 27001, and PCI DSS.

That's the piece of software supply chain security most early-stage teams under-build: not the SBOM itself, but what happens to the findings it feeds after generation.

Here's what that looked like for a team whose vulnerability data was already flowing in, just not scoped correctly yet:

For teams already automating other parts of the pipeline, ComplyJet's help center covers how vulnerability scan sources like Dependabot feed into this tracking directly:

Common Software Supply Chain Security Mistakes That Undermine SBOM Audit Evidence

Each mistake below traces back to treating the SBOM as a document instead of a process:

• Generating an SBOM once, for the audit, and never again. It's out of date by the time anyone reads it a second time.
• Listing direct dependencies only. Transitive dependencies, the ones pulled in underneath what you actually chose, are usually where the risk actually lives.
• No owner assigned to review new components as they're added. An inventory nobody's accountable for drifts the same way an unowned spreadsheet does.
• Treating an SBOM and a vulnerability scan as the same artifact. One tells you what's there; the other tells you what's wrong with it. Auditors ask for both, separately.
• Picking a format nobody downstream can actually consume. An SBOM your vulnerability scanner can't ingest is a document, not a working part of the pipeline.
• Storing it as a PDF instead of a queryable, machine-readable file. This defeats the entire point of a machine-readable bill of materials.
• Treating dependency vulnerability management compliance as a one-time project. It's an ongoing loop tied to the SBOM, not a checklist item closed out before the audit and forgotten after.

FAQs

What is an SBOM?

A software bill of materials is a structured, machine-readable inventory of every component, open-source library, third-party package, or internal module, that makes up a piece of software, along with its version and origin. It's the ingredient list for your codebase.

How does an SBOM help with a SOC 2 audit?

SOC 2's CC7.1 and CC7.2 require detection and monitoring procedures for new vulnerabilities and configuration changes, both of which depend on knowing what's actually running. An SBOM is the inventory those criteria assume exists, even though SOC 2 never uses the word "SBOM" itself.

Do auditors ask for a software bill of materials?

They usually ask for what an SBOM provides, a current component inventory, without necessarily calling it an SBOM by name. Being able to produce one directly, instead of reconstructing an answer during fieldwork, is what separates a smooth request from a multi-day delay.

What should an SBOM include?

Component identity and version, dependency relationships including transitive dependencies, licensing metadata, integrity markers like cryptographic hashes, and build traceability. A dependency list alone, like a package.json file, is missing most of this.

Is an SBOM required for PCI DSS compliance?

PCI DSS doesn't mandate the term "SBOM," but Requirement 6.3.2 in PCI DSS 4.0.1 requires a maintained inventory of bespoke, custom, and third-party software components, which an SBOM satisfies directly.

How do I generate an SBOM?

Pick a generator tied to your build process, a container/binary scanner or ecosystem-native tooling depending on how you ship, generate it on every build rather than once, store it somewhere versioned and queryable, and feed it into a vulnerability scanner that consumes SBOMs directly.

What's the difference between an SBOM and a vulnerability scan?

An SBOM tells you what components exist in your software. A vulnerability scan tells you which of those components have known issues right now. You need the inventory first for the scan to be complete, since you can't flag a vulnerability in a component you never inventoried.

Related Reading

• Compliance as Code: Baking SOC 2 Controls Into Your CI/CD Pipeline, for the broader CI/CD pipeline story this article's SBOM piece plugs into.
• SOC 2 Audit Process, Start to Finish, for where vulnerability and change-management evidence fits into the overall audit timeline.
• PCI DSS Compliance Requirements: All 12, Explained, for the full requirement context Requirement 6.3/11.3 sit inside.