An SBOM tells you what a software inventory reports about components and their relationships. A risk decision also needs a reliable match to the shipped artifact, a relevant vulnerability advisory, the conditions that make the issue applicable, and evidence about your actual use. Record a response, an owner, and a condition for reviewing the decision again.
A dependency match is a reason to investigate. It is neither automatic proof of exploitability nor permission to dismiss the finding because nobody has reproduced an attack.
Anchor the inventory to the artifact
Start with the release you actually run. Record its immutable identity, the SBOM's producer and generation time, and the scope of collection. An inventory generated from source dependencies may answer a different question from one generated from the final container or installer.
CycloneDX's SBOM overview describes components, versions, dependencies, and relationships as inventory information. The format's ability to represent those details does not prove that a particular generator found every dependency in your artifact.
For an application that downloads plugins after startup, a build-time inventory may omit the runtime additions. A multistage container build may include a compiler in a build stage without shipping it in the final image. A separately installed operating-system package can introduce a dependency that the application's package manager never saw.
These are review questions, not findings about a real product. Decide what population the inventory is supposed to describe, then check whether its collection method covers that population. Keep unknown coverage visible rather than converting it into a clean report.
Follow one finding through a synthetic release
Consider a fictional image-processing service called Preview. Its invented release preview-4.2 includes a fictional package pixeltile version 2.4. An invented advisory, EXAMPLE-ADV-001, concerns a decoder used only for one optional input format. These names do not identify a real vulnerability.
The initial scanner match says the package and version may be affected. To decide what to do, the reviewer needs a chain of evidence:
| Stage | Question | Evidence needed for Preview |
|---|---|---|
| Inventory | Does this SBOM describe the running release? | Release identity and collection scope |
| Component identity | Is this the package named by the advisory? | Ecosystem, supplier, package coordinates, version and relevant patches |
| Applicability | What exact condition triggers the issue? | Advisory's affected versions, platform and feature conditions |
| Reachability | Can Preview invoke the decoder? | Entrypoints, configuration and processing path |
| Exposure | Who can supply the relevant input? | Authentication, upload routes, worker access and trust boundaries |
| Response | What reduces the risk within the operating constraints? | Update, containment or a documented applicability conclusion |
A package-name match alone leaves several rows unanswered. So does “we do not use that format” if an automatic file detector can still choose the decoder. Trace the entrypoint through the running configuration rather than relying only on what the UI advertises.
If the shipped package is patched without changing its upstream version string, record the patch identity and supporting supplier evidence. Conversely, a newer version number alone does not establish that the relevant fix is included. Match the artifact and advisory through the package ecosystem's actual release information.
Treat VEX as a scoped assertion
Vulnerability Exploitability eXchange adds machine-readable context about whether a vulnerability affects a product. CycloneDX's VEX documentation describes that product-specific role. It helps carry an assessment between producers and consumers; it does not perform the assessment for them.
For Preview, a useful statement would identify the precise release and advisory, state the conclusion, and explain its justification. It should point to evidence and say who issued it and when. A statement about a different build or an earlier configuration cannot silently clear the current release.
Suppose a supplier says Preview is not affected because the decoder is absent from the shipped binary. That is stronger and more testable than “we have seen no exploitation.” The consumer should still establish whether the statement applies to its artifact and whether the issuer's assessment is trustworthy enough for the decision.
A signature can help establish where a VEX document came from and whether it changed. It cannot turn an unsupported reachability claim into a true one. Schema validation likewise checks the document's structure, not whether the vulnerable function is present or reachable.
Do not confuse a mitigating control with non-applicability. Blocking an upload route may temporarily reduce exposure while leaving the vulnerable component installed and usable through another path. Record the control, its limitations, and the condition under which it stops being effective.
Choose a response without hiding uncertainty
For the fictional service, imagine that the reviewer has confirmed the component match but has not traced the automatic decoder selection. A defensible interim decision could be:
Subject: preview-4.2 / EXAMPLE-ADV-001
Assessment: applicability unresolved
Known: reported component and affected version range match
Unknown: whether automatic format detection can invoke the decoder
Interim action: restrict the affected import route in the test plan
Owner: designated application maintainer
Next evidence: trace deployed decoder selection; assess fixed release
Review trigger: new advisory evidence, configuration change, or next releaseThis is an illustrative decision record, not VEX syntax and not a control we deployed. A real record needs actual identifiers, dates, evidence links, and an authorized owner. It should distinguish an intended mitigation from one applied and checked in the running service.
Severity helps prioritize, but it is not the entire decision. The FIRST CVSS v4.0 user guide states that a Base score measures intrinsic severity and should not be used alone as a risk assessment. Consider the service's exposure, data, privileges, available mitigations, and the reliability of the applicability evidence. Do not invent a universal score threshold that answers those questions for every application.
If updating is the response, use a dependency review and rollback process that tests the application paths affected by the change. A security update still changes software; a compatibility failure still needs a response that does not casually restore the original exposure.
Close the finding against current evidence
After an update, verify the artifact deployed and regenerate or reconcile its inventory. After a mitigation, verify the relevant route or control in the operating environment. After a not-affected conclusion, preserve the evidence and the assumptions that would invalidate it.
Reopen the assessment when the component, build options, runtime configuration, exposed routes, advisory, or supplier statement changes. A decision tied to release 4.2 should not automatically approve release 4.3.
The useful output is more specific than “the scan is green.” It says which release was assessed, why the finding applies or does not, what action was taken, which evidence supports that action, and what remains unknown.
Primary documentation reviewed October 28, 2026. Preview, its dependency, advisory, and decision record are fictional. No SBOM generator, vulnerability scanner, reachability analysis, or remediation was executed for this article.
