From SBOM to security disclosure
Manage product security for every release you support. Generate SBOMs, monitor vulnerabilities, record what you decided and why, and tell your customers. All in one platform you can run in our cloud or on your own infrastructure.
The CRA doesn't stop when you ship. Neither should your security process.
Generating an SBOM is a good first step. But what happens after the software ships? New vulnerabilities are found. Dependencies change. Customers stay on older versions. Security fixes have to be built, shipped and explained.
The Cyber Resilience Act makes handling vulnerabilities for the whole support period of a product a legal obligation for manufacturers. Reporting obligations have applied since 11 September 2026, and the main obligations apply from 11 December 2027, with fines of up to €15 million or 2.5% of global annual turnover.
sbomify gives you the tools for that ongoing work, without stitching together spreadsheets, scanners, release notes and email threads.
One connected workflow, from software composition to customer disclosure.
Know what's in your software, and which releases are affected
Four steps that stay connected for as long as you support a product.
- 01
Generate and manage SBOMs
Create CycloneDX and SPDX SBOMs in your pipelines with our open-source GitHub Action, or upload your own. sbomify validates them against the official schemas, checks them against NTIA, CISA and BSI TR-03183 requirements, and keeps every version. Nothing you upload is ever changed.
SBOM lifecycle → - 02
Track every supported release
Your latest version isn't your only supported version. Pin component SBOMs to product releases, get a merged SBOM for each release, and record release, end-of-support and end-of-life dates using the ECMA-428 Common Lifecycle Enumeration.
Releases → - 03
Monitor and triage vulnerabilities
Released SBOMs are rescanned on a schedule with Google OSV and Dependency-Track, with CISA KEV and EUVD flags. Search a CVE across every product and release, then record your decision with VEX: not affected and why, accepted risk, or fixed.
Vulnerability scanning → - 04
Tell your customers
Publish SBOMs, VEX, security advisories and compliance documents through a branded Trust Center on your own domain. Advisories are also published as CSAF 2.0, and the Transparency Exchange API lets customers' tools fetch everything automatically.
Trust Center →
A new CVE just dropped. Now what?
Knowing a dependency has a vulnerability is only the beginning. Which of your supported releases contain it? Are you actually affected? Does it need a patch? What do you tell your customers?
sbomify links the finding to the products and releases that ship it, so your team goes from an alert to a recorded decision, a tracked fix and a published advisory.
Less time reconstructing your software history. More time fixing what matters.
| Release | Support | Status |
|---|---|---|
| v2.1Until 2031 | Until 2031 | Affected · fix in progress |
| v2.0Until 2030 | Until 2030 | Fixed in 2.0.4 · advisory published |
| v1.2.1Until 2028 | Until 2028 | Not affected · VEX: code not reachable |
| v1.0Ended 2026 | Ended 2026 | End of life · customers notified |
Your agents. Your data. Your decisions.
Your AI agents already know your codebase. Why send it to another vendor's model?
sbomify doesn't bundle an AI model, and none of its core security functions depend on one. Instead it gives your own agents structured security data and an API built for them, with a dedicated agent token that can read your workspace and propose work, but never approve it.
You choose which agents and model providers to use, so you decide where your data goes.
Use your agents to:
- Investigate a CVE in the context of your own code, using the triage and fix prompts sbomify generates
- Propose VEX statements that explain why a release is or isn't affected
- Draft security advisories and propose updates to published ones
A person signs off. VEX statements from an agent wait in a review queue, and its changes to published advisories are shown to your team as a diff. Nothing takes effect until a person approves it, and an agent can't approve its own work.
An audit trail you build by doing the work
The hard part of compliance isn't producing a document. It's showing what happened, when and why.
sbomify keeps SBOMs tied to the releases they describe and never alters them. Every triage decision is a new VEX version. Each finding records when it was first seen and when it was resolved, and advisories keep a timeline of every change. When customers, auditors or market surveillance authorities ask, you have the record.
What sbomify covers in the CRA, and what it doesn't
No tool makes you CRA compliant on its own. Secure design, risk assessment and conformity assessment are still your work.
sbomify supports most of the vulnerability-handling requirements in Annex I Part II, tracks support periods, and drafts the documents you need: the EU declaration of conformity, vulnerability disclosure policy, security.txt and Article 14 notification templates. Our CRA page maps each obligation to what sbomify does.
Disclosure your customers can actually use
Send a link instead of scheduling a call, and cut security questionnaire response times from weeks to minutes.
Share SBOMs, VEX, security advisories, CBOMs and compliance documents such as SOC 2 and ISO 27001 from one branded Trust Center on your own domain. Make each item public, private or gated behind an access request and NDA. People get a web portal; their tools get CSAF feeds and the Transparency Exchange API (TEA).
“Using sbomify has hugely accelerated our work on NTIA compliance. Viktor has also been leading a group that’s creating standards for making SBOMs — this gives us confidence that sbomify will become a platform that follows industry practices as they emerge.”
Open standards. Your infrastructure or ours.
Your supply-chain security shouldn't depend on one vendor's data format. sbomify works in CycloneDX, SPDX, OpenVEX, CSAF and the Transparency Exchange API, with an API for everything else.
Use our hosted cloud, or get the source on GitHub and self-host it for complete control over your data and infrastructure.
Built by people who write the standards
sbomify follows the blueprint of the CISA working group on SBOM generation, co-led by sbomify founder Viktor Petersson, who is also an invited expert to ECMA TC54 on security artifacts and the Transparency Exchange API.
When the standards move, sbomify moves with them.
Your CRA vulnerability-handling workflow starts here
Stop managing SBOMs, releases, vulnerabilities and security disclosures in separate systems. Bring them together with sbomify.
Latest blog posts
News
This Week in SBOMs: PHP2Shell, a Wave of Poisoned Releases, ENISA's SBOM Advisory and Germany's CRA Law
Welcome to the inaugural This Week in SBOMs, a weekly survey of developments within software security, regulation and standards, viewed...
Announcement
Announcing sbomify v26.9.0: The One That Speaks SPDX 3
If you generate SBOMs from an embedded Linux build, you have probably had a version of this experience with us: the document uploads,...
Announcement
Announcing sbomify-action v26.9.0: The One That Runs on Every CI
The action has always claimed to work on any CI system. That was true in the sense that it ran, and false in every sense that matters once...