Package URL

Um package URL (purl, um endereço normalizado de pacote) é um identificador de um pacote de software que o designa tal como o seu próprio ecossistema o faz: pkg:type/namespace/name@version?qualifiers#subpath. Tornou-se uma norma Ecma, ECMA-427, em dezembro de 2025 (1.ª edição, Ecma TC54), e a especificação é mantida em package-url/purl-spec.

Como é construído um purl

Todo o purl começa pelo esquema pkg. O tipo é o ecossistema ou o gestor de pacotes (npm, pypi, cargo, deb, maven, etc.). O espaço de nomes é um agrupamento opcional, como um scope do npm, um grupo Maven ou uma distribuição Linux. Seguem-se o nome e a versão. Os qualificadores acrescentam dados de que o ecossistema precisa para fixar o pacote exato, como a arquitetura ou a versão da distribuição, e o subcaminho aponta para dentro de um pacote.

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

O último diz mais do que «cpio 2.15»: é o build da própria Ubuntu para a versão Noble em arm64. Isto importa porque as distribuições retroportam correções de segurança para as suas próprias versões, pelo que a mesma versão upstream pode estar vulnerável numa distribuição e corrigida noutra.

Porque a correspondência de vulnerabilidades depende dele

As bases de avisos de segurança organizadas por pacote conhecem um componente pelo ecossistema e pelo nome. O esquema OSV exige ecosystem e name para cada pacote afetado e classifica o campo purl como «opcional, mas recomendado»; os avisos do GitHub também são listados por pacote do ecossistema. Quando um componente da SBOM tem um purl, uma ferramenta consegue associá-lo exatamente a esses avisos. Sem ele, tem de adivinhar a partir de um nome ou de um CPE, ou não associa nada, e a vulnerabilidade fica por reportar.

Num build Yocto que comparámos, a SBOM do próprio sistema de build listava centenas de crates de Rust apenas como ficheiros .crate com uma localização de transferência e sem purl pkg:cargo, pelo que esses crates não podiam ser associados aos avisos de Rust (veja builds Yocto). As versões mais recentes do Yocto acrescentam purl de ecossistema para as fontes Cargo e Go.

Package URL vs. CPE

	Package URL	CPE
Quem define o nome	O ecossistema do pacote	O dicionário CPE da NVD
Identifica	Um pacote num registo ou numa distribuição	Um produto, incluindo hardware e sistemas operativos
Formato	pkg:type/namespace/name@version	cpe:2.3:part:vendor:product:version:...
Norma	ECMA-427	NISTIR 7695 (CPE 2.3)
Usado por	OSV, avisos do GitHub, ferramentas SBOM	NVD, muitos scanners
Falha típica	Falta em código incorporado ou listado à mão	Nomes de fornecedor e produto ambíguos; sem dados CPE para muitas CVE recentes

A regra prática: atribua um purl a cada pacote que tenha ecossistema e use um CPE para o que não tem, como software comercial, firmware e hardware. Identificadores que não correspondem são uma das principais causas de resultados errados, veja reduzir o ruído das vulnerabilidades.

Package URL nas SBOM

CycloneDX e SPDX incluem ambos um purl por componente. Os 2026 Minimum Elements da CISA pedem que os identificadores de componentes usem identificadores comuns «como Common Platform Enumeration (CPE) e Package-URL (PURL)», e a alemã BSI TR-03183-2 exige esses identificadores para cada componente, quando existem. Um purl em falta é um problema de qualidade dos campos e não uma lacuna na completude da SBOM: o componente está listado, mas nenhuma base de avisos o consegue procurar.

O CRACI regista um package URL para cada pacote que um build obtém, incluindo cada crate de Rust num build Yocto, para que as suas SBOM possam ser associadas aos avisos de segurança. Veja SBOM do momento do build.