A vulnerability feed is useless until each advisory is tied to the specific hosts, packages, devices and images you actually run, and most organisations cannot do that join quickly when a critical CVE lands. MITRE D3FEND names this countermeasure Asset Vulnerability Enumeration (D3-AVE) and defines it as follows: "Asset vulnerability enumeration enriches inventory items with knowledge identifying their vulnerabilities." It sits in the Model tactic as a child of Asset Inventory, and it has one child of its own, Container Image Analysis (D3-CIA). This guide covers what D3-AVE records, the identifiers and feeds that make the match work, how to build and verify it, and where it breaks. It is for vulnerability management leads, platform engineers and security architects who already run scanners and want the enumeration to be complete and trustworthy. The family overview is in the MITRE D3FEND Asset Inventory Implementation Guide.
Key takeaways
- It is an enrichment, not a scan. D3-AVE adds vulnerability knowledge to items that already exist in an inventory, so its coverage can never be better than the software and hardware inventory underneath it.
- Identifiers decide accuracy. The match between an installed component and an advisory runs on names such as CPE for products and Package URL for open source packages; poor naming is the main source of both missed and false findings.
- Exploitation data changes the order of work. CISA's KEV catalogue, FIRST's EPSS probabilities and SSVC decision outcomes turn a raw list of CVEs into a ranked queue.
- Not every match is real. VEX statements let a supplier or your own team record that a product is not affected, with a justification, so enumeration results can be closed without patching.
- D3FEND's ATT&CK links are inferred and broad. They come from the Software and Container Image artefacts D3-AVE evaluates, so they show where an unpatched component matters, not a detection mapping.
D3-AVE at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-AVE (d3f:AssetVulnerabilityEnumeration) |
| Tactic | Model |
| Parent technique | Asset Inventory (D3-AI) |
| Child technique | Container Image Analysis (D3-CIA), synonym Container Image Scanning |
| D3FEND relations | evaluates Physical Artifact; evaluates Software; identifies Vulnerability |
| Sibling techniques | Configuration Inventory (D3-CI), Data Inventory (D3-DI), Hardware Component Inventory (D3-HCI), Network Node Inventory (D3-NNI), Software Inventory (D3-SWI) |
| D3FEND references | Three patents: McAfee "Automated computer vulnerability resolution system", Nokia "Security vulnerability information aggregation", CA "System and method for vulnerability risk analysis"; the ontology also lists a Veracode software vulnerability graph database patent against it |
| Typical outputs | Per asset and per component: CVE or advisory ID, affected version range, fixed version, severity, exploitation status, owner, due date |
| Main limitation | Only finds known, published vulnerabilities in components the inventory already knows about |
What D3-AVE models
The three patents D3FEND cites describe the same pipeline from different angles. The Nokia patent aggregates vulnerability information from multiple sources into unified vulnerability definitions. The CA patent takes host configuration information, queries a vulnerability database, removes vulnerabilities whose fixes are already installed, and computes a risk score per host and per software product. The McAfee patent aggregates vulnerability information into a remediation database and deploys remediation to client computers. Together they describe four stages a working D3-AVE implementation needs.
- Know the components: the software inventory (D3-SWI) and hardware component inventory (D3-HCI) supply product names and exact versions, including firmware.
- Aggregate advisories: pull vulnerability records from public databases, vendor advisories and open source advisory feeds and normalise them into one record per vulnerability.
- Match and suppress: join components to affected version ranges, then remove matches where the fix or a backported patch is already present.
- Score and route: attach exploitation and impact context, assign an owner and feed the result to patching and hardening work.
D3-AVE is a modelling technique. It does not by itself patch, block or detect anything; its value is that the techniques that do act, such as software update and platform hardening in D3FEND's Harden tactic, work from an accurate list. Active probing of systems is a separate assessment technique: see D3-NVA Network Vulnerability Assessment and D3-SYSVA System Vulnerability Assessment.
Identifiers and feeds that make the match work
| Source or identifier | Publisher | What it contributes to D3-AVE |
|---|---|---|
| CVE ID | CVE Program | The common key that joins advisories, scanner output, KEV, EPSS and VEX statements |
| CPE 2.3 | NIST | Standard names for classes of applications, operating systems and hardware devices, used to state which products a CVE applies to |
| Package URL (purl) and OSV records | OpenSSF OSV schema | Open source advisories keyed by ecosystem (npm, PyPI, Debian and others), package name and version ranges with introduced, fixed and last_affected events |
| KEV catalogue | CISA | CVEs with reliable evidence of active exploitation and a clear remediation action |
| EPSS | FIRST | A daily probability from 0 to 1 that a CVE will be exploited in the wild in the next 30 days, with percentiles |
| SSVC | CISA | A decision tree with outcomes Track, Track*, Attend and Act, based on exploitation status, technical impact, automatable, mission prevalence and public well-being impact |
| VEX | CISA minimum requirements (April 2023) | Supplier or internal statements that a product is not affected, affected, fixed or under investigation |
Two practical points follow. First, CPE names product classes rather than installed instances, so the enumeration engine still needs your inventory's exact version and build to decide applicability. Second, OSV ranges are evaluated per ecosystem: the same package name in two ecosystems is two different packages, and an OSV entry counts a version as affected if it falls in any listed range or appears in the explicit versions list. Matching an open source library by name alone, without its ecosystem, is a common source of noise. Background on the identifiers is in the CVE, CWE and CPE Guide and the SBOM Guide.
Collection approaches compared
| Approach | How components are found | Strengths | Watch for |
|---|---|---|---|
| Agent-based enumeration | Local agent reads installed packages, file versions and patch state | Accurate versions, sees roaming laptops and backported fixes | Agent coverage gaps; appliances and OT devices cannot take agents |
| Authenticated network scanning | Scanner logs in with a credential and queries the host | No agent needed; good for servers and network devices | The scan credential is a privileged non-human identity (see below) |
| Cloud provider and API inventory | Instance, image and managed service metadata from the provider's APIs | Sees short-lived resources a scheduled scan misses | Managed services report versions differently; shared responsibility for patching |
| SBOM matching | Component lists produced at build time are matched against advisory feeds | Re-evaluates shipped software when a new CVE appears without rescanning | SBOM must match what is deployed, not what was built last month |
| Container image analysis (D3-CIA) | Image layers are unpacked and package databases read in the registry or pipeline | Finds issues before deployment | Covered in D3-CIA Container Image Analysis |
Decision guidance: a small organisation with mostly cloud and SaaS can rely on device management agents, the cloud provider's own inventory and one scanner. A large or regulated estate usually needs all five, reconciled into one record per asset, because each method misses something the others see. Whatever the mix, measure the coverage gap against the network node and software inventories rather than against the scanner's own target list.
Where identity fits
Authenticated scanners and enumeration agents hold some of the most powerful machine credentials in an estate: domain accounts or SSH keys that can log in to every server, and cloud roles that can read every account. Treat them as privileged non-human identities. Store scan credentials in a vault, scope them to read-only queries where the scanner supports it, rotate them, and alert on their use from any host other than the scanner. The enumeration record should also carry the identities each asset runs under, so a critical finding on a host immediately shows which service accounts and keys are exposed with it. See the NHI Discovery Guide for building that link.
How to build it
- Fix the inventory baseline first. Reconcile network node, software and hardware inventories so every asset has an owner and a stable ID. Unowned assets produce findings no one fixes.
- Choose the advisory sources. At minimum: your scanner's vulnerability content, vendor advisories for your main platforms, an open source advisory feed in OSV format for application dependencies, the KEV catalogue and EPSS. Record how often each is refreshed.
- Normalise identifiers. Map inventory product names to CPE where possible and keep purl for open source components. Keep a mapping table for products the scanner names inconsistently.
- Pilot on one estate. Run enumeration for a single business unit or cloud account, compare results with a manual check of ten to twenty assets, and record false positives (usually backported fixes) and misses (usually unmanaged software).
- Add suppression with evidence. Accept VEX statements from suppliers and record internal "not affected" decisions with one of the CISA justification values, an approver and an expiry date. Never suppress without a record.
- Attach priority. Flag KEV entries, add EPSS probability and percentile, and route through an SSVC-style decision or your own policy. Example service levels, such as KEV entries on internet-facing assets within days, are your policy choice, not a D3FEND requirement.
- Feed remediation and roll back cleanly. Send findings to patching and configuration owners with the fixed version. When a new feed or matching rule causes a flood of findings, revert to the previous rule set and investigate before re-enabling, rather than letting owners learn to ignore the queue.
How to verify it works
- Known-vulnerable canary: keep a test host or image with a deliberately old, isolated package version and confirm each scanner and feed reports it after every content update.
- New CVE drill: when a high-profile CVE is published, time how long it takes to answer "which assets run the affected version" from the enumeration data alone.
- Coverage reconciliation: compare assets with a recent enumeration result against the network node inventory weekly, and list the difference by owner.
- Suppression audit: sample "not affected" decisions each quarter and confirm the justification still holds after upgrades.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | What it shows |
|---|---|---|
| Inventory assets with a vulnerability result in the last 7 days | Above 95% for servers and endpoints | Enumeration coverage, not scanner coverage |
| Time from CVE publication to affected-asset list | Under 24 hours for critical CVEs | Whether identifiers and feeds actually join |
| Open KEV findings past your internal due date | Zero | Prioritisation is driving work |
| Suppressions without justification or expiry | Zero | Suppression discipline |
| Findings rejected by owners as false | Falling quarter on quarter | Matching quality and trust in the data |
ATT&CK techniques D3FEND relates to D3-AVE
Relationship type: inferred only. D3FEND derives these links because D3-AVE evaluates Software and, through D3-CIA, Container Images, which are the artefacts the techniques below abuse or modify (D3FEND 1.6.0, checked November 2026). They show where an unpatched or tampered component gives an attacker a foothold; they are not a claim that D3-AVE detects the technique. Every ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND lists |
|---|---|
| Initial Access | T1195.001 Compromise Software Dependencies and Development Tools, T1195.002 Compromise Software Supply Chain |
| Execution and Lateral Movement | T1072 Software Deployment Tools |
| Persistence | T1505.001 SQL Stored Procedures, T1505.004 IIS Components, T1137.006 Add-ins, T1547.008 LSASS Driver, T1546.011 Application Shimming, T1554 Compromise Host Software Binary, T1525 Implant Internal Image |
| Persistence and Stealth (pre-OS) | T1542.001 System Firmware, T1542.002 Component Firmware, T1542.003 Bootkit, T1542.004 ROMMONkit, T1014 Rootkit |
| Stealth and Execution | T1574.005 Executable Installer File Permissions Weakness, T1574.010 Services File Permissions Weakness, T1127.001 MSBuild, T1218.014 MMC, T1564.006 Run Virtual Instance, T1497.003 Time Based Checks |
| Credential Access and Collection | T1212 Exploitation for Credential Access, T1649 Steal or Forge Authentication Certificates, T1056.003 Web Portal Capture |
| Impact | T1490 Inhibit System Recovery, T1489 Service Stop |
The useful reading is practical: firmware rows argue for including firmware versions in the enumeration, and supply chain rows argue for SBOM matching of third-party components, not only operating system packages.
Common failure patterns
- Enumerating the scanner's target list, not the inventory: assets nobody added to a scan never appear as vulnerable, so the dashboard looks clean while unmanaged hosts stay exposed.
- Version strings without backport awareness: distribution packages often carry security fixes without changing the upstream version, so naive version matching floods owners with false findings until they stop trusting the data.
- Severity-only ranking: sorting by CVSS base score alone puts thousands of "critical" items ahead of a medium-scored CVE that is in the KEV catalogue.
- Silent suppression: exceptions created to quiet a report, with no justification or expiry, which then hide the same CVE on new assets.
- Stale SBOMs: matching against the component list from an old build while production runs a newer or older release.
- Unprotected scan credentials: a domain-wide scan account with a static password stored in the scanner, which becomes the attacker's lateral movement key.
Framework mapping
| Framework | Reference | Relevance to D3-AVE |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 | Vulnerabilities in assets are identified, validated and recorded |
| NIST CSF 2.0 | ID.AM-01, ID.AM-02 | The hardware and software inventories D3-AVE enriches |
| NIST CSF 2.0 | ID.RA-08 | Processes for receiving and responding to vulnerability disclosures, which feed advisory sources |
| NIST SP 800-53 Rev. 5 | RA-5, RA-5(2) | Vulnerability monitoring and scanning; updating the vulnerabilities to be scanned |
| NIST SP 800-53 Rev. 5 | CM-8, SI-2 | System component inventory; flaw remediation that consumes the findings |
| NIST SP 800-40 Rev. 4 | Enterprise patch management planning | Identifying, prioritising, acquiring, installing and verifying patches downstream of enumeration |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management | Ongoing assessment and tracking of vulnerabilities across enterprise assets |
| MITRE D3FEND | D3-AI, D3-AVE, D3-CIA | Parent, technique and child |
For the control-level detail see the CIS Control 7 Continuous Vulnerability Management Guide and the Risk-Based Vulnerability Management Guide.
Related countermeasures
- Software Inventory (D3-SWI): the component list D3-AVE enriches. See D3-SWI Software Inventory.
- Configuration Inventory (D3-CI): many findings are misconfigurations rather than CVEs. See D3-CI Configuration Inventory.
- Container Image Analysis (D3-CIA): the child technique for images in registries and pipelines.
- Software Update (Harden tactic): the countermeasure that consumes D3-AVE output and closes the findings.
Practitioner checklist
- Measure enumeration coverage against the inventory, not the scanner target list.
- Record exact versions and firmware, and keep CPE and purl identifiers on inventory items.
- Ingest KEV and EPSS daily and show them beside every finding.
- Require a CISA VEX justification, an approver and an expiry for every "not affected" decision.
- Re-match SBOMs of deployed releases when new advisories arrive.
- Vault, scope and monitor every scan credential as a privileged non-human identity.
- Keep a known-vulnerable canary and confirm it is detected after each content update.
- Time the new CVE drill and report it to leadership with the coverage metric.
Standards and references
- MITRE D3FEND: Asset Vulnerability Enumeration (D3-AVE)
- NIST: Common Platform Enumeration (CPE)
- OpenSSF: Open Source Vulnerability (OSV) schema
- CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
- FIRST: Exploit Prediction Scoring System (EPSS)
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
- CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
- NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
Related NHI Mgmt Group resources: MITRE D3FEND Asset Inventory Implementation Guide · Vulnerability Scanning Guide · CISA KEV Catalogue Guide · EPSS Guide · MITRE D3FEND Guide