I’m joined by Philippe Ombredanne, creator of the Package URL (PURL), to discuss the surprisingly complex and messy problem of simply identifying open source software packages. We dive into how PURLs provide a universal, common-sense standard that is becoming essential for the future of SBOMs and securing the software supply chain.
Episode Links
This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.
Identifying a package. It’s one of those problems that seems so simple on the surface. You have a piece of software. It has a name. It has a version. That should be all you need to know. But if you’ve spent any time in the trenches of open source, you know that capturing what a package actually is, is incredibly hard. Also, it’s a foundational part of the security world.
Philippe is the creator of Package URLs, or PURLs. He’s doing a ton of work to solve the identification problem.
The Old Way Was a Bad Way: CPEs
Before PURL, we had this thing called Common Platform Enumeration, or CPE. A CPE is a collection of identifiers controlled by NIST and is used by the NVD data. The system was designed for an older world of commercial software like Microsoft Office, or Adobe Acrobat. It’s not really designed for the chaotic ecosystem of open source. Figuring out details who the vendor is, or even how to name some of the open source packages has made CPE rough to use in recent years.
The PURL Origin Story
The origin story for PURL is an example of how the best solutions come from practical needs, not standards committees. Philippe explained the idea came about years ago from the simple need to connect the dots. You have tools that are pretty good at finding the origin of code, but it was difficult to get from a package found in a manifest file to a vulnerability entry in a database. Inspired by some early work from a Google project called Grafeas, the concept of a simple, URL-like string that could act as a universal key was born.
Why PURLs Just Work
The reason PURLs just work (mostly) is their simplicity. The structure maps directly to reality. It starts with pkg:, followed by a type like npm or maven, and then the name and version, exactly like a developer would write it. There’s no guesswork involved. A package like pkg:npm/[email protected] is just what it looks like. This is much easier than the world of CPE. It allows you to go from the code you see to a standard identifier.
What Comes Next: Benchmarks and a Foundation
So what’s next with PURL? Philippe talked about an idea to create open benchmarks. We could take a real-world application, have everyone agree on exactly what’s inside it, and make that the ground truth. If a tool can’t produce that correct list, then it’s a bug in the tool. It’s a sensible plan to establish a baseline for reality. Philippe also told us PURL is getting a home in the new AboutCode Foundation. This is a huge step. It moves the project from being one person’s passion project to a community-stewarded piece of critical infrastructure that the whole ecosystem can rely on. It’s a sign of maturity and should help build trust.
Conclusion
When you boil it all down, it’s clear that while a package identifier seems like a small, nerdy detail, it’s the absolute foundation for everything else. You can’t secure your supply chain if you can’t agree on what’s in it. PURLs are winning the adoption race not because they’re theoretically perfect, but because all the alternatives are so demonstrably bad. It’s a pragmatic solution to a hard problem. It will continue to grow and change. I expect it will only get better with time.