Setting the purl type based on the tool vs installation method

[prabhu]

I have hit an interesting issue with my projects. I am generating an SBOM using a combination of pip commands and private pip api. I arrive at a package named anaconda-anon-usage, so come up with a purl prefix pkg:pypi/anaconda-anon-usage (because pip means pypi?).

As per OSV, this package is a malware! However, since the package was originally installed with conda, it must have the type pkg:conda/anaconda-anon-usage and magically it is no longer a malware!

How are people dealing with such type-based name collisions? I can imagine many such issues with nix, brew, etc.

[matt-phylum]

These are different packages. Are you trying to construct an SBOM based on a Python package directory? I don't think it can work reliably because of conda or private pypi indices. This is a dependency confusion problem.

I don't think the same problem is likely with nix or brew. If you install something with either of those, the way that the software is installed is different than if you installed the same software with something else and you're not going to find brew packages in /nix/var/nix/db or nix packages in /opt/homebrew/Cellar. I guess it could happen if you incorporated the files from a nix or brew package into some sort of distribution (eg container image) and then processed that with a tool that just matches the file names.

[prabhu]

The question was "how are people dealing with collisions".

[matt-phylum]

I don't see the problem that needs to be dealt with. pkg:pypi and pkg:conda are different in the same way pkg:pypi and pkg:npm are different.

[prabhu]

Thank you for answering.

Take numpy. When there are CVEs against pkg:pypi/numpy, you can assume pkg:conda/numpy are also affected. Very rarely would any feed use pkg:conda, pkg:nix, or pkg:brew to refer to vulnerabilities in Python packages. Things like pedigree are literally unheard of. Will wait to hear more views.

[ppkarwasz]

I have hit an interesting issue with my projects. I am generating an SBOM using a combination of pip commands and private pip api. I arrive at a package named anaconda-anon-usage, so come up with a purl prefix pkg:pypi/anaconda-anon-usage (because pip means pypi?).

I believe the correct Package URL for the package you encountered is:

pkg:pypi/anaconda-anon-usage?repository_url=https:%2F%2Fpypi.anaconda.org%2Fanaconda

and not simply:

pkg:pypi/anaconda-anon-usage

The latter implicitly refers to the default PyPI index:

pkg:pypi/anaconda-anon-usage?repository_url=https:%2F%2Fpypi.org

The repository_url qualifier is defined in the PURL Specification itself, and therefore applies to all package types. As you rightly pointed out, it becomes especially important in contexts like vulnerability management and broader software supply chain security.

As you're certainly aware, most vulnerability databases today support some form of PURL-equivalent—typically a combination of ecosystem and package name. The example you gave is an excellent illustration of why full, properly qualified PURLs should be supported natively in vulnerability databases.

Note

Introducing PURLs into vulnerability databases won't immediately resolve the problem of non-default repositories. We will also need to have a way for those non-default repositories to issue their own vulnerability advisories.

Sonatype OSS Index is currently one of the few databases that support PURLs. Consider how Sonatype OSS Index (you need to register a free account to see the data) handles the package log4j-core:

• Versions with the redhat* suffix are marked as vulnerability-free.
• This is because they originate from the JBoss Enterprise Maven Repository, not Maven Central.

Of course, some of those redhat* versions released before December 2021 are almost certainly affected by Log4Shell and related vulnerabilities. But at that time, the CVE system didn’t support PURLs, so Red Hat had no way to formally report those versions as vulnerable—even though they likely were.

[prabhu]

Follow up question. How do you track the repository url? That information is almost always lost with the repos I am seeing. Are enhancement files like .ABOUT used to fill those gaps.