Back
Make Sense of It All: NVD’s New Affected Products and What They Mean

Make Sense of It All: NVD’s New Affected Products and What They Mean

TIPS Publication date: 2026-10-07

Keeping track of vulnerable software sounds simple: list the software you use and compare it with known vulnerabilities. In practice, the terminology quickly becomes confusing. The NVD uses CPEs and Known Affected Software Configurations, CVE records can contain their own affected-product information, and software inventories rarely use any of those formats.

NVD is now making Affected Products much more visible and useful. This information does not replace CPEs, but it provides another important piece of the puzzle and can help identify vulnerable products even when NVD has not created a CPE-based configuration.

CPEs: giving software a common identity

A Common Platform Enumeration (CPE) is a standardized identifier for software, operating systems and hardware. Google Chrome, for example, can be represented by a CPE such as:

cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*

The value of CPE becomes clear when looking at a real software inventory. One organisation might enter Google Chrome, another Chrome Browser, and another simply Chrome. These names can all be normalized to the same product and associated with the same CPE.

That gives vulnerability management systems a common language. Instead of trying to determine whether two arbitrary pieces of text mean the same thing, they can compare standardized product identities.

A CPE does not mean a product is vulnerable

This distinction is important. A CPE identifies a product; by itself it does not say that the product is vulnerable.

NVD's Known Affected Software Configurations build on CPEs by adding applicability information, including affected version ranges and sometimes relationships with operating systems or other products. NVD might therefore identify Google Chrome through its CPE and specify that versions below a particular release are affected. More complicated configurations can say that a particular version is affected when it runs on Windows, Linux or macOS.

These configurations are powerful, but they can also be difficult to compare with a customer's inventory. A customer may simply tell BaseFortify that it uses Google Chrome 149.0.7827.120. It may not record every operating system or dependency necessary to evaluate a complex NVD configuration.

So what are Affected Products?

Affected Products come from structured information contained in CVE records, generally supplied by the organisation responsible for assigning or publishing the CVE. They can identify the vendor, product and affected versions directly.

Consider CVE-2026-12576, for example. NVD has not produced a traditional CPE configuration for this vulnerability, but its CVE data identifies Delta DVP80ES3 and states that versions through 1.06.00 are affected.

A customer might have entered Delta DVP80ES3 1.05.00. There is no need to wait for an NVD CPE to notice the relationship. The vendor and product correspond, and version 1.05.00 falls within the reported affected range. That provides useful early-warning information, even though NVD has not completed the CPE-based enrichment traditionally used for matching.

Affected Products do not replace CPEs. They give us another reliable way to connect a CVE to the software an organisation actually uses — often before full NVD enrichment is available.

How the pieces fit together

It helps to think of the information as coming from different stages of the vulnerability process. The CVE source can say, in effect, "our product, versions X through Y, is affected." NVD can subsequently enrich vulnerability information with standardized CPE identities and more detailed applicability configurations.

Sometimes both are available. Sometimes only the affected-product information is available. And sometimes the available information is incomplete enough that additional analysis is necessary. For vulnerability management, the important question should therefore not be "Does this CVE have a CPE?" but rather "What reliable information do we have that connects this vulnerability to a component in our inventory?"

Matching what customers actually enter

This is where BaseFortify's canonical component approach becomes important. Customers should not need to know what a CPE is simply to maintain their software inventory.

A customer can enter Microsoft Office 2024, Google Chrome 149, Citrix Workspace App or Apache Tomcat 10.1. BaseFortify can normalize those names into known products and then use the vulnerability information available for them.

An official NVD CPE may provide the strongest and most standardized route. Structured Affected Products can provide another route, particularly for newly published or not-yet-enriched CVEs. Where structured identifiers are unavailable, BaseFortify can use additional analysis to establish likely product relationships.

This becomes even more important for packages and libraries. Components such as log4j-core, spring-webmvc, urllib3 or lodash do not always fit as comfortably into a CPE-centric software inventory. Modern CVE records can also contain package information, giving vulnerability management systems additional ways to connect what developers actually use with published vulnerabilities.

From different sources to one understandable result

The goal is not to make users choose between CPEs, Known Affected Software Configurations and Affected Products. Those are implementation details of the vulnerability ecosystem. What matters to a BaseFortify user is something much simpler: I use this component. Is it affected, and why do you think so?

BaseFortify can use the available evidence to answer that question while retaining where the information came from. A match based on an official NVD CPE configuration can be distinguished from an early match based on structured Affected Products, rather than presenting all matches as though they were established in exactly the same way.

NVD's increasing use of Affected Products therefore adds another valuable source of vulnerability intelligence. Combined with CPEs, configuration information and normalized customer inventories, it helps close the gap between the way vulnerability databases describe software and the way organisations actually record the components they use.

For BaseFortify, that is ultimately the objective: you maintain a recognizable inventory of your software components, while BaseFortify makes sense of the vulnerability data behind it.

Sources and further reading