Scanner output is evidence, not a data model

There is a pattern most vulnerability programs eventually build without meaning to. Scanner output becomes the ticket schema, scanner severity becomes the SLA class, scanner solution text becomes the remediation body, and scanner closure becomes the proof of work. What starts as evidence a sensor produced ends up as the data model the whole program is scored against, and once it is baked into every downstream tool the program can only ask the questions the scanner already asked.

What scanner schemas are actually good at

Give the scanner authors their due. A Nessus finding, a Qualys detection, and a Trivy report against a container image are all excellent at the same thing: capturing what a sensor observed at a moment in time. Host or image, plugin or check ID, version compared, evidence of the check, severity as the scanner interpreted the raw signal, first and last seen. That is a good record for what it is, and it exists in tens of thousands of production environments because scanners are still the cheapest reliable way to see the fleet. The problem is not the finding. The problem is what everyone does with it after.

The accidental architecture

The accidental architecture usually goes like this. Scanner severity is the first number in the record, so it silently becomes priority. The vendor's solution text is already written, so it becomes the ticket body remediation teams copy paste into Jira. And when scanner closure fires an event the audit trail can hang a screenshot on, that event becomes proof of work. None of those defaults are wrong at the sensor and all of them are wrong at the program: severity comes from a signal that ignores ownership, blast radius, business impact, and whether the affected code path is even reachable; solution text is generic guidance a vendor wrote before knowing your fleet; and closure means only that the scanner cannot see the check any more, which is a much smaller claim than the vulnerability being gone.

What OCSF, ECS, and SARIF do and do not cover

The industry has spent real years standardizing what the scanner produces, and the result is genuinely useful prior art we should credit before staking a novel claim anywhere else. The Open Cybersecurity Schema Framework ships a dedicated Vulnerability Finding class (uid 2002) inside its Findings category, adopted by AWS Security Lake and other SIEM oriented destinations as the shape for vulnerability events. Elastic's Common Schema defines a vulnerability.* field group for log style storage, so the finding survives search and correlation. SARIF, the OASIS standard at version 2.1.0, is the interchange format for static analysis output that most modern CI vendors emit and most IDE integrations render. Older SCAP era work continues under OVAL, though OVAL 6.0 development is formally on hold pending NIST SCAP 3.0 discussions. That last detail is the sharper version of the standards stalled argument: the shared shape for evaluating a check has been paused, and no successor has picked up the question of what happens to the check across time.

The mutable join no open standard models

Here is where the open ground actually sits. OCSF models the finding event, ECS models the log field, and SARIF models the static analysis result. All three are correct within their frames, and none of them describes the persistent, stateful entity a remediation team operates against: an asset by identity, joined to a vulnerability by CVE and package, joined to a lifecycle state that changes as the world changes, joined to ownership, suppression, VEX status, and validation evidence. The finding is an append only event. The exposure is a mutable join. Programs have been treating the event as if it were the join, and the vendors that solve the join, aggregation platforms like Nucleus and the exposure stack that landed inside Tenable after the Vulcan Cyber acquisition in early 2025, plus Brinqa's CyberRisk Graph normalizing more than two hundred and forty sources, all do it entirely inside proprietary schemas. That proprietary consensus is the shape of the open ground: not a competitor to OCSF, but a companion entity the existing standards intentionally chose not to model.

Six concerns the scanner schema cannot carry

Six things the exposure entity has to carry, and no scanner record has native fields for.

• Ownership. The person who fixes and the business unit that owns the impact, both of which live in HR systems, service catalogs, or an application registry, and neither of which the scanner has any reason to know.
• Reachability. Runtime evidence that the vulnerable code path is loaded and callable in production, rather than merely present on disk, which requires eBPF or profiling data the scanner does not collect.
• Compensating controls. The WAF rule, EDR shim, patch policy exception, or network segmentation that changes the residual likelihood without changing the package version.
• Exception state. VEX statements that mark a component as not affected with a documented reason, a reviewer, and an expiration date, which is the OASIS standard the industry finally has for saying "we know, and here is why the CVE does not apply here."
• Validation. The ground truth signal from breach and attack simulation or exploit reproduction that confirms the finding is actually exploitable in this environment rather than only theoretically dangerous.
• Business impact. The tie back to the service the asset participates in and the revenue, safety, or regulatory consequence of that service being degraded, which lives in a business impact analysis a scanner has never seen.

A scanner record can point at some of these through side channels, and a mature normalization layer will pull them from the systems that own them, but none of them originate in the scanner and none of them belong in the scanner schema.

One CVE, many findings, zero or more exposures

The clean way to see this is a many to many chain rather than a flat record. A CVE is a published fact about a class of software. A finding is one sensor's observation that the fact might apply to one asset at one moment. An exposure is the program's decision that this observation, on this asset, in this environment, with these compensating controls, this ownership, and this validation evidence, is a real thing the remediation team should carry work against. One CVE maps to hundreds or thousands of findings across a fleet. Those findings map to zero or more exposures, because plenty of findings are false positives, exact duplicates, or already covered by an exception the program accepted last quarter. That collapsing step is the entire job of exposure management, and it cannot be done by the scanner because the scanner does not carry the context to do it.

Why AI assistants inherit the shape you give them

There is a practical reason to fix the schema now that generative assistants are being wired into remediation workflows. If the assistant is grounded in a scanner shaped table, its answers will be scanner shaped. Ask it to explain why a ticket matters and it will paraphrase the plugin's solution text back at you. Request a proposed fix and it will offer the vendor's generic patch instruction. Push it to reorder the queue by risk and it will resort by severity, because severity is the only signal in the schema the assistant can actually see. Ground the same assistant in an exposure entity that carries ownership, reachability, controls, exceptions, and validation, and the answers change qualitatively. The model is no more capable than it was five minutes ago; the schema is more complete, and completeness is the ceiling that raw model quality alone cannot break through.

The reframing: sensors in, exposure entity out

The reframing we push for programs starting exposure entity work is short. Scanners are sensors. Their output is evidence, high value evidence, that the sensor did what a sensor does. Normalize that evidence into an exposure entity that lives in its own store, keyed by durable asset identity (a separate design problem we sketched last week in the asset identity graph post) and joined to CVE, package, ownership, controls, exception state, and validation. Wire the ticketing system, the SLA policy engine, and the executive dashboard to read from the exposure entity, not the raw finding stream. Keep the scanner schema pristine as the sensor record that it is, and let it evolve at its own pace without dragging the rest of the program along with it. The context over scanner argument we made in the same CVE, different risk piece is the same argument one layer up.

CVEasy stores the exposure entity separately from every sensor it ingests, with ownership, reachability, and validation as first class fields rather than derived guesses. TRIS scores against that entity, so a finding without a confirmed exposure never generates a ticket and no scanner default ever silently writes itself into the SLA policy.