An SBOM can tell you which software components a producer says are in a particular build, their versions and relationships when that data is supplied. An SBOM alone cannot tell you whether an attacker can exploit a vulnerability in your application. That decision needs a reliable component match, current advisory, evidence about the built and deployed product, the affected code and its inputs, and the controls around that path. A rich SBOM may link to vulnerability analysis or a VEX statement, but those are additional claims to assess, not a substitute for evidence. If the inventory is incomplete or stale, even the starting component list needs qualification.
The NTIA minimum-elements report defines an SBOM as a formal record of components and supply-chain relationships. Its full report explains that vulnerability information changes over time and is best linked to, rather than assumed permanently complete inside, an SBOM. This makes an SBOM useful for finding where to investigate after an advisory. It does not make it an application exploit test.
A component list answers the first question
Imagine receiving an alert that a widely used parser has a new CVE. A current SBOM can help the team ask, “Which of our products include this parser?” That is an important starting question, especially across multiple applications or suppliers. It is distinct from these later questions:
| Decision question | SBOM contribution | Additional evidence needed |
|---|---|---|
| Is the component listed in this build? | Name, version, supplier, dependency relationship, if captured accurately | Generation method, artifact identity, completeness and freshness. |
| Does the advisory apply? | Candidate package and version for matching | Authoritative affected range, platform/configuration conditions, package identity. |
| Is vulnerable code in what ships? | May identify the upstream component or linked artifact | Build, binary or source evidence for the actual delivered product. |
| Can an attacker reach the vulnerable behavior? | Usually no application call path or input-control proof | Actor, entry point, controls, calls, runtime configuration and effect. |
| Has the risk been removed? | A later SBOM may show a changed component | Verified fix, release artifact and deployment evidence; regression or path review as appropriate. |
The OWASP dependency graph and SBOM guidance distinguishes the inventory from a graph of how components depend on one another. The graph can help an analyst locate the parent dependency or service. It still does not decide whether a user-controlled request reaches the vulnerable function. “Dependency present,” “vulnerable version present,” “affected product” and “demonstrably exploitable” are different statements.
A CTO's customer statement changes when the artifacts arrive
Synthetic assurance case: Northstar's customer asks whether fictional advisory DEMO-ADV-31 affects its document service. The sales draft says, “Our latest SBOM is clean.” Engineering supplies two inventories: yesterday's document-service build lists fixed archive-reader 7.1.2, while an invoice-worker SBOM from six months ago lists affected 7.1.0. The current running artifact map is missing.
The first decision is to withhold the universal assurance, not to claim both services are exploitable. The fresh SBOM describes an available build. The old SBOM records the producer's component claim for an earlier build; historical deployment still needs its own artifact mapping. Neither identifies every current process serving the customer.
At the next checkpoint, the fictional evidence packet resolves the contradiction:
| Evidence | What it now establishes | What remains outside it |
|---|---|---|
| Running document-service inventory | Two instances use the new fixed artifact; one old instance still serves the customer's region | Vulnerable-function invocation on the old instance |
| Fresh worker inventory | Current worker no longer contains archive-reader | Other packages or historical exposure |
| Route review | Old document-service artifact can receive customer archives; advisory prerequisite is still being checked | Confirmed exploitability or an observed incident |
| Release plan | Owner can finish rollout and verify old-instance termination today | Completion has not happened yet |
The evidence reverses the apparent reassurance: the fresh build was not fully deployed, while the stale worker inventory overstated current presence. The CTO now has an operational decision and a customer communication decision.
The operational decision is to complete and verify the document-service rollout, assess whether archive admission should be restricted meanwhile, and keep the historical/path investigation distinct. The customer statement at this checkpoint is:
Our current inventory identifies one remaining older document-service instance containing the affected package version in the assessed region. The current invoice worker does not contain that package. We are completing the document-service rollout and checking the advisory's application-specific conditions. We have not established exploitation. We will provide a deployment-confirmed update at the stated checkpoint.
Use a real checkpoint agreed with the response owner; this example invents no response-time promise. The statement is neither a proof of compromise nor a claim of safety. It gives the customer a meaningful action and boundary.
After the example's final inventory shows only fixed document-service artifacts and termination of the old instance, the updated statement can say the affected package version is no longer present in the assessed running document-service artifacts. It should preserve that historical exposure and exploitation review are separate. “Fixed in the current deployment” does not retroactively mean “never affected.”
Approve claims individually
A CTO can make the assurance decision with a short claim register:
| Proposed claim | Approve at inventory checkpoint? | Evidence needed to change it |
|---|---|---|
| Latest build contains fixed package | Yes, for the exact SBOM subject | Preserve artifact binding |
| Entire customer region runs the fix | No; older instance remains | Final running inventory and old-instance termination |
| Current invoice worker contains affected package | No; old SBOM was stale | Current worker artifact inventory supports correction |
| No customer data was exposed | No; not established by package inventory | Separate incident evidence adequate for that conclusion |
This is the executive job an SBOM cannot do by itself: decide which sentence the company can responsibly stand behind, which operational work changes it, and when the customer will hear the next supported update.
Use a three-stage decision path
First, validate the inventory. Ask the platform or release owner which artifact and revision the SBOM describes, when and how it was generated, which components were excluded, and whether supplier-provided parts are represented. A build SBOM, a source-tree inventory and a deployed image inventory may legitimately differ. A signature can establish who signed particular inventory bytes; it does not establish that the producer found every component or that this is the artifact currently running. Preserve those differences. If the component is absent from one SBOM, check completeness and generation scope before treating absence as proof that it is absent from the product.
Second, establish advisory applicability. The security engineer maps the exact package identity and resolved version to the publisher's affected range and conditions. A name collision across ecosystems or a broad product match can mislead. If a product supplier provides a VEX status, review the product/version it names and the supporting reason. CISA's VEX status-justification guidance describes reasons such as vulnerable code not present or not in the execution path, and explains that these are author assertions a consumer may decide whether to accept. An unexplained “not affected” badge should not silently resolve the question.
Third, decide the response for this application. Ask an engineer to trace the relevant input through entry, controls and vulnerable operation at a pinned revision. Ask the release owner whether that revision and configuration are deployed. If the path is supported, prioritize patching or mitigation by likely impact, exposure and practical difficulty. If the path is defeated by evidence, state the exact reason and scope. If a decisive fact is missing, keep it under investigation and set a check deadline. NIST's patch management guide includes verification after installation; a new SBOM or merged dependency PR alone does not prove the production fix is live.
Decide what the inventory justifies spending time on
An SBOM becomes operationally useful when it helps direct a finite investigation. In Northstar's case, the stale worker inventory and incomplete document-service rollout create different tasks. The release team can resolve the running-artifact map, while the security engineer checks the parser advisory's conditions. Asking both teams to “clear the SBOM” conceals those responsibilities and encourages a document update to substitute for a deployment change.
A practical order is to establish which customer-facing product is under discussion, locate its current artifact records, then examine the component candidates within those artifacts. Where deployment evidence is delayed, the team can still prepare a compatible update or restrict a credible exposure. The inventory gap should remain visible until resolved, but it should not force all useful work to stop. The CTO's job is to remove the operational bottleneck and select the business response, not to invent missing technical certainty.
Suppliers introduce another branch. A supplier may provide an SBOM for a broad appliance image while the organization runs only one optional feature. The component list helps locate a candidate; the supplier's product-specific analysis may explain whether the vulnerable behavior is included or enabled. Ask for the exact product version, configuration conditions and basis of the assertion. If those conditions do not match the installed product, retain the question. Do not require a supplier to disclose all private source simply because an inventory cannot answer a runtime question; seek evidence proportionate to the claim and purchasing decision.
Also distinguish a usable inventory from a complete one. An SBOM that identifies the affected document parser can support immediate patch planning even if another component family is missing. The missing family limits broader assurance and deserves correction. It does not erase the useful positive observation. This prevents two opposite mistakes: treating one incomplete inventory as worthless, or treating its useful rows as proof of comprehensive coverage.
For recurring reporting, track the product-to-artifact mapping and unresolved inventory gaps separately from vulnerability counts. A fall in advisory matches after regenerating an SBOM might reflect a real version change, a renamed component, or reduced inventory scope. Ask which explanation the release evidence supports before reporting improvement. The desired outcome is a reliable chain from customer product to running artifact to component decision. The SBOM supplies an important part of that chain; the organization still owns the interpretation and the action.
What a CTO should request from the team
For each materially relevant advisory, ask for a one-page record with product and deployed revision; SBOM origin and date; exact component and advisory match; affected input path or reason it is blocked; unresolved assumptions; owner; next decision date; and proof of fix when completed. Keep technical evidence in the restricted engineering record if it contains sensitive source or exploitation detail. The executive summary should explain the possible customer or business effect in plain language and avoid claiming an executed exploit from source inspection.
The decision is not binary when the evidence is partial. It is reasonable to restrict a feature or accelerate a patch while applicability is still being checked, especially when potential harm is substantial. Describe that as precautionary risk reduction. It is also reasonable to reject a specific alert when a reviewed, necessary control or absent vulnerable code defeats the claimed path for the named build. Preserve the reason, because a later version or configuration can change it.
Ask your release owner to attach the current SBOM to one deployed product and fill the five-row table above for one active advisory. For the component inventory work, read how to read an SBOM and find the components that matter. For the application-path decision, use how to explain CVE reachability without promising safety.