Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation Help centre FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot →

Home / Knowledge hub / CPE

Knowledge hub

CPE

A standard name for a product and version, used to match software to CVEs.

Illustration explaining CPE

What it means

CPE stands for Common Platform Enumeration. It is a structured naming scheme for products, so a tool can say exactly which software and version it means. A current CPE name is a string, for example cpe:2.3:a:apache:http_server:2.4.49:*:*:*:*:*:*:*, with fields for the part, vendor, product, version and more. The scheme is maintained by NIST and has been used by the NVD for many years.

The National Vulnerability Database, run by NIST, uses CPE names to say which products a CVE affects. If your inventory records the same name, a tool can match your software to published flaws without anybody reading each advisory. Without a shared name, matching software to flaws would depend on guesswork.

Why it matters

Matching software to known flaws is the base of vulnerability management. If your inventory is wrong or the names do not line up, you miss real exposure or chase flaws you do not have. CPE gives tools a shared way to talk about the same product.

It also explains why scanner results can look odd. A tool that guesses the wrong vendor name or version produces a false alarm, and one that finds no match produces silence. Knowing the mechanism helps you judge which results to trust and when to check by hand.

How it shows up

You meet it in scanner output, in the NVD, in software bills of materials and in asset tools. Many tools infer CPE names from version banners, package names or files, which is fragile. A library bundled inside another product often carries no name of its own.

The common problems are mismatched vendor or product spellings, version ranges that tools read differently, and products with no CPE at all. Newer approaches such as package URLs help for open-source libraries. Where it matters, confirm a match by checking the real version and whether the affected code is present.

Questions people ask

CPE, answered

What does a CPE string look like?

It starts with cpe:2.3, followed by fields for part (application, operating system or hardware), vendor, product, version, and several others. A star means any value.

The NVD publishes the official dictionary of names.

Who maintains CPE?

NIST maintains the specification and the official dictionary through the National Vulnerability Database.

The scheme is open, and many tools produce names from it. Vendors and tool makers publish names in that format, and the NVD uses them to link products to each CVE it records.

Why does my scanner report a flaw I do not have?

Often the tool matched the wrong CPE, or read a version range incorrectly. The flaw may be in a different product with a similar name.

Verify the real version and component before acting.

Does every product have a CPE?

No. Many open-source packages, internal software and recent products have none, or the name is incomplete. That means flaws can be missed.

Complement it with package-level identifiers and an SBOM.

Is CPE the same as an SBOM?

No. An SBOM lists the components inside a product. CPE is a naming scheme that can label those components.

They work together to match your software to known flaws. CPE tells a tool what a thing is called, and the SBOM tells it what is present.

Cyberlop mark

Does the name match what you run?

Name matching covers known flaws in other people's software. We test your own application and its APIs, and report only what we actually exploited. Book a pilot on one app.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.