Continuous exposure management as an evidence system

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?

This paper treats continuous exposure management as an evidence system. The system's purpose is not to maximize finding count. It is to maintain a defensible chain from source observation to asset identity, local context, priority decision, corrective action, and verified outcome.

The proposed architecture uses seven durable concepts:

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.

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.

The 2026 Verizon DBIR's finding that software vulnerability exploitation leads initial access increases the cost of this fragmentation. A rapid patch decision requires affected-product evidence, reachable asset identity, business ownership, and remediation authority to converge.

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 Identity is a versioned function

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 Operator decisions outrank scanner refresh

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 includes type, normalized identifiers, criticality, exposure state, owner, tags, attributes, identity version, and source links. Useful types extend beyond hosts to services, web applications, URLs, cloud resources, container images, workloads, identities, operational devices, components, repositories, AI services, mobile apps, certificates, and data stores.

3.2 Finding

A finding is scoped to an asset and includes title, category, severity, confidence, detector, location, external identifiers, evidence, remediation, lifecycle state, control state, observation time, and source-native identity. Two assets with the same title remain two findings; repeated sources for one condition collapse around the same signature.

3.3 Relationship

Relationships make attack-path analysis possible. Examples include resolves-to, hosts, exposes, runs-on, member-of, depends-on, authenticates-to, contains, deploys, communicates-with, and derived-from. Every graph edge should identify its source and should not imply more than that source established.

3.4 Evidence record

Evidence records describe type, reviewer, review time, stable reference or artifact digest, and the claim supported. Evidence of active exploitation, public exploit availability, vendor confirmation, telemetry observation, or internal reproduction can strengthen exploitability. A feed label alone remains pending review.

3.5 Remediation and exception

Remediation includes owner, target date, status, planned action, verification requirement, and ticket reference. Exceptions and risk acceptance add accountable owner, rationale, expiration, conditions, and review. They do not remove the finding.

4. The exposure lifecycle

1. Acquire: accept approved scanner, inventory, SBOM, cloud, DNS, or manual records through strict adapters.
2. Validate: reject malformed, oversized, ambiguous, or out-of-contract input. Report partial coverage rather than hiding it.
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, exposure, exploit evidence, 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 useful prioritization model exposes its factors. Argus's current exposure model combines technical severity, likelihood derived from exposure and effective exploit maturity, asset criticality, control state, lifecycle status, and source confidence. Exploit maturity above proof-of-concept is honored only with reviewed evidence.

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

An evidence system is only as complete as its approved sources and scope. It cannot prove that an unobserved asset does not exist. Deterministic scoring improves reproducibility, not certainty. Relationship graphs can create false paths if edge semantics are loose. Threat feeds have collection bias and age. Authorized validation can affect fragile systems and therefore needs separate 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 tell an operator not only what to fix, but which asset, based on which source, connected through which path, under which model, owned by whom, and verified when. That is the difference between another signal aggregator and an operational security record.