docs: adr for sbom dashboard #1575
Conversation
bxf12315
force-pushed
the
adr-sbom-dashboard
branch
2 times, most recently
from
cc3103d to
eb567af
Compare
bxf12315
force-pushed
the
adr-sbom-dashboard
branch
from
eb567af to
f9053cc
Compare
There was a problem hiding this comment.
I am missing the following information in this document:
- What the meaning/definition of the different "total" values? How can we produce this information?
- How do we handle custom licenses and complex SPDX expressions?
- What's the
idpath variable exactly? We have different ways of addressing SBOMs at the moment. Which one do we use here?
I also think that we might want to think about:
- Who's eligible to retrieve that information (authorization)
- Does it make sense caching this information? If so, how?
| "total_licenses": "0" | ||
| } | ||
| ``` | ||
| - Vulnerabilities state |
There was a problem hiding this comment.
What's the reason for having three "state" endpoints? Wouldn't it be simpler to have one?
docs/adrs/00007-sbom-dashbord.md
Outdated
| ## Decision | ||
| Design an endpoint for each of these parts. | ||
| - sbom state | ||
| - **HTTP GET api//v2/sbom/{id}/sbom-status** |
There was a problem hiding this comment.
So far, we don't use kebab-case, why now? Some for the others.
| - Reponse playload | ||
| ```json | ||
| { | ||
| "name": "Sbom-name", |
There was a problem hiding this comment.
Why do we have additional SBOM information (name, version, …) here. But not in the others?
There was a problem hiding this comment.
These all came from the mockup, and I also think they’re not very reasonable; we could consider removing them.
| "version": "0", | ||
| "published_date": "", | ||
| "licenses": [ | ||
| { "name:": "Apache-2.0", "count": "10"}, |
There was a problem hiding this comment.
To my understanding some SPDX licenses are actually license expressions. How do we handle those?
There was a problem hiding this comment.
We already have spdx_licenses to store the standard SPDX IDs parsed from license expressions.
There was a problem hiding this comment.
Ok, but what's then the meaning of an entry of e.g. MIT?
There was a problem hiding this comment.
Indicates how many times the MIT license appears.
There was a problem hiding this comment.
So MIT OR LGPL-2.1-only would show up as MIT and LGPL-2.1-only? That feels wrong.
There was a problem hiding this comment.
Purely from the perspective of occurrence counts, this does not involve the semantics of specific SPDX expressions and should be fine. Only when dealing with actual license relationships might issues occur.
There was a problem hiding this comment.
So what the benefit of the user having this?
| "total_critical": "0", | ||
| "total_high": "0", | ||
| "total_medium": "0", | ||
| "total_low": "0" |
There was a problem hiding this comment.
To my understanding none is a dedicated severity. So there can 5 vulnerabilities of type none.
| ```json | ||
| { | ||
| "total_packages": "0", | ||
| "total_licenses": "0" |
There was a problem hiding this comment.
Wouldn't that information make more sense in the license state endpoint?
bxf12315
force-pushed
the
adr-sbom-dashboard
branch
from
f9053cc to
16f5b34
Compare
bxf12315
force-pushed
the
adr-sbom-dashboard
branch
from
16f5b34 to
e740005
Compare
2 participants
Rendered preview: https://github.com/bxf12315/trustify/blob/adr-sbom-dashboard/docs/adrs/00007-sbom-dashbord.md