What are the segments of a Package URL (PURL)?

A Package URL (PURL) is an open specification standard for reliably identifying and locating software packages across disparate ecosystems. Defined by the Package URL Specification, every canonical PURL follows a standard URL-like string format:

canonical purl syntax anatomy

pkg:type/namespace/name@version?qualifiers#subpath

A canonical PURL comprises seven distinct segments, arranged in strict hierarchical sequence:

Segment	Requirement	Description	Example
scheme	Required	Constant URL scheme protocol prefix; must always be `pkg`.	pkg
type (Package type)	Required	Package manager, package ecosystem, or registry type (e.g. `golang`, `npm`, `pypi`, `cargo`, `deb`, `generic`). In Packablock reports, this segment is referred to as Package type.	golang
namespace	Optional	Name prefix, vendor, organization, or user scope. Ecosystem-specific conventions apply (e.g., Maven `groupId`, GitHub owner, npm scope).	sigs.k8s.io
name	Required	The primary name of the package or software component.	yaml
version	Optional	Specific release tag, semantic version, git commit hash, or build identifier, preceded by `@`.	v1.4.0
qualifiers	Optional	Extra key-value query parameters preceded by `?` (e.g. architecture, distro, repository URL, checksum).	arch=x86_64
subpath	Optional	Relative sub-path pointing to a specific file or sub-component inside the package, preceded by `#`.	dist/bundle.js

What does "Binary (pkg:generic)" mean?

The pkg:generic type identifies software components, compiled binaries, native shared libraries, or downloaded release archives that do not belong to a language-specific package manager like npm, PyPI, or Cargo.

Many critical infrastructure components (such as OpenSSL, zlib, SQLite, or CLI binaries) are distributed as pre-compiled executable binaries or embedded directly into runtime runtimes. Because they lack a package.json or Cargo.toml file, standard lockfile scanners completely miss them.

In Packablock inspection reports:

pkg:generic/openssl@3.0.13 denotes the authoritative upstream C/C++ cryptographic library bundled directly into the official Node.js 22 LTS distribution.
It allows SBOM engines (like SPDX and CycloneDX) to link vulnerabilities (CVEs) affecting native libraries to the host binary, even when language dependency graphs only list pure JavaScript or Go modules.

How do I inspect PURL segments on Packablock reports?

Every Packablock dependency intelligence report highlights Package URLs with a subtle dotted underline (e.g., pkg:golang/sigs.k8s.io/yaml@v1.4.0).

Hovering your mouse or focus cursor over any PURL badge will automatically display an interactive tooltip breaking down the exact canonical segments: scheme, Package type, namespace, name, version, qualifiers, and subpath.

What ecosystems and package managers does Packablock support?

Packablock ingests dependency graphs and attestation blocks across language-level package managers, operating system package registries, and unmanaged native releases:

Language Package Registries

Go Modules: pkg:golang (Go proxy / go.mod)
npm: pkg:npm (npmjs.org / package-lock.json)
PyPI: pkg:pypi (Python wheels & sdist)
Cargo: pkg:cargo (crates.io / Cargo.lock)
Maven Central: pkg:maven (Java POM / artifacts)
NuGet: pkg:nuget (.NET assemblies / nuget.org)
Composer: pkg:composer (PHP / Packagist)
RubyGems: pkg:gem (Ruby / rubygems.org)
Pub: pkg:pub (Dart & Flutter / pub.dev)
Swift PM: pkg:swift (Apple Swift Package Index)

Operating System & Binary Registries

Debian & Ubuntu: pkg:deb (official dpkg control files)
Alpine Linux: pkg:apk (official APKBUILD & packages)
RPM / RHEL / Fedora: pkg:rpm (official RPM spec files)
No Package Manager: pkg:generic (unmanaged binaries, embedded C/C++ runtimes, and release tarballs)

For each ecosystem, Packablock correlates transitive dependency trees with official upstream release registries, CVE trackers, and OpenSSF Scorecards without cloning source repositories.