CRACI for PSIRT teams and product security leads

The problem a PSIRT manager has

A head of product security is accountable for answers the PSIRT does not produce on its own. When a CVE lands in a widely used library, customers, executives and, increasingly, regulators ask the same questions within hours: are we affected, in which products and versions, since when, and when will it be fixed?

The answers depend on the inventory, and the inventory usually comes from scanners reading lockfiles or manifests after the fact. They list development dependencies that never ship and miss packages the build downloaded some other way. So the PSIRT asks engineering teams to check by hand, and the answer arrives in days, with caveats.

The FIRST PSIRT Services Framework calls an inventory of product components "essential to quickly identify affected products for inherited vulnerabilities". That inventory is where CRACI starts. For the full picture of the role, see what is a PSIRT.

What CRACI gives a PSIRT

An inventory recorded from the build

CRACI runs your GitHub Actions builds on its own runners and records the packages each job actually fetched, including transitive dependencies, packages restored from CI caches and dependencies no lockfile lists. It is a recorder, not a scanner. Each SBOM carries a completeness state, so a partial record is marked as partial, and SBOMs export as CycloneDX or SPDX.

Continuous monitoring of what shipped

Monitored SBOMs are re-evaluated continuously as new vulnerabilities are published, and findings are aggregated across builds and repositories. A CVE published next month is matched against the releases you already shipped, not only the next build. Known malicious releases with a published CVE are flagged like any other vulnerability.

Affected products, versions and periods

Build history shows every past build with its SBOM and which builds contained a vulnerable dependency, direct or transitive, so you know the period you were affected, within your retention period. The inventory view shows exactly which software versions are deployed to which products. Together they turn "are we affected?" into a lookup.

Bought-in components

Products rarely consist only of your own code. Vendor SBOMs can be added, so third-party components are monitored alongside your own builds.

Triage, routing and VEX

Security teams triage discovered vulnerabilities and send them to the teams that own the fix, which matches the distributed PSIRT model where product teams do the remediation. CRACI supports VEX. See VEX for how not affected statements save a PSIRT and its customers work.

Keeping a fixed CVE out of later builds

Policy gates can block a build on findings, including builds that contain a specific CVE. After a PSIRT case is closed, a gate on that CVE stops the vulnerable version from quietly returning in a later release.

Evidence for audits and customers

The API returns SBOMs, network traces and provenance for each build, so the record behind an advisory or an audit answer is available outside the UI. Where the EU Cyber Resilience Act applies, CRACI also submits the required notifications to authorities on the manufacturer's behalf; the obligation stays with the manufacturer. See what is the CRA.

Where CRACI fits in the PSIRT process

PSIRT stage	What CRACI contributes
Preparation	An SBOM per build, recorded as it runs, with a completeness state
Discovery	Continuous re-evaluation of monitored SBOMs, including vendor SBOMs
Verification	Which builds, versions and products contain the component, and since when
Remediation	Triage to the owning team; policy gates that keep the CVE out of later builds
Release and disclosure	VEX support; SBOM export; API access to the build record

The stages follow the vulnerability management lifecycle.

What CRACI does not do

• Reachability analysis. CRACI shows that a vulnerable package was in the build, not whether your code calls the vulnerable function.
• Source code scanning. SAST and secrets scanning are out of scope; plenty of good tools do that alongside CRACI.
• CI systems other than GitHub Actions. GitHub Actions today; other CI systems are on the roadmap.
• Compliance on your behalf. CRACI supplies the evidence; meeting NIS2, the CRA or any other framework remains your organization's process.

CRACI for PSIRT teams: frequently asked questions

Is CRACI a PSIRT tool?

CRACI covers the part of PSIRT work that depends on knowing what you ship: build-time SBOMs, continuous monitoring of them, which builds and products contain a vulnerable component, and triage to the owning team. Your disclosure channel and advisory process build on that record.

How does CRACI know what is in a product?

Builds run on CRACI's GitHub Actions runners, and CRACI records the packages each job actually fetched, including transitive dependencies, packages restored from CI caches and dependencies no lockfile lists. It is a recorder, not a scanner. Each SBOM carries a completeness state, so you know when the record is partial.

Can CRACI tell us which past releases were affected by a CVE?

Yes, within your retention period. Build history shows every past build and its SBOM, and which builds contained a vulnerable dependency, direct or transitive, so you know the period you were affected. The inventory view shows which software versions are deployed to which products.

Does CRACI cover components we buy from suppliers?

You can add vendor SBOMs, so bought-in components are monitored alongside your own builds.

Does CRACI support VEX?

Yes. CRACI supports VEX for recording how a known vulnerability affects your product. See VEX for the statuses and formats, and CSAF for how advisories carry them.

Which CI systems does CRACI support?

GitHub Actions today. Other CI systems are on the roadmap.