An SBOM is the ingredient list for your software, and ASPM is the process that uses that list, plus scan results and context, to decide what to fix first. SBOMs supply the component data. ASPM turns it into owned, prioritized, tracked work.
Two ideas, two jobs
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. It answers "what is in this build?"
ASPM, application security posture management, answers a different question: "of everything we know is wrong, what should we deal with first, and who is on it?" The two meet where a new vulnerability is announced and you need to know which of your products contain the affected component.
How they connect in practice
- Generate. Each build produces an SBOM.
- Store. The SBOM is attached to the right product and version.
- Match. When a new advisory appears, the platform checks stored SBOMs for the affected component.
- Prioritize. The match is ranked using exploitation data, reachability and exposure.
- Assign. The finding goes to the owning team.
- Communicate. If a customer asks, you can show whether you are affected.
Without the SBOM, step three is a manual search. Without ASPM, steps four to six are a spreadsheet.
Where VEX comes in
A VEX, vulnerability exploitability exchange, is a statement about whether a product is affected by a specific vulnerability. CISA publishes minimum requirements for VEX documents. A VEX lets a supplier say, for example, that a flagged component is present but the vulnerable code is not used. This reduces noise for customers who receive your SBOM.
| Document | Says | Typical reader |
|---|---|---|
| SBOM | What components are in the product | Customers, auditors, your own team |
| VEX | Whether a given vulnerability affects the product | Customers who scanned your SBOM |
| ASPM view | What to fix, by whom, by when | Your engineering and security teams |
Common gaps to look for
- Stale SBOMs. One generated at release but never refreshed misses newly disclosed issues, because the list of components stays the same while the advisories change. Matching must happen continuously.
- Missing transitive dependencies. Check that nested packages are listed.
- No link to ownership. An SBOM does not say who owns the product. The platform must.
- No export. If you must share SBOMs with customers, test that the platform can produce a standard format.
What to ask when buying
Which formats does it produce and ingest? Does it match new advisories to stored SBOMs automatically? Can it generate or consume VEX statements? Can I share a customer facing view without exposing internal data?
A starter plan
Begin with your one or two most important products. Generate SBOMs in the build, store them centrally, and run a monthly drill: pick a recent advisory and time how long it takes to list affected products. Improve until it takes minutes.
A worked example: a new advisory arrives
Suppose an advisory is published for a widely used parsing library. Here is how the flow looks with SBOMs and an ASPM process in place.
- Morning. The advisory is published, and your platform matches the library name and version range against stored SBOMs.
- Within the hour. It lists five products that contain the library, with versions.
- Prioritize. For each product, you check whether the component is reachable and whether the product is exposed. Two products are internet facing.
- Assign. Tickets are created for the two exposed products with a short deadline, and the other three are scheduled.
- Communicate. A customer asks whether you are affected. You answer using the SBOM and, where relevant, a VEX statement.
Without stored SBOMs, step one would be a search through repositories. Without a prioritization process, steps three and four would depend on whoever read the advisory first.
Step by step: building the flow
- Choose one product and generate an SBOM in its build.
- Store each SBOM with the product name, version and build date.
- Pick a recent advisory and match it against the stored SBOMs by hand, timing the exercise.
- Automate the match once you know what it needs to do.
- Add exposure and ownership fields to the product record.
- Write a short template for customer answers, reviewed by security.
Choosing an SBOM format
Two formats are widely used in practice, and most tools can read both. When choosing, consider what your customers ask for, what your build tools support and whether you need to include extra information such as licenses or provenance. Pick one for internal use and offer the other on request if customers need it. Keep the decision recorded and revisit it annually.
Handling the customer facing side
When sharing SBOMs, decide who may receive them and under what terms. Some companies share freely, while others require an agreement. Strip internal paths or private package names if they are sensitive. State the date of generation clearly, since an SBOM is a snapshot.
Measuring the flow
Track the time from advisory publication to a list of affected products. If it takes days, there is room to improve. If it takes minutes, shift attention to the next step: time from list to fix.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance and evidence automation. A free scan at gold.safeguard.sh/scan shows what an inventory looks like for your code.
Try it yourself
Click through it at your own pace, or open it full screen. Check how components and versions are listed.
Quick check
Is an SBOM the same as a vulnerability report?
No. An SBOM lists components. A vulnerability report lists known flaws in them.
Do I need VEX to use an SBOM?
No, but it helps customers separate present components from exploitable ones.
How often should SBOMs be regenerated?
Generate one with every build or release. The advisory data changes daily, so matching against stored SBOMs should also run continuously.
Sources
Last reviewed: 19 October 2026.
