Package URL

Una package URL (purl, una dirección estándar de paquete) es un identificador de un paquete de software que lo nombra como lo hace su propio ecosistema: pkg:type/namespace/name@version?qualifiers#subpath. Se convirtió en norma Ecma, ECMA-427, en diciembre de 2025 (1.ª edición, Ecma TC54), y la especificación se mantiene en package-url/purl-spec.

Cómo se construye una purl

Toda purl empieza por el esquema pkg. El tipo es el ecosistema o el gestor de paquetes (npm, pypi, cargo, deb, maven, etc.). El espacio de nombres es una agrupación opcional, como un scope de npm, un grupo de Maven o una distribución Linux. Después vienen el nombre y la versión. Los calificadores añaden datos que el ecosistema necesita para fijar el paquete exacto, como la arquitectura o la versión de la distribución, y la subruta apunta al interior de un paquete.

pkg:npm/%40angular/[email protected]
pkg:pypi/[email protected]
pkg:cargo/[email protected]
pkg:deb/ubuntu/[email protected]+dfsg-1ubuntu2.1?arch=arm64&distro=noble

La última dice más que «cpio 2.15»: es el build propio de Ubuntu para la versión Noble en arm64. Importa porque las distribuciones retroportan correcciones de seguridad a sus propias versiones, de modo que la misma versión upstream puede ser vulnerable en una distribución y estar corregida en otra.

Por qué el cotejo de vulnerabilidades depende de ella

Las bases de avisos organizadas por paquete conocen un componente por su ecosistema y su nombre. El esquema OSV exige ecosystem y name para cada paquete afectado y califica su campo purl de «opcional pero recomendado»; los avisos de GitHub también se listan por paquete de ecosistema. Cuando un componente de la SBOM lleva una purl, una herramienta puede cotejarlo exactamente con esos avisos. Sin ella tiene que adivinar a partir de un nombre o de un CPE, o no coteja nada, y la vulnerabilidad queda sin notificar.

En un build de Yocto que comparamos, la SBOM del propio sistema de build listaba cientos de crates de Rust solo como archivos .crate con una ubicación de descarga y sin purl pkg:cargo, así que esos crates no podían cotejarse con los avisos de Rust (vea builds de Yocto). Las versiones más recientes de Yocto añaden purl de ecosistema para las fuentes de Cargo y Go.

Package URL frente a CPE

	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

La regla práctica: dé una purl a cada paquete que tenga ecosistema, y use un CPE para lo que no lo tiene, como software comercial, firmware y hardware. Los identificadores que no encajan son una de las principales causas de hallazgos erróneos, vea reducir el ruido de vulnerabilidades.

Package URL en las SBOM

CycloneDX y SPDX incluyen una purl por componente. Los 2026 Minimum Elements de la CISA piden que los identificadores de componente usen identificadores comunes «como Common Platform Enumeration (CPE) y Package-URL (PURL)», y la alemana BSI TR-03183-2 exige esos identificadores para cada componente cuando existen. Una purl ausente es un problema de calidad de los campos más que una laguna en la completitud de la SBOM: el componente aparece, pero ninguna base de avisos puede buscarlo.

CRACI registra una package URL para cada paquete que descarga un build, incluido cada crate de Rust de un build de Yocto, para que sus SBOM puedan cotejarse con los avisos. Vea SBOM en tiempo de build.