CPE

Common Platform Enumeration (CPE) es un esquema estructurado de nombres para productos de TI en ciberseguridad: aplicaciones, sistemas operativos y hardware. El NIST especificó la versión 2.3 en NISTIR 7695 (agosto de 2011). La National Vulnerability Database (NVD) usa nombres CPE para indicar a qué productos afecta una CVE, y mantiene el diccionario CPE oficial.

El formato CPE 2.3

Un nombre CPE 2.3 tiene 11 atributos tras el prefijo cpe:2.3: part, vendor, product, version, update, edition, language, sw_edition, target_sw, target_hw y other. La parte (part) es a para una aplicación, o para un sistema operativo y h para hardware. Un * significa cualquier valor y un - significa no aplicable.

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

El primero es el ejemplo de la especificación. El segundo es la biblioteca npm lodash, con node.js como software de destino. El tercero es un producto de hardware. Los tres están en el diccionario de la NVD.

Cómo funciona el cotejo por CPE y dónde falla

Un registro de la NVD lista los CPE a los que se aplica una CVE, a menudo con rangos de versiones. Un escáner convierte cada componente de una SBOM en una suposición de CPE y compara. Tres cosas salen mal:

• Nombres ambiguos. El proveedor y el producto del diccionario no siempre coinciden con el nombre del paquete en su ecosistema. La biblioteca xz es cpe:2.3:a:tukaani:xz, mientras que Debian la distribuye como el paquete xz-utils. Una suposición construida a partir del nombre del paquete acierta con el producto equivocado o con ninguno.
• Rangos demasiado amplios. Una declaración de aplicabilidad puede cubrir versiones o plataformas no afectadas, por ejemplo todas las versiones de un producto cuando solo lo estaba una configuración de build. Cada componente que coincide se convierte en un hallazgo que hay que clasificar.
• Datos ausentes. El NIST dice que «a partir de principios de 2024, la NVD acumuló un retraso considerable de CVE sin enriquecer». Desde el 15 de abril de 2026 enriquece las CVE por prioridad (primero las entradas del KEV de la CISA, el software que usa el gobierno federal y el software crítico según la EO 14028) y etiqueta el resto como «Lowest Priority - not scheduled for immediate enrichment» (NIST). Las CVE Numbering Authorities pueden aportar los productos afectados, CPE incluidos, en el registro CVE, y la NVD incorpora esos datos aportados por CNA y ADP desde junio de 2026, pero la cobertura varía según la CNA. Las notas de la versión 5.2 del Yocto Project lo dicen sin rodeos: con comprobaciones basadas en CPE, «algunas vulnerabilidades simplemente no se notifican».

Cotejar el producto equivocado es una fuente de falsos positivos; vea reducir el ruido de vulnerabilidades.

CPE frente a Package URL

	Package URL	CPE
Quién define el nombre	El ecosistema del paquete	El diccionario CPE de la NVD
Identifica	Un paquete en un registro o una distribución	Un producto, incluidos hardware y sistemas operativos
Formato	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Norma	ECMA-427	NISTIR 7695 (CPE 2.3)
Lo usan	OSV, avisos de GitHub, herramientas SBOM	NVD, muchos escáneres
Fallo típico	Falta en código incorporado o listado a mano	Nombres de proveedor y producto ambiguos; sin datos CPE para muchas CVE recientes

Use una package URL siempre que exista un ecosistema de paquetes, un CPE para productos comerciales, firmware y hardware, y ambos cuando un requisito pida ambos. Los 2026 Minimum Elements de la CISA citan CPE y Package-URL como identificadores comunes, y la BSI TR-03183-2 exige esos identificadores para cada componente cuando existen.

Los CPE en las SBOM

CycloneDX tiene un campo cpe en cada componente, y SPDX incluye los CPE como identificadores externos. Si usted es proveedor, indique el CPE que la NVD usa realmente para su producto (búsquelo en el diccionario) en lugar de inventarlo: un CPE inventado no coincide con nada. Los identificadores son una parte de la calidad de los campos de una SBOM; si falta algo en la lista es otra cuestión, la completitud de la SBOM.

CRACI identifica cada paquete que descarga un build por su package URL. Vea SBOM en tiempo de build.