CPE

Common Platform Enumeration (CPE) er et strukturert navneskjema for IT-produkter innen cybersikkerhet: applikasjoner, operativsystemer og maskinvare. Versjon 2.3 er spesifisert av NIST i NISTIR 7695 (august 2011). National Vulnerability Database (NVD) bruker CPE-navn for å angi hvilke produkter en CVE rammer, og vedlikeholder den offisielle CPE-ordboken.

Formatet CPE 2.3

Et CPE 2.3-navn har 11 attributter etter prefikset cpe:2.3: part, vendor, product, version, update, edition, language, sw_edition, target_sw, target_hw og other. Delen (part) er a for en applikasjon, o for et operativsystem og h for maskinvare. En * betyr vilkårlig verdi, og en - betyr ikke aktuelt.

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*
cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:node.js:*:*
cpe:2.3:h:raspberrypi:raspberry_pi_4_model_b:-:*:*:*:*:*:*:*

Den første er eksemplet fra spesifikasjonen. Den andre er npm-biblioteket lodash, med node.js som målprogramvare. Den tredje er et maskinvareprodukt. Alle tre finnes i NVDs ordbok.

Slik fungerer CPE-matching, og her går den galt

En NVD-post oppgir CPE-ene en CVE gjelder for, ofte med versjonsintervaller. En skanner gjør hver komponent i en SBOM om til en CPE-gjetning og sammenligner. Tre ting går galt:

• Tvetydige navn. Ordbokens leverandør og produkt stemmer ikke alltid med hva pakken heter i økosystemet sitt. Biblioteket xz er cpe:2.3:a:tukaani:xz, mens Debian leverer det som pakken xz-utils. En gjetning bygd på pakkenavnet treffer feil produkt eller ingenting.
• For brede intervaller. En anvendelighetsangivelse kan dekke versjoner eller plattformer som ikke er berørt, for eksempel alle versjoner av et produkt når bare én byggekonfigurasjon var berørt. Hver komponent som matcher, blir et funn som må triageres.
• Manglende data. NIST skriver at «NVD fra tidlig i 2024 bygde opp et betydelig etterslep av CVE-er som ikke var beriket». Siden 15. april 2026 beriker NVD CVE-er etter prioritet (først oppføringer i CISA KEV, programvare som brukes av amerikanske føderale myndigheter, og kritisk programvare etter EO 14028) og merker resten «Lowest Priority - not scheduled for immediate enrichment» (NIST). CVE Numbering Authorities kan oppgi berørte produkter, også CPE-er, i CVE-posten, og NVD har siden juni 2026 tatt slike data fra CNA-er og ADP-er inn i postene sine, men dekningen varierer fra CNA til CNA. Yocto Projects utgivelsesnotater for 5.2 sier det rett ut: med CPE-baserte kontroller blir «noen sårbarheter rett og slett ikke rapportert».

Å matche feil produkt er en kilde til falske positiver; se reduser sårbarhetsstøyen.

CPE og Package URL

	Package URL	CPE
Hvem bestemmer navnet	Pakkens økosystem	NVDs CPE-ordbok
Identifiserer	En pakke i et register eller en distribusjon	Et produkt, også maskinvare og operativsystemer
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Brukes av	OSV, GitHub-advisories, SBOM-verktøy	NVD, mange skannere
Typisk feil	Mangler for vendorert eller håndlistet kode	Tvetydige leverandør- og produktnavn; ingen CPE-data for mange nye CVE-er

Bruk en package URL der det finnes et pakkeøkosystem, en CPE for kommersielle produkter, fastvare og maskinvare, og begge der et krav ber om begge. CISAs 2026 Minimum Elements nevner CPE og Package-URL som vanlige identifikatorer, og BSI TR-03183-2 krever slike identifikatorer for hver komponent der de finnes.

CPE-er i SBOM-er

CycloneDX har et felt cpe på hver komponent, og SPDX oppgir CPE-er som eksterne identifikatorer. Er du leverandør, oppgi den CPE-en NVD faktisk bruker for produktet ditt (slå den opp i ordboken) i stedet for å finne på en: en oppdiktet CPE matcher ingenting. Identifikatorer er én del av en SBOMs feltkvalitet; om noe mangler i listen, er et eget spørsmål, SBOM-fullstendighet.

CRACI identifiserer hver pakke et bygg henter inn, ut fra package URL-en. Se SBOM-er fra byggetidspunktet.