When a new vulnerability or a poisoned update is announced, the organisations that respond in hours are the ones that already know which hosts run the affected software and version. D3-SWI Software Inventory is the MITRE D3FEND technique for that knowledge: D3FEND defines it as identifying and recording "the software items in the organization's architecture", with the synonyms Software Discovery and Software Inventorying. It sits in the Model tactic under Asset Inventory and inventories the Software artefact. This page covers what to record, the collection methods D3FEND names and their limits, how to keep the inventory current, how to verify it, and what it feeds. It is written for endpoint, vulnerability management and platform teams. For the parent technique and its siblings, see the D3FEND Asset Inventory Implementation Guide.
Key takeaways
- Query the node first, enumerate the network second. D3FEND describes administrators querying nodes with management tools, and falling back to network enumeration of responding services only where queries are not supported.
- Installed is not the same as running. The Host Resources MIB keeps separate installed and running tables, and its authors note that some running software never appears in the installed list.
- Collection methods have side effects. D3FEND warns that scanning can disturb IT and OT systems, and Microsoft warns that querying the Win32_Product WMI class triggers a Windows Installer consistency check and repair.
- Inventory activity looks like attacker discovery. D3FEND notes that adversary enumeration parallels normal inventorying, so the collector's privileges and behaviour must be known and monitored.
- The inventory is an input, not an outcome. Its value appears in vulnerability enumeration, allowlisting and supply chain response, which all fail when versions are missing or stale.
D3-SWI at a glance
| Field | D3-SWI Software Inventory |
|---|---|
| D3FEND ID | D3-SWI |
| Tactic | Model |
| Parent technique | Asset Inventory |
| Digital artefact | Inventories Software |
| Synonyms | Software Discovery, Software Inventorying |
| D3FEND examples | Application-layer discovery: SNMP collecting MIB information; WBEM collecting CIM information, including WMI and Windows Management Infrastructure (MI) |
| D3FEND references | DMTF Web-Based Enterprise Management; Microsoft Windows Management Instrumentation; Microsoft Windows Management Infrastructure |
| Typical output | Per-host list of software name, publisher, version, install path and source, linked to the node inventory and to SBOMs |
What to record
A software inventory that supports security decisions needs more than a product name. As a working minimum (our recommendation, not a D3FEND requirement):
- Identity of the software: publisher, product, exact version and build, in a normalised form that vulnerability feeds can match. Standard identifiers help: NIST IR 8060 gives guidelines for interoperable Software Identification (SWID) tags, which are defined in ISO/IEC 19770-2.
- Where it lives: host or image, install path, and whether it is installed, running or both.
- How it got there: package manager, installer, deployment tool, container image or user install, so unapproved sources stand out.
- Components inside it: for in-house and supplier applications, link an SBOM. CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components.
- Ownership and lifecycle: business owner, support status and end-of-life date. See the Operating System End of Life and Extended Support Guide.
- Last seen: collection time and source, so stale records age out rather than linger.
Collection methods and their limits
| Method | What it returns | Limits and cautions |
|---|---|---|
| WBEM and CIM (DMTF) | Standardised management data over CIM Operations over HTTP (DSP0200) or WS-Management (DSP0226) | Needs authenticated management access; coverage depends on the providers installed on each host |
| WMI and Windows MI | Windows implementations of CIM, queried locally or remotely | Avoid Win32_Product: Microsoft states it is not query optimised and that enumerating it starts a consistency check that verifies and repairs installed packages |
| SNMP Host Resources MIB (RFC 2790) | hrSWInstalledTable (name, product ID, type, date) and hrSWRunTable (running software, path, parameters) | The installed group is optional; it excludes software run from network storage; implementations differ between executables and packages; use SNMPv3 |
| Operating system package databases | Packages and versions as recorded by the platform package manager | Misses software copied into place, language-level packages and portable binaries |
| Endpoint management and security agents | Installed applications, often with running processes and file hashes | Only managed hosts; agent gaps hide the least-managed systems |
| SBOMs and image scanning | Components inside applications and container images | Only as complete as the SBOM generator and only for artefacts that have one |
| Network enumeration of responding services | Service banners and versions seen on the network | D3FEND's fallback; can disturb IT and OT systems and sees only listening software |
Use more than one method and reconcile them: an application seen running but absent from the installed list is either portable, network-hosted or a finding. For container estates, image analysis is the inventory source; see D3-CIA Container Image Analysis.
Where identity fits
Remote inventory needs credentials that can log in to, or query, every host: WMI accounts, SNMPv3 users, agent enrolment tokens and API keys for cloud inventories. D3FEND points out that most enumeration through administrative tools needs administrator privileges, which is exactly why these accounts are attractive to attackers. Give each collector its own identity, the narrowest read rights the platform allows, an owner and a rotation schedule, and alert when that identity is used from anywhere other than the collector. See the Service Account Inventory Template.
How to build and maintain it
- Anchor to the node inventory. Every software record should hang off a known host, image or account. See D3-NNI Network Node Inventory.
- Choose collection per platform. Agent or management interface for managed endpoints and servers, package databases for Linux, image scanning for containers, SBOM ingestion for applications, passive or vendor-approved methods for OT.
- Pilot and watch for side effects. Run collection on a test ring first, measure load and errors, and confirm that no query triggers installer repairs or service disruption. Keep the previous collection method available as the rollback.
- Normalise names and versions. Map raw strings to a standard publisher, product and version so the same product is counted once and matches vulnerability data.
- Define the authorised baseline. Record which software is approved, for which hosts, which turns the inventory into a basis for allowlisting. See the Application Allowlisting Guide.
- Keep it current. Update on install and removal events as well as on a schedule, age out records not seen recently, and alert on new unapproved software on sensitive hosts.
- Connect consumers. Feed the inventory to vulnerability enumeration, end-of-life tracking and incident response lookups.
What the inventory feeds
| Consumer | How D3-SWI helps |
|---|---|
| Vulnerability enumeration | Match versions to advisories without waiting for a network scan; see D3-AVE Asset Vulnerability Enumeration |
| Supply chain response | Answer "where do we run this compromised package or update?" within hours; see the SBOM operations guide |
| Allowlisting and hardening | The approved list becomes the allow rule set; unknown items become review tasks |
| Detection | New software on a server, or a known tool appearing on an unexpected host, is a lead for investigation |
| Configuration baselines | Software versions pair with settings in D3-CI Configuration Inventory |
ATT&CK relationships
Relationship type: inferred only. D3FEND's technique page (checked November 2026) lists offensive techniques related to D3-SWI through the shared Software artefact and marks these inferences experimental. They mean the technique acts on software that an inventory records, not that the inventory detects it. The rows are grouped by ATT&CK v20 tactic; IDs were checked against ATT&CK v20, and techniques that sit in two tactics are listed once.
| Tactic (ATT&CK v20) | Techniques D3FEND relates to D3-SWI | Where an inventory helps (NHI Mgmt Group view) |
|---|---|---|
| Initial Access | T1195.001 Compromise Software Dependencies and Development Tools; T1195.002 Compromise Software Supply Chain | Strongest case: locating every host that runs an affected version |
| Execution and Lateral Movement | T1072 Software Deployment Tools | Knowing which deployment tools exist and where |
| Persistence | T1137.006 Add-ins; T1176 Software Extensions; T1505.001 SQL Stored Procedures; T1505.004 IIS Components; T1546.011 Application Shimming; T1547.008 LSASS Driver; T1554 Compromise Host Software Binary | New add-ins, extensions and components show up as inventory changes if the inventory records them |
| Stealth | T1014 Rootkit; T1127.001 MSBuild; T1218.014 MMC; T1542.001 System Firmware; T1542.002 Component Firmware; T1542.003 Bootkit; T1542.004 ROMMONkit; T1564.006 Run Virtual Instance; T1574.005 Executable Installer File Permissions Weakness; T1574.010 Services File Permissions Weakness; T1497.003 Time Based Checks | Limited: rootkits and firmware implants hide from the interfaces inventories use; unexpected virtualisation software on a workstation is a finding |
| Collection and Credential Access | T1056.003 Web Portal Capture; T1212 Exploitation for Credential Access; T1649 Steal or Forge Authentication Certificates | Indirect: version data shows which exploitable software is present |
| Impact | T1489 Service Stop; T1490 Inhibit System Recovery | Indirect: knowing which backup and recovery software runs where |
See MITRE ATT&CK T1195 Supply Chain Compromise and MITRE ATT&CK T1072 Software Deployment Tools. Attackers run their own version of this technique; see T1518 Software Discovery.
How to verify it works
- Known-answer test: install a harmless, uniquely named test package on a sample of hosts in each platform ring and confirm it appears with the right version within the expected collection interval, then disappears after removal.
- Advisory drill: take a recent advisory and time how long it takes to list every affected host and version from the inventory alone.
- Cross-source reconciliation: compare agent data, package databases and network-observed services for the same hosts and investigate disagreements.
| Metric (example measures, not a standard) | What it shows |
|---|---|
| Share of known hosts and images with a software inventory collected in the last 7 days (example window) | Coverage and freshness |
| Share of software records with a normalised publisher, product and version | Usability for vulnerability matching |
| Unapproved software items on servers, and their age | Drift from the authorised baseline |
| Time from advisory to complete affected-host list | Operational value in response |
| Software at or past end of support | Lifecycle exposure |
Common failure patterns
- Agent coverage taken as estate coverage: unmanaged servers, appliances and OT systems are often the ones running the oldest software.
- Using a collection query with side effects: Win32_Product queries run installer consistency checks and can log event 11708 installation failures on hosts where the account lacks access, according to Microsoft.
- Names without versions: "Java" or "OpenSSL" without build numbers cannot be matched to an advisory.
- Installed list only: portable tools, network-hosted binaries and language packages run without ever appearing as installed products.
- Over-privileged collectors: one domain admin account used for inventory across the estate gives an attacker the same reach.
- No feedback loop: unapproved software is reported every week and never removed or approved.
Framework mapping
| Framework | Reference | Relationship to D3-SWI |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02 | Inventories of software, services and systems are maintained |
| NIST CSF 2.0 | ID.AM-08 | Systems, hardware, software, services and data are managed throughout their life cycles |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory; CM-8(1) Updates During Installation and Removal; CM-8(3) Automated Unauthorized Component Detection | Inventory, update on change and detection of unauthorised software |
| NIST SP 800-53 Rev 5 | CM-7(5) Authorized Software, Allow-by-exception; CM-10 Software Usage Restrictions; CM-11 User-installed Software | Controls that depend on knowing what is installed |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets | Actively manage all operating systems and applications on the network |
Practitioner checklist
- Link every software record to a known host, image or account.
- Use at least two collection methods per platform and reconcile them.
- Remove Win32_Product from inventory scripts and tools in favour of side-effect-free sources.
- Record exact versions in a normalised form that matches vulnerability feeds.
- Ingest SBOMs for in-house and critical supplier applications.
- Give collectors their own least-privilege identities, stored in a secrets manager and monitored for use elsewhere.
- Maintain an authorised software baseline and act on unapproved items.
- Run an advisory drill each quarter and track time to a complete affected-host list.
Standards and references
- MITRE D3FEND: Software Inventory (D3-SWI)
- DMTF: Web-Based Enterprise Management (WBEM)
- Microsoft: Win32_Product class
- IETF: RFC 2790 Host Resources MIB
- NIST: IR 8060 Guidelines for the Creation of Interoperable SWID Tags
- CISA: Software Bill of Materials (SBOM)
- CIS: Control 2 Inventory and Control of Software Assets
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: D3FEND Asset Inventory Implementation Guide · Asset Inventory and CMDB Security Guide · SBOM Guide · Application Allowlisting Guide · MITRE D3FEND Guide