Deviations and attestation

Discovery turns what it could not apply into work for people, and turns what it has confirmed into evidence for auditors. This page covers the queues a CMDB reviewer works and the report an auditor reads. The procedures are in Guides for CMDB reviewers and auditors.

Deviations (Soll/Ist)

When discovery refuses to apply a value because it contradicts the CMDB, the refusal becomes a deviation. The apply sweep creates deviations automatically. Each one shows the CI, the attribute, what the CMDB says (Soll), what was observed (Ist), severity, state, detection time and due date. You find them under Assets & Risk → Discovery sources → Deviations, on the page Verification and drift, in the Deviation queue.

Severity and review target

• Targets are wall-clock hours from detection, because a wrong CMDB is wrong at night as well.
• The daily SLA sweep (02:15) marks overdue deviations SLA breached and records one audit event per breach. It never changes their state. The Breaching SLA only filter shows them.

Ownership

The owner of a deviation is the CI's technical owner, otherwise its business owner, otherwise the standing queue owner. A deviation without any owner is not created and is reported as ownerless — set an owner on the CI.

Deciding a deviation

Deviations never close themselves. Closing requires a person, a decision and a written reason:

• Acknowledge — you take it on.
• Resolve — under Which value is right? you choose Keep CMDB value (preselected) or Accept observed value, and enter Why. Accepting the observed value updates the CI; keeping the CMDB value changes nothing.
• Not a deviation — a false alarm, dismissed with a reason.

Resolved and dismissed deviations cannot be reopened. If the systems still disagree, the next run records a new deviation with its own detection time, so breach history and mean time to resolve cannot be reset. Keep CMDB value is therefore only final when you also fix the device or the source.

An empty queue does not prove agreement. Either the estate matches the CMDB, or no source has observed it yet. Check source health and the run ledger before you read an empty queue as good news.

Verification and attestation

Partially available. The verification rules and the staleness check exist, but confirmations are not yet written by the sweep, so the attestation shows no verified CIs. The per-CI verification panel on the CI page is planned — not yet available, and the verification-window policy has no screen yet.

Verification

• A CI is independently verified when a source from a different origin system confirms it with authenticated or authoritative data for at least one strong identifier and one state attribute. A bare presence sweep is not enough.
• A confirmation older than the verification window (default 30 days, per CI class) makes the CI stale. A daily job at 02:15 records when a CI's last independent confirmation has left the window.
• Logical CIs that no second system can observe (business service, IT service, supplier, contract) can be designated single-sourced by construction with an audited justification.
• A CI with an open deviation is excluded from the verified count, however recently it was confirmed.
• Changing the verification window needs two people: the database refuses a policy where approver and recorder are the same.

The CMDB attestation

The CMDB attestation (Assets & Risk → Discovery sources → Attestation) is the auditor report. It reports the three states — verified, stale and single-sourced — separately, per CI class, with:

• the Denominator policy in words: what is counted and why, and whether the tenant has ever changed the verification window,
• Coverage at both the effective and the seeded default window — if they differ, the window was widened,
• Coverage by CI class: In scope, Window (days), Verified (effective N), Verified (default N), Stale, Single-sourced and Excluded (open deviation),
• Single-sourced by construction, listing every such CI with its justification,
• Deviations: open deviations and Mean time to resolve,
• Source freshness: the last successful run of every source, and quarantined sources.

Sealing (Seal attestation, permission discovery.report.export) stores the report as an immutable, hash-chained artifact anchored to an Audit chain head. A later report supersedes it; the sealed one stays on record. Sealing the first attestation makes the discovery_sources flag sticky.

Absent assets and retirement

When a CI is no longer seen, Discovery counts consecutive successful, complete runs of that source:

• Failed, partial, capped, quarantined and observe-only runs never count. A run counts only if the source is active and the run enumerated the whole estate.
• A change of scope, manifest or field list resets the count.
• When the count reaches the grace — 5 runs by default and for scanners, 3 for Intune — a tombstone candidate opens, but only if no other origin system still sees the CI.

Candidates appear under Assets & Risk → Discovery sources → Absent CIs, on the page Absent assets, with Missed runs and Corroboration (Also absent from or Only source for this item). A person chooses Retire or Keep. Retiring sets the CI's lifecycle state to retired through the normal CMDB versioning; the record, its history and its provenance stay, and you can reverse it by setting the lifecycle state back on the CI. Discovery never deletes a CI.

Moving a source to active has no button yet (see Sources and commissioning), and only runs of active sources count towards absence.

Review inbox

Partially available. The inbox lists software-name, CPE and lifecycle items, which cannot yet be decided in the UI. Topology links can be decided.

The Review inbox (Assets & Risk → Discovery sources → Review inbox) lists every discovery decision that waits on a human, oldest first, across all queues: software names, CPE mappings, lifecycle mappings and topology links. The columns are Decision, Subject, Waiting since, Assignee and From run.

• A queue your role cannot read is named rather than silently hidden.
• Truncated lists say how many items exist in total.

Software inventory, CVEs and end of life

Partially available. Software normalisation, CPE and CVE correlation and end-of-life enrichment are built and tested but not yet scheduled in the sweep. Recording open scanner findings as CVEs runs today.

• Scanner findings. Open findings from the scanner are recorded as CVEs on the matched CI, duplicate-safe and subject to the configured minimum CVSS score. They go through the CMDB CVE service, which owns versioning, the audit row and the DORA critical-detection event — see CVEs and lifecycle risk. This needs the cve_detection_ui flag.
• Software normalisation. Raw installer strings become publisher, product, version and edition. Resolution order: previous result, human correction, deterministic rule, AI suggestion. An AI suggestion is always queued for a human; the database refuses to accept one without a reviewer.
• Learning corrections. Correcting one variant of a product name fixes every variant with the same canonical key.
• CPE mapping and CVE correlation. Normalised products are mapped to CPE 2.3 names and matched against the mirrored NVD feed. Low-confidence mappings wait for review. Each correlation keeps the matched criteria and the snapshot date as evidence.
• End of life and end of support. Product versions are matched to release cycles from endoflife.date. The earliest date wins across installs; a date is never invented. Dates land in the CI end-of-life and end-of-support fields that the daily risk check reads. This needs the eol_eos_risk_register flag.
• Licences. The installed-software catalog is separate from the licence catalog. Intune detected applications feed the software licence allocations of Software Licence Management.

Vulnerability and end-of-life feeds are read only from the EU mirror, refreshed daily at 04:00.

Relationship mapping

Sources can report edges between two observed records, for example host A talks to application B. Once both ends resolve to a CI, the edge waits under Observed topology links in the review inbox, showing Observed edge, Type, From CI, To CI and Last seen.

• Accept creates a governed CI relationship that appears in the topology graph immediately — see Relationships and impact.
• Reject records the decision with a reason and creates nothing. A rejected link is sealed in the audit chain, and a later observation of the same edge does not reopen it.

Deciding topology links needs discovery.topology.decide.