PURL Format Discrepancy

[kashishtopi]

Current Behavior

Although, The Purl format on Dependency Track and Purl-Spec mentions that Namespace/GroupID is optional.

For JAVA (Maven) packages, Dependency Track fails to find vulnerabilities in the Java Maven SBOM If Namespace/GroupID is not mentioned in the Purl.

Proposed Behavior

scheme:type/namespace/name@version

** Namespace is not optional, IT IS a MUST in the Purl-Spec format for a JAVA - MavenSBOM for being detectable by Dependency Track.

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[melba-lopez]

hey team! if you need more info on this, feel free to reach out to myself or @kashishtopi as we have been troubleshooting this issue for a few days now.

[stevespringett]

Namespace is not optional, IT IS a MUST in the Purl-Spec format for a JAVA - Maven SBOM for being detectable by Dependency Track.

That is correct and is documented in the purl spec. See https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst

I do not believe it is the role of Dependency-Track to validate all current and future purl types.

[melba-lopez]

Hmmm... lets think about that for a minute.

Cyclonedx-cli validates SBOMs OWASP also has an SBOM Validator

if Dependency track needs those items to detect vulnerabilities in specific packages, then we would want to inform the users that there may be reasons why they see NO vulnerabilities. So if Dependency track is using cyclonedx-cli or the sbomvalidator tool in the backend, we should absolutely have this baked in. I'm indifferent on which tool provides the information, but the UI should provide that. Right now the only way a user knows there's something wrong is if the SBOM doesnt load or they look at the api logs.

My recommendation (which we may be able to help with) 1) Surface any SBOM related warnings to the user via UI setting they could enable 2) If cyclonedx-cli or sbom validator is not being used today with dependency track before it ingests an SBOM, we should add that as an enhancement 3) add an extra flag for cyclonedx-cli or sbom validator to add checks for special package requirements (like maven) --> i know this is a different repo/project, but wanted to document it here.

[stevespringett]

we would want to inform the users that there may be reasons why they see NO vulnerabilities

What you're describing is a subset of SBOM quality. Quality is being discussed by the larger industry from two angles: taxonomy/capabilities and accuracy. Accuracy is a lot more difficult to analyze. Purl being just one aspect of component identity. CPE, SWID, and coordinates (GAV/GNV) being the others. Validating for one without validating against the others will have limited utility.

Checking for the existence of all required fields for a given ecosystem doesn't increase quality that much. You'd have to go much further in verifying the existence of the package itself based on the data in the SBOM. Otherwise, the values could simply be made up. If a group/namespace is missing for a Maven package, that's an indication that the tool or method that produced the SBOM should likely not be trusted. That would be good to flag. But if we go down the rabbit hole of individual component SBOM quality, it's going to involve much more than just purl validation.

[stevespringett]

If you wanted to focus specifically on purl, I'd recommend adding purl type checks to the official purl implementations for Java, go, .NET, etc.

https://github.com/orgs/package-url/repositories