SBOM management and vulnerability exchange
Producing a software bill of materials is the easy part. The harder part is keeping it current, loading it into one place and answering the question that follows every new flaw: is this component in anything we run, and can it be reached?
What we do
- Pipeline SBOM generation
- SBOM inventory setup
- Advisory watching
- VEX statement writing
- Triage workflow
- Customer SBOM delivery
Our team works with CycloneDX and SPDX formats, Syft and cdxgen to generate SBOMs, and Dependency-Track to store them and watch for new advisories. We have experience with OpenVEX, which records whether a flaw affects a product. We add generation to the build, send results to one project inventory and set rules for who triages a new finding.
This group goes deeper than our supply chain and IaC security group, which covers scanners and signing. An SBOM lists components and does not prove they are safe. These are tools our team has experience with, not partnerships.
Leading platforms we work with
- CycloneDX
- SPDX
- Dependency-Track
- Syft
- cdxgen
- OpenVEX
- Grype
Platforms and practices
- SBOM generation in build pipelines
- CycloneDX and SPDX output choices
- Central SBOM inventory in Dependency-Track
- New advisory alerts by component
- VEX statements for not-affected findings
- Triage ownership and response times
- Customer and insurer SBOM requests
- Container image and application SBOMs
- Component license review
References
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use SBOM management and vulnerability exchange for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreCyber Automation
Custom AI agents that do repetitive work around the clock, with human review where it matters.
Learn moreTailored Software
Software built around your business in weeks, and you own the code.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhat is the difference between an SBOM and a VEX statement?
An SBOM is a list of the components inside software. A VEX statement says whether a known flaw in one of those components actually affects a product. The first answers what is in it, the second answers whether a flaw matters.
Does an SBOM prove our software is safe?
No. It lists components and does not say whether they are free of flaws. It becomes useful when it is current and matched against new advisories.
Why keep SBOMs in one place?
When a new flaw is published, you need to know in minutes which products use that component. A central inventory with alerts by component answers that, and a folder of old files does not.
Do customers and insurers ask for SBOMs?
Some do, and some contracts require them. Ask the customer or your contracting officer which format and delivery they expect, and check with counsel before you promise delivery in a contract.