GenerateFromDependency without CPE or PURL

[fg-j]

Summary

Currently, it's not possible to use GenerateFromDependency() in paketo-buildpacks/vsdbg#1 because the vsdbg dependency has neither a CPE nor a PURL and 'GenerateFromDependency()' fails if the dependency lacks a CPE. With this change, the function generates an SBOM when the CPE is absent. The tests also assert that SBOM generation succeeds without a PURL.

⚠️ Note

As you can see in the test assertions, for SPDX and Syft SBOMs, when the dependency CPE is empty, the SBOM output gets cpe:2.3:-:-:-:-:-:-:-:-:-:-:- for its CPE. As far as I can gather from the CPE Naming Spec 2.3, this means that every attribute of the software gets the value "NA" or Not Applicable.

My understanding is that consumers will compare CPEs in SBOMs to CPEs in published vulnerability notices. If the CPEs in an SBOM match the CPEs for a vulnerability, the software is deemed vulnerable. The CPE Matching Spec 2.3 describes how tools are supposed to compare CPEs to understand whether a given piece of software contains a vulnerability.

From what I can tell in that document, assigning an "all N/A" CPE to dependencies with unknown CPEs is our best way to avoid false positives. We don't want a dependency with unknown CPE to set off alarms that it's vulnerable to CVEs in unrelated packages, (or, even worse, CVEs in all packages.)

✋ Help

The naming spec and matching spec are dense. I'd appreciate a second set of eyes to confirm if my choice of UnknownCPE makes sense.

Todo:

• Add godoc to UnknownCPE once its value is confirmed

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[fg-j]

I've spent some time playing around with a Golang implementation of the CPE2.3 naming and matching specs: https://github.com/knqyf263/go-cpe. As you can see in this Go playground example, the UnknownCPE I've chosen is consistently disjoint with other CPEs. This gives me pretty good confidence that it won't cause false positives.