[Question]: CPE detection/generation for manually added components

[bahrb]

We're planning to scan our docker images with syft and providing the result via cyclonedx SBOM to dependency-track. Our images include manually added zip's of jdk and tomcat. Syft detects this components but a proper cpe is missing to match against the nvd by dependency-track. My question is, how to achieve the cpe generation? Can this be done by adding a special file(generated by us) with these information which gets picked up by syft? Is it possible to configure content detection of such files via glob patterns or something else?

Thanks in advanced!

[wagoodman]

Hey @bahrb we do generate CPEs for packages for the json format, however as of today the CycloneDX format does not show these generated CPEs. We almost added support for this but noticed a couple of things that made us hesitate:

1. There is a deprecation warning with the use of CPEs in the CycloneDX spec.
2. Only one CPE can be provided, however, we generate multiple CPE candidates based on the discovered package information. It isn't clear which CPE is "better" than another among the generated candidates, so opted to not include any CPEs for the mean time.

That being said, nothing is technically preventing this feature from being added (to here and here). The only risk is that the CPE selected to be placed in the document may not be the best candidate for matching against NVD.

[bahrb]

Thank you for the clarification @wagoodman. I totally understand the reservation to support or implement a deprecated feature. When cpe is out of the game, there are just swid or purl left over to achieve what we want. According to the cycloneDX doc, just these three fields can be used for identifying known vulnerabilities. Is there a way to make a parser pickup such information(purl/swid) from a file or something else?

[wagoodman]

We support pURL today, but not SWID. pURLs are generated from any data discovered about a package, which is different for each ecosystem. For instance:

• https://github.com/anchore/syft/blob/v0.19.1/syft/pkg/rpmdb_metadata.go#L49
• https://github.com/anchore/syft/blob/v0.19.1/syft/pkg/java_metadata.go#L54
• https://github.com/anchore/syft/blob/main/syft/pkg/dpkg_metadata.go#L37

...these examples show that the pURL is crafted from different underlying metadata.

Just to clarify, I have two interpretations for what you're asking for:

1. you are looking for a way to have a "hints" file where you can supply manually-crafted pURLs (or CPEs / SWIDs) for a package already discovered by syft today.
2. you are looking for a way to have a "hints" file where you can supply additional packages that syft is not discovering today, and additionally provide information about these package hints such as pURLs/CPEs/SWIDs?

Which is closest to your ask?

There have been some discussions around allowing something like this: https://github.com/anchore/syft/issues/31, about supporting detection of SBOMs within an image and incorporate the contents into the generated SBOM.

[bahrb]

@wagoodman thank you for your detailed answer!

My question tends more to interpretation 1, to provide a hint for already discovered packages but without valid CPEs or pURLs. Meanwhile I found a solution for tomcat. The binary distribution is already available on maven, so a valid/working pURL is the result.

Another thing I was stumbling across is the JDK and the different vendor implementations. It is a similar problem like tomcat above. We added a manual jdk(azul zulu) from zip to our docker image, which was recognized by syft but due to missing pURL, SWID or CPE, dependency-track didn't match against any database.

Instead of using an extracted zip, I changed it to use the official azul docker image as foundation which result in a valid pURL for the zulu JDK as well, because it's retrieved from azul's own deb-repo. The interesting part here is, since most of CVE's for the JDK are vendor specific to Oracle or OpenJDK you wont get a match for zulu JDK though it is build on OpenJDK and the fixes also apply to their JDK. So one could miss a security issue in zulu JDK because it is not issued for this vendor but instead for Oracle or OpenJDK. Hence, a hint to pickup another CPE for Oracle or OpenJDK would bring the benefit of discovering such gaps. But it's still an edge case.

[spiffcs]

Glad to see the initial issue was solved @bahrb!

Meanwhile I found a solution for tomcat. 
The binary distribution is already available on maven, so a valid/working pURL is the result.

As to your follow up question about

"to provide a hint for already discovered packages but without valid CPEs or pURLs"

This current feature is not planned, but we'd be happy to review PR from anyone who is looking for this kind of corrective feature for fine tuning CPE generation.

The rough part is if it's an append of the corrective cpe, which works for spdx/syft raw, or a replace, which would be the case for cyclonedx.