Screenshots and/or screen recording
Fleet's Software Inventory correctly identifies installed .NET packages on Windows hosts (e.g., "Microsoft .Net Native Framework Package", "Microsoft .NET Core Runtime", "Microsoft .NET Core Host"), but the Vulnerabilities column shows "---" (none) for all of them, even for versions with known Critical/High CVEs.
Problem
Fleet's vulnerability management enumerates .NET Framework/.NET Core software as installed programs (inventory works correctly), but it does not match these installed .NET versions against known CVEs. So the gap is in CVE detection/matching for .NET, not in software inventory. As a result, hosts running vulnerable .NET versions show zero vulnerabilities for that software, giving customers false confidence in their patch posture.
Example gap observed
In a recent customer environment review, several Critical/High .NET CVEs were identified manually (via other tooling) that Fleet did not surface despite the affected .NET software being present in Fleet's inventory:
One host had the most .NET CVEs (~38) due to older, unpatched .NET versions dating back to March 2021. Other Windows hosts in the same environment were missing only the Oct 2024 and Jul 2026 .NET cumulative updates. Remediation in all cases is applying the relevant .NET cumulative update — the same class of patch Fleet already surfaces for other OS-level vulnerabilities.
Why this matters
- .NET is ubiquitous in enterprise Windows environments (internal apps, agents, services), and Fleet already tracks it as installed software.
- .NET CVEs are frequently Critical/High severity (RCE, privilege escalation) and are patched via frequent cumulative updates.
- Because the software is already inventoried but shows no vulnerabilities, this isn't a visibility gap customers can easily notice — it looks like the host is compliant when it isn't.
Ideal workflow
- For each installed .NET Framework/.NET Core/.NET (5+) package already captured in Fleet's software inventory, Fleet checks the version against NVD/vendor advisories (similar to how Fleet matches other software CVEs).
- Applicable CVEs populate the Vulnerabilities column for that software in Inventory, and roll up into the Vulnerabilities tab with CVE, CVSS, affected hosts, and remediation guidance (i.e., which cumulative update to apply).
- This should work for both legacy .NET Framework (versions identified via the NDP registry key scheme, e.g. 4.x release numbers) and modern .NET/.NET Core (versions like 3.1.x, 6.x, 8.x).
Interpretation
Fleet already has the raw data needed (.NET software name + version in inventory) but lacks a NVD/vendor CVE feed or matching logic for these products, so vulnerable .NET installs are silently reported as "no vulnerabilities." Closing this gap means adding .NET to Fleet's existing software vulnerability-matching pipeline, not building new inventory collection.
Screenshots and/or screen recording
Fleet's Software Inventory correctly identifies installed .NET packages on Windows hosts (e.g., "Microsoft .Net Native Framework Package", "Microsoft .NET Core Runtime", "Microsoft .NET Core Host"), but the Vulnerabilities column shows "---" (none) for all of them, even for versions with known Critical/High CVEs.
Problem
Fleet's vulnerability management enumerates .NET Framework/.NET Core software as installed programs (inventory works correctly), but it does not match these installed .NET versions against known CVEs. So the gap is in CVE detection/matching for .NET, not in software inventory. As a result, hosts running vulnerable .NET versions show zero vulnerabilities for that software, giving customers false confidence in their patch posture.
Example gap observed
In a recent customer environment review, several Critical/High .NET CVEs were identified manually (via other tooling) that Fleet did not surface despite the affected .NET software being present in Fleet's inventory:
One host had the most .NET CVEs (~38) due to older, unpatched .NET versions dating back to March 2021. Other Windows hosts in the same environment were missing only the Oct 2024 and Jul 2026 .NET cumulative updates. Remediation in all cases is applying the relevant .NET cumulative update — the same class of patch Fleet already surfaces for other OS-level vulnerabilities.
Why this matters
Ideal workflow
Interpretation
Fleet already has the raw data needed (.NET software name + version in inventory) but lacks a NVD/vendor CVE feed or matching logic for these products, so vulnerable .NET installs are silently reported as "no vulnerabilities." Closing this gap means adding .NET to Fleet's existing software vulnerability-matching pipeline, not building new inventory collection.