CPE Identifiers Explained: A Practical Guide for Security Teams

If your security team tracks vulnerabilities, you've almost certainly encountered CPE identifiers—those long, colon-separated strings that appear in NVD entries and vulnerability scanners. But what exactly do they mean, and how can you use them in practice?

This guide breaks down the CPE naming convention, explains each field in a CPE identifier, and shows how security teams can use them to connect technology detection to vulnerability management with real-world examples.

What Is CPE?

Common Platform Enumeration (CPE) is a standardized naming scheme for IT products, maintained by NIST (National Institute of Standards and Technology). It provides a structured way to identify applications, operating systems, and hardware devices using a machine-readable format.

CPE is the backbone of how the National Vulnerability Database (NVD) catalogs which products are affected by each vulnerability. When a new CVE is published, the NVD associates it with one or more CPE identifiers so that tools and teams can match their software inventory against known security issues.

The CPE Naming Convention Breakdown

The current CPE specification is version 2.3, which uses a formatted string binding. The full format is:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

That's 13 fields separated by colons. Here's what each one means:

In practice, most web technologies use just the first six meaningful fields (part, vendor, product, and version), with the remaining fields set to * (any value). The asterisk is a wildcard that matches anything.

The Part Field

The part field tells you what category the product falls into:

• a — Application: Software that runs on an operating system (jQuery, WordPress, Nginx, Apache HTTP Server)
• o — Operating System: The OS itself (Linux, Windows Server, macOS)
• h — Hardware: Physical devices (routers, switches, IoT devices)

For web technology detection, nearly every CPE you encounter will have a as the part, since you're identifying software running on web servers.

Practical Examples with DetectZeStack

When DetectZeStack detects a technology on a website, it returns the corresponding CPE identifier. Here are real-world examples showing how common web technologies map to their CPE identifiers:

jQuery 3.6.0

cpe:2.3:a:jquery:jquery:3.6.0:*:*:*:*:*:*:*

The vendor and product are both jquery. The version 3.6.0 is pinned, which means NVD queries will return only vulnerabilities affecting that specific version.

WordPress 6.4

cpe:2.3:a:wordpress:wordpress:6.4:*:*:*:*:*:*:*

WordPress is one of the most heavily tracked products in the NVD. Pinning the version lets you filter out vulnerabilities that were patched in earlier or later releases.

Apache HTTP Server

cpe:2.3:a:apache:http_server:*:*:*:*:*:*:*:*

Note that the product name is http_server, not apache or httpd. CPE product names follow the NVD's official dictionary, which doesn't always match the colloquial name. The wildcard * in the version field means this matches all versions.

Nginx

cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*

The vendor is f5, not nginx, because F5 Networks acquired Nginx in 2019. The NVD reflects the current owner as the vendor. This is a common source of confusion—always verify CPE vendor names against the NVD CPE dictionary.

Querying the NVD with CPE Identifiers

Once you have a CPE identifier, you can query the NVD's REST API to find all known vulnerabilities for that product. The NVD API is free and does not require authentication for basic use (though an API key raises your rate limit).

Here's how to look up vulnerabilities for jQuery 3.6.0:

curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:jquery:jquery:3.6.0:*:*:*:*:*:*:*"

The response includes matching CVEs with full details:

{
  "resultsPerPage": 3,
  "startIndex": 0,
  "totalResults": 3,
  "vulnerabilities": [
    {
      "cve": {
        "id": "CVE-2020-23064",
        "descriptions": [
          {
            "lang": "en",
            "value": "Cross Site Scripting vulnerability in jQuery 2.2.0 through 3.x before 3.5.0..."
          }
        ],
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "baseScore": 6.1,
                "baseSeverity": "MEDIUM"
              }
            }
          ]
        }
      }
    }
  ]
}

Key parameters for the NVD API:

• cpeName — The full CPE 2.3 formatted string to match
• resultsPerPage — Limit the number of results (max 2000)
• startIndex — Offset for pagination
• cvssV3Severity — Filter by severity: LOW, MEDIUM, HIGH, or CRITICAL

Building an Automated Vulnerability Pipeline

The real power of CPE identifiers comes when you combine technology detection with automated NVD lookups. Here's how to build a pipeline that continuously monitors your web properties for vulnerable technologies.

Step 1: Detect Technologies at Scale

Use the DetectZeStack batch endpoint to scan multiple domains in a single request. Each technology in the response includes its CPE identifier when available:

curl -X POST "https://detectzestack.com/analyze/batch" \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["example.com", "shop.example.com", "blog.example.com"]}'

Step 2: Extract and Deduplicate CPEs

Collect all CPE identifiers from the scan results and deduplicate them. If jQuery 3.6.0 appears on five of your domains, you only need to query the NVD once for that CPE.

Step 3: Query the NVD

For each unique CPE, query the NVD API and collect matching CVEs. Respect the rate limits—space requests 600ms apart without an API key, or 200ms apart with one.

Step 4: Alert on New Findings

Compare results against previous scans. When a new CVE appears for a technology you're running, trigger an alert through your existing incident response workflow. DetectZeStack webhooks notify you each time a monitored domain is analyzed, so you can re-run the vulnerability check automatically.

Conclusion

CPE identifiers are the bridge between knowing what technologies a website runs and understanding the security risks those technologies carry. The standardized naming convention—maintained by NIST and used universally across the NVD—gives security teams a reliable, machine-readable way to connect technology inventories to vulnerability databases.

The key takeaways:

• CPE provides a universal language for identifying IT products across security tools and databases
• The naming convention is structured but practical—most web technologies use just the part, vendor, product, and version fields
• Vendor names in CPE can be surprising—always verify against the NVD CPE dictionary (e.g., Nginx's vendor is f5, not nginx)
• Automation is straightforward—combine DetectZeStack's CPE output with the NVD API for continuous vulnerability monitoring

DetectZeStack provides CPE identifiers automatically as part of every technology detection scan, so you can go from URL to vulnerability report without manual mapping. See how it works in the vulnerability detection guide, or learn how to run a full security audit on website dependencies.

For a deeper look at using CPE in security audits, read our guide on auditing website dependencies with CPE.