How much compatibility are we planning to have with Trustification V1 UI?

[carlosthe19916]

@bobmcwhirter and others, in light of the comment #78 (comment)

It seems we are populating the Advisory model with CSAF + CVE files. I have nothing against that but it made think:

How much are we going to deviate the modeling between Trustification and Trustify? Can we guarantee >= 95% compatibility or less?

• In Trustification the UI assumes that each advisory is only a CSAF file and renders data accordingly.
• Each Advisory contains information about Products (see the image below). This wound't be possible if we merge CSAF and CVEs together in Advisories right?

This is not much of a technical question but more about what would be our goal in terms in compatibility with Trustification so I can also know what to expect from the backend to render things accordingly in the UI.

[bobmcwhirter]

Here's the way I'm thinking about it...

Vulnerabilities exist, and generally-speaking we learn of them via CVEs and the NVDB etc.

But... there could be other databases of vulnerabilities, perhaps private per-customer or such.

Advisories may be authored by an untold number of organizations who are responsible for addressing vulnerabilities.

A CVE document is not just an enumeration of a vulnerability but also a pretty low-effort/low-value advisory, often times.

OSV schema exists and gathers up & aggregates a lot of advisories (about CVE vulnerabilities) from various sources (RustSec, Ubuntu, etc). Those are advisories that have severities and relate to ... things.

CSAF is another format of advisory, which happens to be used by Red Hat (and others?) but is not the only sort of advisory we want to track. It also addresses vulnerabilities, with severities, related to ... things.

Those ... things can be identified a myriad of ways. Red Hat (and others) use CPE, or Common Product Enumeration descriptors. This is where our concept of "Product" arises.

Other advisory formats, non-CSAF flavored, can also use CPEs.

CSAF and other advisories can also use pURLs instead of CPEs.

A variety may even use hashes/checksums in the form of SHA256 or other content-addressible identifiers.

That's a lot of words to then get to...

Our UI should have zero awareness of CSAF. It's just a serialization format for information. Our database schema ignores CSAF. And CVE. And any other format. We're trying to instead model information, which just-so-happens to arrive in some previously-known format such as CVERecords, OSV schema or CSAF documents.

So, instead of thinking "render a CSAF file", I think we should approach it as "Render an advisory" and be flexible enough to describe the "Affected Things", which may be products, pURLs, or other identifiers.

Likewise, the scoring may be in CVSS3.1 format, or in the future CVSS4.0 format, which has different fields. A single system may contain severities in both formats. And an advisory may actually have both a CVSS3.1 and CVSS4.0 severity for the same context, depending on how arbitrary unknown future people write advisories.

Similarly, for SBOM stuff, really what we'll want to display is "this thing relates to those things in some particular way" as opposed to "render an SPDX SBOM", since we will support SPDX, CycloneDX and who-knows-what-the-future-might-bring formats.

Once again, we try to boil it down to what information is being expressed through these arbitrary serialization formats currently used to deliver that information to The System.

[bobmcwhirter]

So, going back to the original question...

Perhaps we have Product Information table if there's CPEs related to the Advisory.
Perhaps we also have a Package Information table if there's pURLs related to the Advisory.
Perhaps we also additionally have an Artifact Information table if there're things described by SHA256 hashes or whatnot.

[carlosthe19916]

It makes what you described.
I know my question specifically mentioned the advisories but I was really wondering in the whole app: SBOMs, CVEs, Advisories, etc.

• How much compromised are we going to be to serve the same UI as in Trustification regardless of how the modeling is structured?
• I was under the assumption that the UI will be 99%-100% equivalent as the Trustification UI. But it seems I might be wrong.

From your answer it feels like Some things might change.

• If we will assume that some changes will be inevitable. Then, I'm thinking that it might make sense for me to collect some feedback from the UX team to understand what they think is wrong or can be enhanced into Trustification (v1) and evaluate how to match their ideas with the "changes we will have in the Models and abstractions within Trustify"

[bobmcwhirter]

I don't think strict fidelity to the v1 UI is a requirement. We're trying to redo and rework things that were not well-understood the first time around.

We should have equivalent functionality... explore things and their relationships, be those things products, vulnerabilities, advisories... dependencies/dependents.. etc.

I agree talking to UXD and driving a rethink across the UI is probably very smart.

[carlosthe19916]

Thanks for the detailed reply @bobmcwhirter! I'll close the discussion. If we need to further discuss it we can open it again in the future