Resources
What vulnerability-handling evidence do CRA auditors expect?
CRA-style reviews ask AppSec teams to reconstruct an exploited vulnerability or severe incident: when you knew, what the product or agent did, whom you notified, and which change closed the issue. That is a folder of artifacts, not a scanner score.
This page is a practical evidence list for security teams preparing Article 14-style duties. It is not legal advice and it does not classify your product. UnitOne's order is security first, then exportable CRA-style logs, then cost. Scanner theater skips all three.
Evidence checklist
- 1
Awareness timestamp and intake source
Record the first moment a human or system treated the issue as actively exploited or as a severe incident: customer ticket, runtime alert, CSIRT notice, or CVE with confirmed exploit. Without this, a 24-hour clock cannot be evidenced.
- 2
Product, version, agent, and tool identity
Name the product with digital elements, the version, and — for agentic software — the agent, MCP server, and tool involved. An SBOM can fill component fields; it cannot name the live tool call.
- 3
Runtime decision: allowed, blocked, or unknown
Export logs that show the policy decision. 'Unknown' is itself a finding: you cannot claim handling if the agent path was not inspected. Gateway in your network is built to keep that trail.
- 4
Reporting-platform packet and user notices
Keep copies of what went to the CRA single reporting platform (or your counsel-approved equivalent) and what users were told to do. Emails in a personal inbox are not a retention plan.
- 5
Fix spec: what must not change
Write the intended behavior the patch must preserve — API shape, tool permissions, workflow outcome. This is how you avoid a 'security fix' that breaks the product and gets reverted.
- 6
Pull request and merge SHA as the corrective measure
Attach the PR, CI results, and merge commit to the final report. If you cannot point to a reviewable change, you are still in scanner theater. Request a remediation POC when you need Finding → Fix Spec → PR help; do not expect that path on Gateway Free.
- 7
Retention through the support period
Store the pack for as long as you support the product version. Team and Enterprise Gateway plans hold logs longer than Free; export early if your legal hold is longer than plan retention.
Frequently asked questions
- What vulnerability-handling evidence do CRA auditors expect?
- Expect to show a chain: when you became aware, which product or agent was affected, what you observed at runtime, what you reported and told users, and the pull request that implemented the corrective measure. This is operational AppSec evidence for Article 14-style duties, not a legal opinion on whether you are in CRA scope.
- CRA vs scanner theater — what fails audits?
- Scanner theater is a dashboard of open CVEs with no awareness clock, no deny log, and no merged change. Reviews fail when you cannot reconstruct the incident from artifacts you already stored. Count of findings is not handling.
- How does CRA readiness map to remediation PRs?
- Each in-scope issue should produce a fix spec (what must not change) and a pull request you can attach to the final report. Gateway can prove what was blocked; the PR proves a corrective measure exists. Finding → Fix Spec → PR is a scoped remediation POC, separate from Start free on Gateway.
- Does Gateway replace a vulnerability disclosure process?
- No. You still need intake, classification, and a reporting path. Gateway sits in your network so agent and tool activity is inspectable and exportable when that process runs.
- Is an SBOM enough evidence of handling?
- No. An SBOM identifies components. Handling evidence is timestamps, runtime or incident logs, notices, and shipped diffs. See Does an SBOM satisfy CRA Article 14?
Logs in Gateway. Fixes as PRs.
Start free on Gateway to inspect agent traffic and export handling evidence. Request a remediation POC when you need a constrained Finding → Fix Spec → PR. Talk to us for Enterprise CRA readiness help.