Program Design Evidence

The evidence architecture of a good vulnerability program

September 24, 2026·9 min read·Chris Boker
A vertical rail on the left carries seven distinct state markers for the finding lifecycle, each with an ink arrow feeding a stacked ledger of seven identical evidence cards in the middle. Each card has a bold green header stripe, two rows of field bars, and a gold proof seal in the top right corner. Three regulator gate blocks on the right in rust, gold, and mint carry a clock face and three query lines each, and heavy ink arrows draw records from the ledger into every gate, so one archive answers all three clocks.

On September 11, 2026, the EU Cyber Resilience Act's reporting duty went live. A manufacturer aware of an actively exploited vulnerability in a covered product now has 24 hours to file an early warning through ENISA's Single Reporting Platform, 72 hours for a notification with impact and mitigation detail, and 14 days from a corrective measure existing to a final report (EC CRA reporting, Jones Day analysis). Whatever the program did to find, prioritize, and act on the issue, the truthful record of who knew what and when has to be filed inside a window measured in hours. If that record does not already exist as a designed output, it will be assembled under deadline out of ticket comments and chat threads.

The same demand arrives from two other directions. SEC Item 1.05 requires public disclosure within four business days of a materiality determination on a cybersecurity incident (Hunton practice update). CISA's BOD 26-04 puts federal civilian agencies on risk-tiered remediation clocks by December 7, 2026, and requires them to furnish their vulnerability management procedures on request. Three regimes, three clocks, one question: what did you know, when, and what did you do. Evidence is no longer an audit chore. It is a filing.

The prior art we should credit before naming anything new

Evidence discipline is not new to security. SOC 2 CC7 and CC8, ISO/IEC 27001 Annex A logging and monitoring, and the FedRAMP continuous monitoring package have generated more artifacts than most programs know what to do with, and FedRAMP's Plan of Action and Milestones (POA&M) is the closest published artifact to a governed evidence record for unresolved findings. Append-only ledgers and event sourcing are ordinary software architecture too; storing state transitions instead of the current-state row is what any transactional system does.

Adjacent provenance formats also exist. in-toto attests to build steps, SLSA ranks build environment integrity, and VEX communicates a supplier's exploitability position on a specific product-plus-vulnerability pair, which our earlier SBOM and runtime exposure piece covers. Each attests to something outside the remediation lifecycle inside one organization; that lifecycle is where the map goes blank.

The finding lifecycle as an evidence stream

Our CTEM reference architecture published in July put remediation evidence as layer six. This post is what that layer looks like when a team designs it in from the start, instead of reconstructing it after the auditor sits down. Treat every state transition on a finding as an event that emits an immutable record; the program then has a stream, not a folder.

  • Observed. Ingest source, timestamp, the raw evidence blob (packet capture, agent report, config snapshot), and the resolved asset identifier.
  • Scored. Exposure band (TRIS or equivalent tier) at decision time, plus a snapshot of the enrichment inputs (CVSS, EPSS, KEV, reachability, ownership, compensating controls) rather than a live lookup that drifts.
  • Owned. Team and named engineer routed to, the routing rule that matched, and the SLA clock start.
  • Acted. Change ticket references, patch version applied, config diff before and after, or the workaround script and where it ran.
  • Validated. Rescan artifact against the same asset, BAS run against the technique, or a sensor detection firing as expected.
  • Excepted. The exception artifact if the finding was accepted as residual risk, carrying owner, scope, compensating control and its validation record, expiration, and re-review trigger.
  • Closed. A reason code and a pointer to whichever prior record justifies closure.

Each record carries who, what, when, and a proof pointer. The current state of a finding is a projection over that stream, not a row someone edited in place, so a closed finding still carries its history, which is what an auditor, incident lead, or regulator asks for.

What counts as proof at each transition

Not every note a program writes is evidence. A ticket comment that says done is a claim; a rescan artifact showing the vulnerable version gone is a proof. When a calendar entry says patched, that is metadata; a config diff showing the RDP registry key flipped from 1 to 0 on a named host is a proof. An assertion that an exception is valid is opinion; the signed exception with an expiration, a compensating control, and a validation record for the control is proof.

