CPE

Common Platform Enumeration (CPE) to ustrukturyzowany schemat nazewnictwa produktów IT w cyberbezpieczeństwie: aplikacji, systemów operacyjnych i sprzętu. Wersję 2.3 NIST opisał w NISTIR 7695 (sierpień 2011). National Vulnerability Database (NVD) używa nazw CPE, by wskazać, których produktów dotyczy CVE, i prowadzi oficjalny słownik CPE.

Format CPE 2.3

Nazwa CPE 2.3 ma 11 atrybutów po prefiksie cpe:2.3: part, vendor, product, version, update, edition, language, sw_edition, target_sw, target_hw i other. Część (part) to a dla aplikacji, o dla systemu operacyjnego i h dla sprzętu. Znak * oznacza dowolną wartość, a - oznacza „nie dotyczy”.

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:-:*:*:*:*:*:*:*

Pierwsza to przykład ze specyfikacji. Druga to biblioteka npm lodash z node.js jako oprogramowaniem docelowym. Trzecia to urządzenie sprzętowe. Wszystkie trzy są w słowniku NVD.

Jak działa dopasowanie CPE i gdzie zawodzi

Rekord NVD wymienia CPE, których dotyczy CVE, często z zakresami wersji. Skaner zamienia każdy komponent SBOM w przypuszczalne CPE i porównuje. Trzy rzeczy idą źle:

• Niejednoznaczne nazwy. Dostawca i produkt w słowniku nie zawsze odpowiadają nazwie pakietu w jego ekosystemie. Biblioteka xz to cpe:2.3:a:tukaani:xz, podczas gdy Debian dostarcza ją jako pakiet xz-utils. Przypuszczenie zbudowane z nazwy pakietu trafia w zły produkt albo w żaden.
• Zbyt szerokie zakresy. Deklaracja zastosowania może obejmować wersje lub platformy, których problem nie dotyczy, np. każdą wersję produktu, choć dotyczył on tylko jednej konfiguracji buildu. Każdy pasujący komponent staje się znaleziskiem do triażu.
• Brakujące dane. NIST pisze, że „od początku 2024 roku w NVD narosły znaczne zaległości we wzbogacaniu CVE”. Od 15 kwietnia 2026 roku NVD wzbogaca CVE według priorytetu (najpierw wpisy w CISA KEV, oprogramowanie używane przez administrację federalną USA i oprogramowanie krytyczne w rozumieniu EO 14028), a pozostałe oznacza jako „Lowest Priority - not scheduled for immediate enrichment” (NIST). CVE Numbering Authorities mogą podawać objęte produkty, w tym CPE, w rekordzie CVE, a NVD od czerwca 2026 roku włącza takie dane od CNA i ADP do swoich rekordów, ale pokrycie zależy od CNA. Informacje o wydaniu 5.2 Yocto Project mówią wprost: przy kontrolach opartych na CPE „niektóre podatności po prostu nie są zgłaszane”.

Dopasowanie do złego produktu to jedno ze źródeł fałszywych alarmów; zob. ograniczanie szumu podatności.

CPE a Package URL

	Package URL	CPE
Kto ustala nazwę	Ekosystem pakietu	Słownik CPE prowadzony przez NVD
Identyfikuje	Pakiet w rejestrze lub dystrybucji	Produkt, także sprzęt i systemy operacyjne
Format	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Standard	ECMA-427	NISTIR 7695 (CPE 2.3)
Używają go	OSV, biuletyny GitHub, narzędzia SBOM	NVD, wiele skanerów
Typowy problem	Brak dla kodu dołączonego do repozytorium lub wpisanego ręcznie	Niejednoznaczne nazwy dostawców i produktów; brak danych CPE dla wielu nowych CVE

Proszę używać package URL wszędzie tam, gdzie istnieje ekosystem pakietów, CPE dla produktów komercyjnych, firmware'u i sprzętu, a obu tam, gdzie wymagania tego żądają. 2026 Minimum Elements CISA wymieniają CPE i Package-URL jako powszechne identyfikatory, a BSI TR-03183-2 wymaga takich identyfikatorów dla każdego komponentu, o ile istnieją.

CPE w SBOM

CycloneDX ma pole cpe w każdym komponencie, a SPDX podaje CPE jako identyfikatory zewnętrzne. Jeśli są Państwo dostawcą, proszę wpisać CPE, którego NVD faktycznie używa dla Państwa produktu (warto sprawdzić je w słowniku), zamiast je wymyślać: wymyślone CPE niczego nie dopasuje. Identyfikatory to jeden z elementów jakości pól SBOM; to, czy czegoś brakuje na liście, jest osobną kwestią, czyli kompletnością SBOM.

CRACI identyfikuje każdy pakiet pobierany przez build po jego package URL. Zob. SBOM z czasu buildu.