Add primary component detection scorer

[riteshnoronha]

@surendrapathak Added primary component detection to our scoring framework. I have added it as a quality metric. For SPDX we are checking if the relationships contains a describes for a package identifier. For Cyclonedx we are checking if the metadata describes a primary component.

CDX example

SBOM Quality Score:10.0	components:4	/Users/riteshnoronha/wrk/interlynk-io/lynk-api/scripts/samples/misc/ascii-boxes-sbom-cdx.json
+----------+-----------------------------+-----------+-------------------------+
| CATEGORY |           FEATURE           |   SCORE   |          DESC           |
+----------+-----------------------------+-----------+-------------------------+
| Quality  | sbom_with_primary_component | 10.0/10.0 | primary component found |
+----------+-----------------------------+-----------+-------------------------+
SBOM Quality Score:0.0	components:105	/Users/riteshnoronha/wrk/interlynk-io/lynk-api/scripts/samples/misc/ghidra-sbom-cdx.json
+----------+-----------------------------+----------+----------------------------+
| CATEGORY |           FEATURE           |  SCORE   |            DESC            |
+----------+-----------------------------+----------+----------------------------+
| Quality  | sbom_with_primary_component | 0.0/10.0 | no primary component found |
+----------+-----------------------------+----------+----------------------------+

SPDX Example

SBOM Quality Score:0.0	components:1303	/Users/riteshnoronha/wrk/interlynk-io/lynk-api/scripts/samples/spdx/constellation-spdx.json
+----------+-----------------------------+----------+----------------------------+
| CATEGORY |           FEATURE           |  SCORE   |            DESC            |
+----------+-----------------------------+----------+----------------------------+
| Quality  | sbom_with_primary_component | 0.0/10.0 | no primary component found |
+----------+-----------------------------+----------+----------------------------+
SBOM Quality Score:10.0	components:34	/Users/riteshnoronha/wrk/interlynk-io/lynk-api/scripts/samples/spdx/julia.spdx.json
+----------+-----------------------------+-----------+-------------------------+
| CATEGORY |           FEATURE           |   SCORE   |          DESC           |
+----------+-----------------------------+-----------+-------------------------+
| Quality  | sbom_with_primary_component | 10.0/10.0 | primary component found |
+----------+-----------------------------+-----------+-------------------------+

[surendrapathak]

LGTM

[sethmlarson]

@riteshnoronha @surendrapathak Is it true that for SPDX the DESCRIBES relationship must apply to a package instead of a file? I don't see that distinction in the specification.

[riteshnoronha]

Hi Seth, You are right. SPDX specification itself does not explicitly make that distinction. However, our tools are primarily designed with a focus on distributable SBOMs specifically with NTIA minimum element recommendation for SBOM as the backdrop.

NTIA minimum elements requires component-level granularity and package as the primary artifact. This approach facilitates the linkage of components to vulnerability databases using mechanisms such as purl/cpe and swid.To further support this perspective, we have considered Steve Winslow's(@swinslow) article available at https://spdx.github.io/spdx-ntia-sbom-howto/#_2_2_spdx_elements. Hence the addition of the new Check.

Of course, sbomqs is designed to be configurable and this or any check can be turned off with the custom config file.

[sethmlarson]

Thanks for the response @riteshnoronha, did you have a quote that NTIA minimum elements requires the top-level component to be a package? They mention component may be a file in their definition of component:

A unit of software defined by a supplier at the time the component is built, packaged, or
delivered. Many components contain subcomponents. Examples of components include a
software product, a device, a library, or a single file

I'm not an expert at this, only using this tool to evaluate an SBOM I'm creating for CPython. In the specific case I was using the CPython tarball being described as the top-level component instead of the "CPython" package.

[sethmlarson]

Although maybe I should be using packageFileName for this case, hmm. That might be the right approach.

[riteshnoronha]

Yes that's a possibility. Can you share sboms you are working on , would love to see it, i'm assuming for cpython, since you are mostly working with c/c++ code, packages names are not a thing, hence you would need to specify file-names?

[sethmlarson]

@riteshnoronha I've uploaded my draft here: https://gist.github.com/sethmlarson/103891c6cac4d41b11daab89e6c84868

[swinslow]

@sethmlarson @riteshnoronha I agree with the comments above; the DESCRIBES relationship in SPDX 2.3 and earlier does not require that the element be a Package, at least for SPDX conformance purposes. You could have a valid SPDX Document with a DESCRIBES relationship to a File (or multiple Packages / Files / Snippets).

To the question about whether NTIA Minimum Elements requires it to be a Package: that's a great question, and I'm not certain offhand. I'm cc'ing @kestewart in case she has thoughts on this as well!

Strangely, the link to the NTIA Minimum Elements PDF doesn't seem to be working for me any longer. Not sure if that's just an issue on my end or if NTIA changed the URL.

The NTIA report, to my reading, doesn't require that the DESCRIBES'd element be a Package -- though I expect that is going to be the most common use case by far.

Additionally, some of the NTIA mandatory fields (e.g. "Version of the Component") I believe exist in SPDX only for Packages and not for Files. So although it might be possible to come up with an NTIA Minimum Elements SBOM in SPDX format that used just Files and not Packages, I suspect that's very much a rare edge case and would have its own challenges.

[surendrapathak]

In earnest, we mixed up two recommendations, and it is not explicitly limited to 'Package' but seems heavily implied in the documents.
Specifically.

1. Framing Software Component Transparency mapped 'baseline attributes' across SPDX, CyloneDX and SWID. This is the included map on Page 13 of the 2nd Edition.
   
2. In the above context, it is implied that (a) DESCRIBES and CONTAINS are preferred relationships (b) Package and related attributes are preferred mapping to the 'baseline attributes'.
3. SBOM Minimum Elements considers Component Name and Component Version as part of the minimum elements.
   
4. However, the same Minimum Element is comfortable including a single file as a component (potentially open to File and its subattributes in SPDX).
   

So, Seth is correct that FILE is a possible path to compliant SPDX and a compliant Minimum Elements document, but it feels that it is not the preferred implementation.

[riteshnoronha]

@sethmlarson thanks for sharing your SBOM. I looked over it and here are my my findings

Sbom is great and well done, i loaded it into our tool and found it was parsable and was able to detect vulns.

Feedback

1. Tool Information: You have a tool name, and version specified as git, however according to the spec, tool should be specified as "Tool: toolidentifier-version". This will allow for tool version tracking, and associated outputs.
   "Tool: python/release-tools@f58cfa6611dd13f2fb4e4790a8c54f06dddab6bc"

2. Author Information: No sure if you are aware but an email can be speciied for authors using the following syntax. "Person: Python Release Managers (support@email.com)"

3. The primary component has no relationships, not sure if that is intentional.

[sethmlarson]

@riteshnoronha Thank you for the feedback! I'll fix up the SBOM, and yes the top-level package should have a DEPENDS_ON relationship with the other 6 packages. Also what tool are you using in your example?

[riteshnoronha]

@sethmlarson those are from our sbom automation platform (closed beta right now), I can send you an invite if you want to try it yourself.