A scanner report lists vulnerabilities per host or per package, but risk lives at the level of a system: the same flaw can be unreachable in one system and the easiest route to critical data in another. MITRE D3FEND names the countermeasure that closes this gap System Vulnerability Assessment (D3-SYSVA) and defines it as relating "all the vulnerabilities of a system's components in the context of their configuration and internal dependencies", which "can also include assessing risk emerging from the system's design as a whole, not just the sum of individual component vulnerabilities." It sits under the Model tactic as a child of System Mapping (D3-SYSM). This page explains what the technique models, the inputs it needs, how to build it on top of existing scanning, how to measure it and where it commonly fails. It is written for vulnerability management leads, security architects and risk owners.
Key takeaways
- It is system-level, not finding-level. D3-SYSVA starts from component findings and asks what they mean for a named system given its configuration and dependencies.
- Design risk counts. D3FEND explicitly includes risk from the system's design as a whole, such as a single shared credential or an exposed management path, which no component scanner reports.
- It depends on the other models. Without System Dependency Mapping and an asset and software inventory, there is no system to assess, only a list of findings.
- Exploitability context reduces noise. Vulnerability Exploitability eXchange (VEX) statements, exploitation evidence and a decision method such as SSVC turn context into priorities.
- One inferred ATT&CK relation. D3FEND relates D3-SYSVA, by inference, only to Downgrade Attack, which is T1689 in ATT&CK v20.
D3-SYSVA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-SYSVA (d3f:SystemVulnerabilityAssessment) |
| Tactic | Model |
| Parent technique | System Mapping (D3-SYSM) |
| Siblings | System Dependency Mapping (D3-SYSDM), Service Dependency Mapping (D3-SVCDM), Data Exchange Mapping (D3-DEM) |
| Ontology relations | evaluates Digital System; identifies Vulnerability |
| Related ATT&CK technique (inferred) | Downgrade Attack, T1689 in ATT&CK v20 |
| D3FEND reference | Software vulnerability graph database patent (Veracode) |
| Typical inputs | Component findings, SBOMs, VEX statements, configuration data, dependency model, exploitation intelligence, system criticality |
| Typical outputs | A per-system vulnerability and design risk view with prioritised actions and owners |
What D3FEND means by system vulnerability assessment
The D3FEND entry is brief: a definition and one reference, with no separate "how it works" or considerations text as of November 2026. Two ideas carry the technique.
- Context of configuration and dependencies: a vulnerable function in a library matters only if the system loads that library, the vulnerable feature is enabled and an attacker can reach it. The cited patent describes a graph database that catalogues vulnerabilities in open source components and represents relationships within them, which is the kind of structure that makes this context queryable.
- Emergent design risk: the system as a whole can be weaker than its parts, for example when every component is patched but one service account has administrative rights across all tiers, or when an internal management interface is reachable from a less trusted zone.
It differs from Asset Vulnerability Enumeration (D3-AVE), which lists vulnerabilities per asset, and from Network Vulnerability Assessment (D3-NVA), which looks at network-level weaknesses. D3-SYSVA consumes their output. See the D3-AVE Asset Vulnerability Enumeration and the D3-NVA Network Vulnerability Assessment.
Inputs and what each contributes
The table is NHI Mgmt Group guidance on inputs, not part of D3FEND.
| Input | Source | Question it answers |
|---|---|---|
| Component findings | Authenticated host scans, container image scans, software composition analysis | Which known vulnerabilities exist in which components |
| SBOM | Build pipeline, supplier deliveries (CycloneDX or SPDX) | Which components and versions the system contains |
| VEX statements | Suppliers and internal product teams | Whether a product is actually affected by a listed vulnerability (CISA describes VEX as an attestation, a form of security advisory) |
| Dependency model | System Dependency Mapping, Service Dependency Mapping | Which systems load the component and what relies on them |
| Configuration state | Configuration inventory, hardening benchmarks | Whether the vulnerable feature is enabled and reachable |
| Exploitation intelligence | CISA Known Exploited Vulnerabilities catalogue, EPSS | Whether attackers are using or likely to use it |
| Criticality and data | Operational Dependency Mapping, business impact analysis, data inventory | What the system supports and what it holds |
| Identities and trust paths | Service account inventory, identity provider, secrets manager | Which credentials a compromise exposes and where they lead |
How to build it
- Start from mapped systems. Take the critical systems that already have a dependency model. See the D3-SYSDM System Dependency Mapping.
- Join findings to the model. Attach scanner and software composition findings to the components in each system's model, using package identifiers and versions rather than host names alone.
- Apply affectedness context. Use supplier and internal VEX statements to mark findings as not affected, affected, fixed or under investigation, and record the justification for any "not affected" status.
- Assess reachability and configuration. For each remaining high-severity finding, record whether the vulnerable feature is enabled, whether it is exposed to untrusted networks and what identity the component runs as.
- Review design risk. Once per system, with the architect, look for whole-system weaknesses: shared or over-privileged service accounts, flat trust between tiers, legacy protocol versions still accepted, single points of failure and management paths from lower trust zones.
- Decide with a method. Use a documented decision method such as CISA's SSVC, whose decision points include exploitation status, technical impact, automatability, mission prevalence and public well-being impact, and whose outcomes are Track, Track*, Attend and Act. See the SSVC Guide.
- Hand off and re-assess. Send actions to the system owner through the patch or change process, and re-run the assessment when the SBOM, configuration or dependency model changes. See the Patch Management Guide.
Pilot on two or three systems, compare the resulting priorities with the plain severity ranking, and check the differences with the system owners before scaling. Because the technique produces assessments rather than changes, roll back means reverting to the previous prioritisation method, not undoing system changes.
The inferred ATT&CK relation
The D3FEND page for D3-SYSVA lists one offensive technique, Downgrade Attack, and states that its offensive mappings are inferred, experimental and will improve as the knowledge graph grows. D3FEND shows it under the older Impair Defenses sub-technique ID, which ATT&CK v20 has revoked; the current technique is T1689 Downgrade Attack. The practical link, in NHI Mgmt Group's reading, is that a system-level assessment is where accepted legacy protocol and cipher versions show up as a design weakness even when every component is patched. See the MITRE ATT&CK T1689 Downgrade Attack.
Where identity fits
Many of the design risks that component scanners miss are identity risks: one service account used by every tier, an API key with broader rights than the dependency needs, or a long-lived certificate trusted across environments. Including the non-human identities on each dependency edge in the assessment shows the real consequence of a component flaw, which is often the credential it exposes rather than the host. See the Identity Attack Paths Guide.
Detection and measurement
Metrics we suggest (targets are examples, not standards):
| Metric | What it shows | Example target |
|---|---|---|
| Critical systems with a current system-level assessment | Coverage | 100%, refreshed at each major change |
| Share of high-severity findings with affectedness and reachability recorded | Depth of context | Over 90% for critical systems |
| Design risks identified per system and their age | Whether whole-system weaknesses are found and closed | No design risk open beyond its agreed date |
| Time from a new KEV entry to a per-system affected list | Speed of contextual triage | Within one working day |
| Share of "not affected" decisions with a recorded justification | Quality and auditability of suppression | 100% |
Limits and common failure patterns
- Calling a scan an assessment. A sorted scanner export has no system boundary, no dependencies and no design view.
- Undocumented suppressions. Marking findings "not affected" without a VEX justification or evidence hides real exposure and fails audit.
- Stale dependency data. Context is only as good as the model beneath it; an assessment built on last year's SBOM gives confident wrong answers.
- Skipping design review. Component-only assessment misses shared credentials, flat trust and legacy protocol acceptance, the risks D3FEND specifically names as emerging from the design.
- Severity-only ranking. CVSS base scores describe the flaw, not the system; pair them with exploitation evidence and criticality. See the Vulnerability Prioritisation Guide.
Framework mapping
D3FEND does not map D3-SYSVA to other frameworks. The table is NHI Mgmt Group's reading.
| Framework | Reference | How D3-SYSVA supports it |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01, ID.RA-04, ID.RA-05 | Vulnerabilities identified, validated and recorded; impacts and likelihoods recorded; risk used to prioritise response |
| NIST SP 800-53 Rev. 5 | RA-3 Risk Assessment, RA-5 Vulnerability Monitoring and Scanning, RA-9 Criticality Analysis, SA-17 Developer Security and Privacy Architecture and Design | System risk assessment, scan input, critical component focus and design-level review |
| NIST SP 800-40 Rev. 4 | Enterprise patch management planning | Feeds prioritised, system-aware remediation into patching |
| ISO/IEC 27001:2022 Annex A | 8.8 Management of technical vulnerabilities | Evaluating exposure to technical vulnerabilities and taking measures |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management | Risk-based remediation of findings. See the CIS Control 7 Continuous Vulnerability Management Guide. |
Practitioner checklist
- Define the system boundary and dependency model before assessing.
- Join findings to components by package identifier and version.
- Record VEX status and justification for every suppressed finding.
- Record reachability, enabled features and running identity for high-severity findings.
- Hold a design risk review per critical system at least once a year and after major change (an example interval).
- Prioritise with a documented method using exploitation evidence and criticality.
- Re-assess automatically when SBOM, configuration or dependencies change.
- Track design risks to closure with named owners.
Standards and references
- MITRE D3FEND: System Vulnerability Assessment (D3-SYSVA)
- MITRE D3FEND: System Mapping (D3-SYSM)
- Veracode: Software vulnerability graph database (WO2020028535A1)
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
- CISA: Software Bill of Materials (SBOM) and VEX
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- OSV: Open Source Vulnerabilities database
Related NHI Mgmt Group resources: MITRE D3FEND System Mapping implementation guide · Risk-Based Vulnerability Management Guide · SBOM Guide · CISA KEV Catalogue Guide · MITRE D3FEND Guide