Investigate SWID/pURL retrieval and/or generation

[sophiewigmore]

Background

Given that in the related upstream RFC for bill of materials, the format for the bill of materials is leaning towards CycloneDX. According to CycloneDX documentation around vulnerabilities, it seems like maybe we should include pURLs (package URLs) and SWIDs (software ID) as optional fields as well as CPEs. Additionally, CPEs may be deprecated eventually, so it would be in our benefit to support other vulnerability identifiers.

Issue

We should investigate how we can get SWIDs and pURLs for our dependencies in the dependency server. We should figure out if we can generate them on the fly like we do for CPEs, or if we will need to incorporate a tool for retrieving them.

Desired Outcome

The outcome of this investigation should be more issues detailing the work that will need to be done to support these two fields, if it's possible.

[sophiewigmore]

pURL examples:

From https://github.com/sophiewigmore/bom/blob/master/syft/go-mod/from-image/syft-cyclonedx-from-source.xml#L31 for the apt dependency:

<purl>pkg:deb/ubuntu/[email protected]?arch=amd64</purl>"

for the bash dependency:

 <purl>pkg:deb/ubuntu/[email protected]?arch=amd64</purl>

From https://github.com/sophiewigmore/bom/blob/master/syft/go-mod/from-source/syft-cyclonedx-from-source.xml#L21l for the gorilla package:

<purl>pkg:golang/github.com/gorilla/[email protected]</purl>

No SWIDs were generated by tern, syft, or conversion tools in this repo. These might require more investigation.

[sophiewigmore]

After further investigation:

1. We are not proceeding with adding SWID tags. Per @ForestEckhardt investigation, this seems like a young concept that is likely to change. Additionally, it seems that SWIDs should be something we consume from packages, rather than generate ourselves. Though CPEs will not be supported by NVD eventually in favour of SWIDs, we believe that they will be around long enough that we shouldn't implement this at this point.

2. For package URLs, we will proceed with implementing pURL generation for our buildpack-installed dependencies. After investigating and talking with maintainers at https://gitter.im/package-url/Lobby#, its obvious we can generate these package URLS either with the generic type of as debian/ubuntu types. Providing a package URL will provide a uniform interface, and we have received feedback that if we don't provide pURLs we will need to provide another option for users to create pURLs themselves from the information we provide. At that point, it makes more sense to support pURLs. We should implement this.

[ForestEckhardt]

Here is an issue tracking the progress of implementing the addition of pURLs #82