Vulnerability Tracking
Track every known vulnerability in the software you ship, from the build that pulled it in to the release that fixed it. CRACI records the SBOM of every build, keeps checking it against new vulnerability data, and routes each finding to the team that owns the fix.
What is vulnerability tracking?
Vulnerability tracking is the ongoing record of every known vulnerability that affects your software, from discovery until it is fixed or ruled out. For each one it answers four questions: where is it, which products and releases include it, who owns the fix, and what is its status.
Many tools answer the first question by scanning manifest and lock files after the fact, and leave the rest to spreadsheets and tickets. CRACI starts earlier. Your GitHub Actions jobs run on CRACI runners, and while they run, CRACI records every package the build actually pulled in, including packages restored from CI caches. That build-time SBOM is what CRACI monitors, so the vulnerabilities you track are the ones in the artifact you shipped, not in a scan that ran somewhere nearby.
Tracking the software you ship, not only your IT assets
Most vulnerability tracking tools are built for IT: they scan servers, laptops and cloud accounts, and the fix is a patch someone installs. Software you build and sell needs a different record. The vulnerable code is inside your release, the fix is a new build, and customers and authorities ask which versions were affected and for how long.
That is the record CRACI keeps: the SBOM of every build, the products and versions it was deployed to, the vendor components you bought in, and the status of every vulnerability across all of them.
Continuous re-evaluation of what you shipped
CRACI records the SBOM while each build runs, then keeps re-evaluating monitored SBOMs against vulnerability data. A vulnerability published long after a release still shows up against the release it affects, without anyone rerunning a scan.
One view across builds and repositories
Findings are aggregated across builds and repositories, with organization views on the default branch. The inventory view shows exactly which software versions are deployed to which products, and build history shows which past builds contained a vulnerable dependency, so you know which products were affected and for how long.
Triage and routing to the owning team
Security teams triage discovered vulnerabilities and send them to the teams that own the fix, so each finding reaches the people who can act on it. CRACI also supports VEX for recording how a vulnerability affects your product, and policy gates can block any build that contains a specific CVE.
Vendor SBOMs tracked next to your own
Add SBOMs from your vendors, and bought-in components are monitored alongside the software you build. Third-party code in your product is tracked in the same place as your own dependencies.
From finding to CRA notification
For the Cyber Resilience Act, CRACI submits the vulnerability notifications on your behalf: the early warning, the notification and the final report. SBOMs export as CycloneDX or SPDX with the vulnerabilities found in their components, for audits, customers and your own records.
Every vulnerable package, and what pulls it in
Each build lists its packages with version, package URL, license and vulnerability status, and shows whether its SBOM is complete. Open a package to see its advisories with severity, and the packages that require it.
The vulnerability tracking lifecycle in CRACI
- Discover. Each build produces an SBOM with a completeness state, exported as CycloneDX or SPDX with transitive dependencies. Monitored SBOMs, your own and your vendors', are re-evaluated continuously against vulnerability data.
- Locate. Organization views across builds and repositories, the inventory view and build history show which products and versions are affected, and since when.
- Prioritize and triage. Each advisory shows its severity. Security teams triage each finding, with VEX support for recording how a vulnerability affects your product.
- Remediate. Each finding goes to the team that owns the fix, and "Required by" shows which package pulls a transitive vulnerability in. Policy gates can keep a specific CVE out of later builds.
- Verify. The SBOM of the next build shows whether the vulnerable version is gone, so the record runs through to the fixed release.
- Report. CRACI submits CRA vulnerability notifications on your behalf, and SBOMs export with the vulnerabilities found in their components.
What to track for each vulnerability
- Vulnerability
- The advisory and its IDs (CVE, GHSA and others), with severity.
- Component
- The package and exact version, and whether it is a direct or transitive dependency.
- Path
- The packages that pull the vulnerable one in, which tells you what to upgrade.
- Exposure
- Which products, releases and builds include it, and since when.
- Owner
- The team responsible for the fix.
- Status
- Open, under investigation, not affected or fixed, ideally recorded as VEX.
- Evidence
- The build or release that no longer contains the vulnerable version.
Metrics that show whether tracking works
Security teams usually report on four numbers:
- Mean time to remediate (MTTR): how long it takes from a vulnerability being found to a release without it.
- Remediation deadline compliance: the share of vulnerabilities fixed within the deadline your policy sets for their severity.
- Backlog trend: whether the number of open vulnerabilities is going up or down.
- Exposure window: how long each product shipped a vulnerable version. CRACI's build history shows which builds contained a vulnerable dependency, so you know the period you were affected.
What CRACI does not do today
CRACI does not offer reachability analysis, so it does not rank findings by whether your code calls the vulnerable function. It does not show remediation metrics such as MTTR, deadline compliance or a backlog trend. It does not alert on a severity threshold today, and its alerts cover egress policy violations. Comments on findings, a diff between releases, threshold alerts and vulnerability webhooks are on the roadmap.
VEX: which vulnerabilities actually affect your product
A vulnerable component in your SBOM does not always mean a vulnerable product. The affected code may not be included in what you ship, or may not be reachable in the way an attack needs. VEX (Vulnerability Exploitability eXchange) is a machine-readable way to say so: each VEX statement links a product, a vulnerability and a status. The standard statuses are not affected, affected, fixed and under investigation.
That matters once customers and authorities check your SBOMs against vulnerability databases. Without a VEX statement, every match looks like an open issue, and your team ends up explaining the same false positives again and again. CRACI supports VEX for recording how a vulnerability affects your product, alongside the triage that sends each finding to the team that owns the fix.
Curious how much there is to keep up with? See how many CVEs are published each day and how the volume of High and Critical vulnerabilities has grown.
Vulnerability tracking, explained
Common questions about tracking vulnerabilities in the software you build and buy
What is vulnerability tracking?
Vulnerability tracking is the running record of every known vulnerability that affects your software, from the moment it is found until it is fixed or ruled out: which component and version it is in, which products and releases include it, who owns the fix and what its status is. For software you ship, it starts from an accurate list of components, which is what an SBOM provides.
What are the steps of vulnerability management?
The usual cycle has five steps: discover the vulnerabilities in what you run or ship, prioritize them, remediate them, verify that the fix removed them, and report. Tracking is what connects the steps, so a finding does not get lost between discovery and a fixed release. In CRACI the steps are recording the build-time SBOM, triaging each finding, routing it to the owning team, confirming that a later build no longer contains the vulnerable version, and reporting through SBOM exports and CRA notifications.
How do you track vulnerability remediation?
Give every vulnerability an owner and a status, and close it only when a build or release no longer contains the vulnerable version. Measure how long fixes take, whether they meet your deadlines and whether the open backlog is shrinking. In CRACI, each build's SBOM shows whether the vulnerable version is still there, and a policy gate can keep a specific CVE out of later builds.
What is SBOM vulnerability management?
SBOM vulnerability management means matching the components listed in your software bills of materials against vulnerability data, and doing it again as new vulnerabilities are published. The result is only as good as the SBOM. CRACI records the SBOM while the build runs, so the list reflects what the build actually pulled in, including packages restored from CI caches.
How is vulnerability tracking different from vulnerability scanning?
A scan is a point in time: it reads files, reports findings and stops. Tracking keeps the findings, their owners and their status over time, and keeps checking shipped software as new vulnerabilities appear. CRACI is a recorder, not a scanner: it records each build, then continuously re-evaluates the monitored SBOMs.
Does CRACI track vulnerabilities in third-party software?
Yes. You can add vendor SBOMs, and those bought-in components are monitored alongside the software you build on CRACI.
Can CRACI block a build that contains a known vulnerability?
Yes. Policy gates can block a build on findings, including any build that contains a specific CVE, so a vulnerability you have fixed does not come back in a later build.
How does CRACI notify me about vulnerabilities?
Findings appear in CRACI's organization views, where security teams triage them and send them to the owning teams. Alerts today cover egress policy violations. Threshold alerts and vulnerability webhooks are on the roadmap, as are Slack and Teams alerts.
Does CRACI help with CRA vulnerability reporting?
Yes. CRACI submits the CRA vulnerability notifications on your behalf: the early warning, the notification and the final report. Meeting the Cyber Resilience Act remains the manufacturer's process; CRACI automates a significant part of the supply chain visibility and evidence that process needs.
Does CRACI support VEX?
Yes. CRACI supports VEX (Vulnerability Exploitability eXchange) for recording how a known vulnerability affects your product, alongside triage and routing to the team that owns the fix. A VEX statement tells customers and authorities whether a vulnerability matched in your SBOM actually affects the product, so they are not chasing false positives. Book a demo to see how it fits your triage process.
Does CRACI do reachability analysis?
No. CRACI does not offer reachability analysis. It shows which of your builds, repositories and products contain a vulnerable component, and supports VEX for recording how a vulnerability affects your product.
See vulnerability tracking on your own builds
Book a demo and we will show which vulnerabilities reach the software you ship, and who owns each fix
Book a demo