The rule is boring and it holds: proof at closure has to match the risk at open. A hygiene finding closes on a clean rescan of the target. An internet-facing exploited CVE closes on a rescan plus a validation run showing the attack path failed plus a rotated credential set, because the exposure demanded all three. Write the required proof into the ticket at open time, per our remediation operating model, so the receiving team knows the bar before touching the change.

Storage that outlasts the scanner

Mutable ticket systems are poor evidence stores. Comments get edited, fields get renamed, projects re-parent, integrations rewrite descriptions on sync, a vendor migration wipes half of what the last auditor saw. The evidence store has three properties a ticket system does not need.

  • Append-only. A record is never edited after it is written; corrections write a new record that names and supersedes the earlier one, so the trail keeps both.
  • Keyed to asset and finding, not to ticket. A ticket ID belongs to the tool that issued it; the asset and finding identifiers belong to the program and survive tool changes.
  • Queryable by asset, service, control, and time window. All three regimes above ask time-boxed questions of the form "as of this date, what was known about this asset and what was being done about it." A store that cannot answer that shape of query is an archive.

None of this requires a bespoke database. A signed, versioned object store indexed in Postgres or SQLite is enough for most programs; a git-backed repository of JSON records is enough for a small one. The design constraint is the property, not the tool.

One archive, three regimes

The payoff is that one well-designed stream answers all three regulatory questions without a re-collection pass. A CRA 24-hour early warning wants the earliest observation of active exploitation, the affected product versions, and the mitigation state, from the observed and validated records. Its 72-hour notification wants initial impact and preliminary root cause, from the scored snapshot and the acted change references. The 14-day final report is the closure record with its proof pointer.

An SEC 1.05 materiality determination wants a defensible view of what the organization knew, when, and how it responded between then and the disclosure; the same stream produces that dossier as a query, not an all-hands weekend. A CISA request under BOD 26-04 wants the procedures on file and evidence the tiered clocks are being met, and the stream filtered to KEV-adjacent findings on federal-tier assets is already that record.

The alternative is manual archaeology across ticket comments and scan exports under a filing deadline. Verizon's 2026 DBIR across more than 13,000 organizations reported only 26 percent of KEV entries fully remediated. Some unknown share of the rest is genuinely mitigated with nobody able to prove it, and that unprovable middle is what evidence architecture converts into a defensible position.

The compounding return once evidence is designed

Structured evidence also changes what a program can measure. State transitions are timestamped and form a graph, so loop latency, first-owner latency, validation latency, exception churn, and re-observation rate become queries instead of manual counts. The measurement layer of a mature program sits on top of an evidence stream that was there first; without one, no program can honestly report those numbers or improve what it cannot see.

External enrichment is thinning at the same time. On April 15, 2026, NIST moved roughly 29,000 pre-March 2026 CVEs to a "Not Scheduled" status in NVD's operational triage (NIST NVD update), and Dragos's 2026 Year in Review reported 25 percent of ICS-CERT and NVD entries with incorrect CVSS scores in 2025 and 26 percent of ICS advisories with no vendor patch. Local evidence is increasingly the only authoritative record of why a finding was handled the way it was.

What evidence architecture does not fix

Evidence does not close findings. A program with a beautiful stream and a saturated fix queue still has a saturated fix queue, and no volume of proof records will drain it. A signed exception with a real expiration is honest, and the exposure still sits there until the compensating control does its job. The architecture makes the program's truth legible in real time, at the granularity a regulator or a board will ask for; whether that truth is comfortable is for the operating model to answer.

Where CVEasy fits

CVEasy AI writes the observed, scored, acted, validated, and excepted records locally, keyed to the asset identifier the resolved-asset layer produced and the TRIS score already assigned. The evidence store is a byproduct of a program running its loop honestly on hardware you own, not a compliance module bolted on after the fact.