3 use cases from Trustification

[carlosthe19916]

I previously shared this internally but sharing it as a Discussion as it is relevant to share it here

Trustification compatiblity

Trustification was designed on top of 3 strong Use Cases that involved 3 entities:

• SBOM
• Package
• Vulnerability

The 3 use cases are:

1. SBOM

• Given an SBOM X, give me all packages within that SBOM
• Given an SBOM X, give me all Vulnerabilities that affect that SBOM

2. PACKAGE

• Given a PACKAGE X, give me all SBOM that contain that PACKAGE
• Given a PACKAGE X, give me all VULNERABILITIES that affect that PACKAGE

3. VULNERABILITY

• Given a VULNERABILITY X, give me all SBOMs affected by that VULNERABILITY
• Given a VULNERABILITY X, give me all PACKAGEs affected by that VULNERABILITY

We should provide endpoints to cover those 3 use cases, and IMHO those 3 use cases are not negotiable. Some of the required endpoints are already available, others still need to be created. I'll update which ones are done, but I'll do it tomorrow morning with more time

[ctron]

I think there are some valuable use cases over here: #478 (comment)

For inspiration - here are some questions prodsec wanted to answer with component registry (with OSIDB) ... notice that none of them asked about a specific SBOM:

• Retrieve a specific component by purl
• Retrieve a specific Component dependencies
• Retrieve a specific Component root component:
• Retrieve/Search list of Components by name
• Retrieve latest component used by product stream eg. a list of product streams listing latest components (could be narrowed down to specific component name/version etc) ... note this was the most difficult query to do efficiently and reason for a graph (though we never got around to implementing a real graph)
• Search for Components by regular expression name (and version):
• Retrieve/Search a Product Stream
• List Product Streams
• Retrieve a Product Stream manifest/sbom

then the following (with osidb, but I think trustify gets from vex):

• Given a CVE ID, what products are affected ?
• Given a CVE ID, what components are affected ?
• What products + version + stream contain a given component (e.g. full text search) ?
• Which unfixed CVE are affecting a component ?
• Which unfixed CVE are affecting a product + version + stream ?
• What are the fixed CVE of this a product + version + stream?
• What are the fixed CVEs for a component?
• What are the WONTFIX CVEs for a component?
• What are the WONTFIX CVEs for a product?
• How many CVE’s are filed against a product + version

[carlosthe19916]

Thanks for sharing. Indeed those questions are very relevant.
So far we do not have "Products/Components" but as soon as we have them, we should also aim to answer those questions.

[carlosthe19916]

@jcrossley3

It was a bit late for me to reply in our internal chat but I didn't want to turn off my laptop without expanding a bit which was the original idea of the Package Use case. I am sharing it here because with the latest discussions done internally I believe this use case will either be removed or re-designed

The Package use case was designed this way (Originally on Trustification).

• Lets say we live some years back and we heard that the Log4J package is a vulnerable package everyone is talking about
• As a company I want to know which of all the SBOMs I have contain the Log4J package
• I enter to the UI and because My starting point is a package "Log4j" then I SEARCH for the package in the Package List View
• The search could give me many results, as there can be multiple versions of the same package Log4J
• Each package listed into the Package List view should also contain the list of Vulnerabilities that affect that specific package and version so I am can see which version of Log4J is affected by which Vulnerability
• Finally, once I am able to identify the package Log4j and the Vulnerability I am scared of, then I can select it and see which are the SBOM in my whole portfolio that contain that package

[jcrossley3]

I question the value of the "Package List View". To achieve the goals you describe, I would either go to the SBOM view and query "log4j" to see all the SBOM's that contain it, or I'd go to the Vulnerabilities view and query "log4j" to see which apply to it. Why make me list all the log4j versions first? If I know my version, I can include that in the aforementioned queries. If I don't, how does showing me all the versions help me?

[jcrossley3]

In other words, our resources (in REST speak) are Vulnerabilities and SBOMs. Packages are not a resource -- they're a means of filtering our resources.

[carlosthe19916]

I believe as long as we keep the spirit of the use case it should not matter whether we answer the question through the "SBOM List" or the "Vulnerabilities List" as you suggested.

And the spirit of the use case is "given a package (let's say log4j) I want to know which are the SBOMs that contain that package. Also Given a package (let's say log4j again) I want to know which are the set of vulnerabilities that affect that package"

Again, the UI can 100% change (I believe everyone is open for that). But ideally, we should be able to keep original spirit of the use case. WDYT?

[jcrossley3]

I dig it. I can also imagine convenient links from each view to the other: with a single click, i can switch from sboms filtered by package to vulnerabilities filtered by the same package and vice versa.