Normalize Findings
Normalization maps every ingested record — whatever shape it arrived in from VMDR, Policy Compliance, WAS, or a third-party source onto ETM's Common Data Model: a shared set of finding and asset attributes. Normalizing first is what makes it possible to compare, filter, and later correlate findings from different tools as if they spoke the same language.
Navigate to: Configuration > Custom Attributes (to see normalized attributes exposed as tokens)
The Common Data Model
Regardless of source, every finding is described using the same underlying attribute set. This is what the identification rules described in Correlate findings rely on to recognize the same issue across sources, and it's what surfaces as tokens you can use in Custom Attributes and search.
Core Normalized Attributes
Some of the attributes every finding is normalized to include:
- Type — Vulnerability or Misconfiguration
- Severity and QVSS/QDS score — a consistent 0–5 or 0–100 scale across all sources
- CVSS scores (Base and Temporal, v2 and v3), where applicable
- Status — for example NEW, ACTIVE, FIXED, REOPENED, PASS, or FAIL
- Title, sub-type, and source identifiers such as CVE ID, CWE ID, or vendor ID
For the complete, current list of finding and asset attributes, see Supported Attributes.
Why Normalization Matters
Without a common schema, a critical vulnerability from one scanner and a critical vulnerability from another could use different severity scales, different status names, or different field names entirely. Normalization removes that inconsistency before a finding is ever compared against another, scored, or shown to you so a QVSS score, a status, or a custom attribute formula means the same thing no matter which source the finding came from.
The attributes described here are also what you write formulas against when you create a Custom Attribute — for example referencing finding.qds or asset.criticalityScore.