Continuous exposure management, built on evidence you can trace

Executive summary

Exposure management fails when discovery, scanning, threat intelligence, ticketing, and reporting each maintain a different version of the environment. The organization receives more signals but cannot answer basic questions: Which asset is affected? Who owns it? Is it reachable? Is exploitation supported by evidence? Which business service depends on it? Did the fix work?

The point is a chain you can defend: this observation, on this asset, in this context; produced this decision, this fix, and this verified outcome. Counting findings is not the goal.

The architecture has seven parts:

1. Stable, versioned asset identity.
2. Normalized findings with preserved source provenance.
3. Explicit relationships forming an attack-surface graph.
4. Evidence-gated claims about exploitability.
5. Explainable, versioned prioritization.
6. Operator-owned remediation and exception state.
7. Rescan verification and measured risk delta.

Threat context for this paper is in Whitepaper 02.

1. The fragmentation problem

A typical security stack can identify the same system as a hostname, IP address, cloud instance, application URL; certificate name, agent ID, and CMDB record. If each scanner creates a new object, the organization inherits duplicate findings, split ownership, contradictory severity, and several independent closure states.

Three forms of drift follow:

• Identity drift: the same asset becomes several records or a recycled identifier is attached to the wrong asset.
• Evidence drift: the current claim no longer points to the response, artifact, configuration, or source that supported it.
• Workflow drift: a scanner refresh reopens accepted risk, closes a manually confirmed issue, or erases the reason for a decision.

...requires four things to line up fast: you know the product is affected, you know which of your assets runs it, you know who owns it, and someone can change it.

2. Architecture principles

2.1 Observations are not conclusions

A scanner label, inventory fingerprint, threat-feed record, and analyst reproduction are different evidence classes. Preserve each claim at its strongest justified level. Unknown coverage should remain unknown rather than becoming a negative finding.

2.2 Version the rule that assigns asset identity

Asset keys should derive from normalized identifiers under published precedence. Cloud identity should include provider and account. A change to identity logic needs a new version and migration path; silently re-keying destroys history.

2.3 Sources remain visible after normalization

Normalization makes sources comparable, but it should not erase their origin. Each ingest run records source kind, name, reference, time, and the records touched. An analyst must be able to return from the normalized finding to its original evidence.

2.4 A human decision outranks the next scan

Scanners own what they observed. Operators own status, mitigation, acceptance, and business decisions. Re-observation should append history and raise a regression signal without silently taking ownership back.

2.5 Every calculated result is explainable

Risk, attack paths, service-level status, and score changes should be reproducible from stored inputs and a named model version. A model upgrade retains the superseded value and factors.

3. Minimum data model

3.1 Asset

An asset record carries its type, its identifiers, who owns it, how exposed it is, and where the data came from. “Asset” means more than a host: web applications, cloud resources, container images, identities, certificates and data stores all get records.

3.2 Finding

A finding belongs to one asset and records what it is, how severe, how confident, what found it, and what state it is in. Two assets with the same problem are two findings; several sources reporting one condition collapse to one.

3.3 Relationship

Relationships are what make attack-path analysis possible: resolves-to, authenticates-to, depends-on, and about eight more. Every edge names the source that established it, and claims no more than that source did.

3.4 Evidence record

Each record names its type, who reviewed it and when, a stable reference, and what it proves. Active exploitation, a public exploit, vendor confirmation or your own reproduction all strengthen an exploitability claim. A feed label on its own stays pending review.

3.5 Remediation and exception

Remediation records the owner, target date, and planned action, among other fields. An exception adds its rationale and expiration. The finding remains in the record.

4. The exposure lifecycle

1. Acquire: accept approved scanner and inventory records through strict adapters, along with SBOM, cloud, DNS, or manual sources.
2. Validate: reject malformed or oversized input and flag ambiguous or out-of-contract records; partial coverage appears in the result.
3. Resolve identity: normalize identifiers and apply the versioned precedence rule.
4. Merge without downgrade: enrich existing assets and findings while preventing partial input from erasing stronger context.
5. Correlate: build relationships, attach source provenance, and evaluate declarative exposure combinations.
6. Review evidence: confirm affectedness and exploitability at a level appropriate to the decision.
7. Prioritize: combine severity with exposure and exploit evidence. Then account for asset criticality, confidence, control state, and attack-path context.
8. Remediate: assign work, clock, exception, and owner.
9. Verify: retest or reacquire evidence, compare state, and record risk delta.
10. Report: present different views for executives and analysts from the same underlying records.

5. Prioritization without a magic number

A prioritisation model is only useful if it shows its factors. Ours weighs technical severity, how exposed the asset is, how mature the exploit is, and what the asset actually does — plus how much we trust the source. Anything above proof-of-concept exploit maturity needs reviewed evidence before it counts.

Threat intelligence is attached as a dated claim. CISA KEV establishes known exploitation in the wild; EPSS estimates exploitation probability over a 30-day window. Neither proves local affectedness. They strengthen the threat side after product and asset identity are resolved.

Attack-path analysis adds topology. A medium-severity condition on a reachable identity service that authenticates to critical systems may deserve higher priority than an isolated critical issue. The system should show the path and factors rather than conceal that conclusion inside a vendor score.

6. Metrics that measure control

• Inventory coverage: percentage of in-scope services with owner, criticality, exposure, and current source evidence.
• Identity quality: unresolved duplicate rate, ambiguous identifier rate, and recycled-asset detection.
• Evidence coverage: percentage of urgent findings with confirmed affectedness and reviewed exploit evidence.
• Threat-feed freshness: age and coverage of KEV, EPSS, and vendor claims.
• Remediation flow: median time to owner, mitigation, fix, and verified closure by priority.
• Exception health: expired acceptances, unowned exceptions, and conditions not revalidated.
• Verification quality: percentage of closures supported by rescan or equivalent evidence.
• Risk delta: change in open risk and attack paths, with model-version consistency.

7. Staged adoption

Phase 1: identity and ingestion

Select authoritative sources, define in-scope asset types, normalize identifiers, preserve provenance, and import without network side effects. Measure duplicates and unknown ownership before adding another scanner.

Phase 2: workflow ownership

Define finding identity, operator-owned lifecycle, remediation clocks, exception requirements, and verification evidence. Integrate tickets only after field ownership is explicit.

Phase 3: context and paths

Add business criticality, exposure, relationships, exploit evidence; KEV, EPSS, and deterministic attack paths. Validate each relationship producer independently.

Phase 4: continuous assurance

Schedule source refresh, detect inventory change, monitor stale coverage; verify remediation, report trends, and review scoring-model changes through a release process.

8. Limitations and failure modes

The biggest limit is scope: we cannot prove an asset we never saw does not exist. After that, deterministic scoring buys reproducibility rather than certainty; loose edge semantics can invent paths; and every threat feed has collection bias and an age. Authorized validation can also break fragile systems, which is why it gets its own scope and pacing controls.

The architecture should fail visibly: mark partial collection, stale feeds, unknown ownership, unreviewed exploit claims, and unverified closure. A clean dashboard produced by hiding uncertainty is a worse outcome than an honest coverage gap.

Conclusion

Continuous exposure management becomes useful when it preserves the chain of reasoning. The system should name the fix and affected asset, cite the source, and show the relevant path. It must also record the model, owner, and verification time. That evidence turns incoming signals into an operational security record.

Edition history: September 1, 2026, version 1.1. September 8, 2026, version 1.2: source links added; asset identity, prioritization, and operating limits clarified.