The critical-CVE and DORA RTS Art. 10 evidence reports, how reports are sealed and bound to the audit chain, and how the audit trail serves as evidence.

The same records that drive daily vulnerability and patch work also produce the evidence auditors and supervisors ask for. This page covers the evidence reports available today, how they are sealed, and how you use the audit trail to show who did what, and when.

Evidence reports

Report	Content	Requires	Status
Critical CVE evidence	Point-in-time snapshot of which CIs carry critical CVEs (the detection half).	`reporting.run`	Partially available — the generator exists and results appear in Reports history
DORA RTS Art. 10 remediation evidence	For every CVE on a CI: the patch that closes it, the Change that deployed it, the Change's approval and state, the per-CI installation outcome and the resulting CVE status.	`reporting.run` and `dora_detection_workflow`	Partially available — the report is started through the API, not yet from a button

Together the two reports cover both halves of the DORA vulnerability evidence: detection (which CIs carry critical CVEs) and remediation (how each CVE on a CI was patched through a governed Change). Generating a DORA artifact makes the dora_detection_workflow flag sticky: switching it off afterwards requires a reason and approval by a second person.

What feeds the remediation evidence

The DORA RTS Art. 10 report reads the chain that patch work already records:

A CVE is recorded on a CI — manually or from the scanner integration.
The catalogue identifies the patch that closes it (Suggested patches on the CI).
Deploy patch creates a Normal Change with the affected CIs, which is approved and scheduled through the CAB.
The implementer records Installed, Failed or Deferred per CI under Patch deployment outcomes.
The resulting CVE status on the CI is recorded.

Sealed, content-hashed reports

Every report is stored as an immutable report record, content-hashed and bound to the head of the audit chain at generation time. Generated reports appear under Reports > Reports in the History section with their state and Hash. A report in state Ready with a hash is the sealed artifact you hand to an auditor or supervisor.

The audit chain itself is checked by a daily verifier, described below.

The audit trail as evidence

Every change to a finding, patch, patch status, deployment outcome, known-issue setting or risk acceptance writes exactly one audit event, in the same transaction as the change. The audit log is:

append-only at database level;
hash-chained per tenant;
verified daily by a chain verifier.

Audit payloads contain IDs, states, counts, hashes and reason codes — never raw scanner output or free-text rationales, which stay in the record itself. Records written by a feed are attributed to the source (system actor), with the person who triggered the run noted separately.

To trace a finding or a patch, open Admin > Audit log and filter by entity type, for example vulnerability_finding, or by the patch. Creation, triage and deployment outcomes each appear once. The step-by-step version is in Trace the history of a finding or patch.

What auditors can see

The standard Auditor role has read-only access to findings, CVE exposures, the patch catalogue and patch status, the audit trail and the sealed evidence reports. Reading is not audited as a change.

Planned evidence capabilities

Planned — not yet available. The following are specified target behaviour and are not part of the current release:

Vulnerability evidence with preflight — before generating, a preflight lists unverified or manual closures, expired acceptances, Changes without outcome, groups without owner, stale or unknown coverage and unmatched critical assets, so you can fix them first. The report distinguishes every outcome, and only scan-verified closures may be described as verified.

Program rollups — open by severity and service, overdue, median age, reopened, coverage freshness, verified versus manual closure, expiring exceptions and unmatched assets, with every rate showing its denominator and unknown coverage shown separately; including pseudonymized Works Council views.

See Availability.

Reporting and evidence