Multi SBOM Upload for one Project: Allow amending or extending the SBOM of a given project

[lsauer]

Current Behavior:

When uploading a SBOM all files are replaced. This seems intuitive and logical

Proposed Behavior:

Many repos are composites these days of all sorts of languages and workflows. There is no one SBOM scanner that can handle it all.

To scan the entire Repo on an enterprise-level many individual scanners are used each creating a SBOM based on some kind of heuristics. There would be the possibility of merging the SBOM results with e.g. the cyclonedx cli together and then uploading it all. But that shifts logic unnecessarily to the client and individuals, as this is something everyone will face in a medium to large enterprise. It would be more convenient if that could be handled in a secure way by the DT.

Where for a project a multi-sbom is started with a handshake that give the client a key that it needs to upload SBOMs along with this key in the HTTP header. Then there is another API call of: Finish Upload DT then does the cyclonedx cli merging of all the uploaded files, generates one SBOM and continues with its existing logic.

Workflow API: GET MultiSBomToken API: PUT SBOM1 (+ HEADER w. TOKEN) API: PUT SBOM2 (+ HEADER w. TOKEN) API: PUT SBOM.....n (+ HEADER w. TOKEN) API: GET MultiSBomFinishAndMerge

[redaabdellah21]

hi @lsauer, wouldn't it be a little unorganized? for an example, having a mix of npm components and maven components, wouldn't it be hard to track for the developpers? another approche is to be able to create a batch inside of which you can create multiple projects and there you can have like, a project for your front, a project for your back... it would be easier for developpers to keep up with.

PS: i am not a contributer, just a user who had the same question as you.

[stevespringett]

Possible duplicate of #728

im not a fan of allowing DT to append as it will result in unexpected dependency graphs and other anomalies that will limit its utility. There’s also three different algorithms the CLI uses to append each resulting in slightly different results. Rather, I think supporting parent/child projects as described in #84 would likely be much cleaner, especially if the UI allowed both independent and aggregate views of inventory and risk.

[lsauer]

Yes, its a Duplicate of #728. I didn't see that issue. Understood and I share your both your thinking. But in an enterprise there are many repos, and much tinkering going on within. Without delving into psychology and corporate culture, let's agree it is not a perfect world

Still the status quo of SBOM should be documented to allow other people to make decisions based on their function and stake in the enterprise rather than the project. Getting the whole picture is important.

Steve, for instance trivy will use the module name in the graph and go from there. So I don't see anything odd in the dependency graph if it is even available. Well there are also several ways to handle sets, so I understand that it is not a straightforward way of merging.

It is not a parent/child thing relationship or question. In many instances a tool or auxiliary script can certainly be seen as a child when the relationship is one of importance. But in case of a monolithic repository with various microservices and these services being written in different languages based on their performance needs it is different. These may then be scanned by different SBOM generators and this is where my questions originates from. In addition a lot of other scenarios I didn't think about.

IMHO it makes sense to outsource this logic to DT rather than the "clients".

[stevespringett]

Your example of a monorepo with many microservices each having their own SBOM is interesting. Why exactly would you want to merge all of the SBOMs into one? I don't understand the use case. If merged, how you will be able to attribute license and security risk on merged SBOMs since you won't be able to tie it back to the microservice it originated from?

Attribution is already difficult in monorepos. Merging SBOMs will make it more so.

[lsauer]

Sure, let me explain.

Be aware that the different SBOMs in the aforementioned scenario, which is not rare, results from different language platforms, requiring different SBOM scanners.

Merging them together is not great, but I understand this as a workaround to the current shortcoming of DependencyTrack. Premise: To understand, there is a convention to stick to the naming scheme of "PROJECT_KEY.REPO_KEY" throughout the enterprise toolchain of git-frontend, CI/CD server, Statical Code Analysis, Binary Repo mostly for the sake of simplifying automation.

Correct me if I am wrong, yet right now there is no possibility of uploading different SBOMs to a project and keeping them as separate entities that could even be treated as sets within the project on which you can run set-operations like: overlap, distinct, uique.

Regarding the attribution: Trivy seems to mention the absolute sourcefile path as the root of the dependency by treating the path as a separate module whose name is the absolute path. At first I thought it is a bug, but this is exactly what I've been looking for. I don't know if you can define the definition-file it in the SPDX Spec as well, but if you could why would trivy go this route.

[chalbersma]

Your example of a monorepo with many microservices each having their own SBOM is interesting. Why exactly would you want to merge all of the SBOMs into one? I don't understand the use case. If merged, how you will be able to attribute license and security risk on merged SBOMs since you won't be able to tie it back to the microservice it originated from?

Attribution is already difficult in monorepos. Merging SBOMs will make it more so.

One none, monorepo use case to consider. Let's say you have a project with code and a docker container that runs that code. You might have one SBOM that describes all the code dependencies and one that describes the dependencies of the build docker container (with OS packages etc...)