Support PackageURL in test API

[stevespringett]

The test API uses ecosystem-specific criterial in the API. This is an anti-pattern that the security industry and standards bodies are moving away from.

This request is to support PackageURL as an additional method (and preferred method) of component identification. PackageURL is supported by:

• OWASP Dependency-Track
• OWASP Dependency-Check (coming soon)
• Sonatype OSSIndex
• CycloneDX BoM format
• SPDX BoM format (enhancement in development)

For example:

GET
https://snyk.io/api/v1/test/maven/groupId/artifactId/version?org=9695cbb1-3a87-4d6f-8ae1-61a1c37ee9f7&repository=https%3A%2F%2Frepo1.maven.org%2Fmaven2

The new proposed PackageURL test API would simply be:

POST
https://snyk.io/api/v1/test/packageurl

In the case of Maven, this would be written as:

POST
https://snyk.io/api/v1/test/pkg:maven/groupId/artifactId@version

The orgID and any other data not part of the PackageURL would either need to be sent as part of the body, or as additional paths in the URL. For example:

GET
https://snyk.io/api/v1/org/test/org/9695cbb1-3a87-4d6f-8ae1-61a1c37ee9f7/pkg:maven/groupId/artifactId@version

By implementing PackageURL, API users and third-party systems will not have to concern themselves about all the differences between various ecosystems. They would simply send the packageurl to the Snyk test API.

Additionally, if there are other APIs that references components by their various metadata (group, name, version, etc), then those APIs should also support PackageURL.

[gjvis]

Hi @stevespringett 👋. PackageURL looks really interesting – we've been looking for something along those lines for a while! We didn't want to introduce our own unique-snowflake way of referring to packages, so in the absence of a spec (that we could find) we opted for the package-manager-specific API we have today. This could be the answer we've been looking for, particularly if its already somewhat battle-tested in a few different ecosystems.

What's the best way to engage with that community?

[stevespringett]

https://github.com/package-url/purl-spec is where most of the action is, although most folks are a bit slow to respond. Questions about the future of the spec, discrepancies (there are some), etc, should be addressed there.

That said, I'm the leader of OWASP Dependency-Track and the CycloneDX BoM spec, both containing first-class support for PackageURL, and I'm the author of the official PackageURL Java implementation. I've also worked with the SPDX and Sonatype OSSIndex folks previously and am part of an NTIA working group for the USG that will be recommending and/or creating a BoM spec for the entire federal government, and many of the folks on the working group have a favorable opinion of PackageURL.

I'd be more than happy to address any questions you have about the spec as it exists today.

steve[dot]springett[at]owasp.org

As an aside, the primary reason for my request is to add Snyk as an optional source of vulnerability intelligence to Dependency-Track. The platform currently supports Dependency-Check, Sonatype OSSIndex (in dev), and VulnDB (partial support). For existing Snyk customers, this would allow them additional flexibility and control and would be a way for Snyk reach new audiences.

[gjvis]

Thanks very much of the offer to answer any questions we have, that's very kind. Will review the spec and various implementations to get a better handle on the detail.

We'll update this thread with our plans once we've had a chance for some internal discussion.

[stevespringett]

Curious if theres been any discussion or decision on this?

[gjvis]

Hi @stevespringett – apologies for the radio silence. We still haven't made a decision here. Currently we're looking at pURLs in the context of our internals, which has delayed the API discussion a little. We're actively looking at this in the coming weeks, will update on progress once we have some

[stevespringett]

@gjvis has any progress been made on this? Also related, I recently posted a new wiki article for OWASP about component analysis and purl is part of it - was in draft since January.

https://www.owasp.org/index.php/Component_Analysis

[geoffwhittington]

As an integration developer, I'm interested in Snyk supporting purl.

[VinodAnandan]

Hi Team, any update on this?

[pombredanne]

Gentle ping. Do you need help for this?

[claudioandreantonio]

Hi @gjvis @lili2311 . Is there a new update on this possibility? Thank you.

[lili2311]

hi @claudioandreantonio

We’re building out a new API for Snyk at the moment, and working on where this will utilise various emerging standards This will include issues from Snyk Open Source projects, where SPDX + the vulnerability extension is relevant We have have an API in the works for grabbing the dependency information in standard formats as well, starting with CycloneDX, but we’ll be adding support for SPDX as well If you want to chat about this talk to your Snyk contact who can grab someone from the product team to talk more

[mcombuechen]

Hi @stevespringett and everyone,

at Snyk we’ve been working on an API endpoint to support this use case, which was released to our customers last week. This supports fetching vulnerabilities associated with open source packages for the following purl types:

• npm
• maven
• cocoapods
• composer
• gem
• nuget
• pypi
• hex
• cargo
• generic (used for C/C++ packages)

The API documentation is available here: https://apidocs.snyk.io/?version=2022-09-15#get-/orgs/-org_id-/packages/-purl-/issues

We would love to hear from you with any feedback or questions.