Best Practices for SBOM Management Across Multiple Environments and Handling Replacements

[schl3sch]

Hi, great to hear that you will be able to create collections in the next version of Dependency Track, this will open up a lot of new possibilities for organising projects.

However, I have a challenge: I only want to store SBOMs for software that is actually deployed. So if I have different environments and each of these is deployed on a different server, it would be nice to be able to replace or update the SBOM via CI/CD when a newer version of that project is deployed. Is there a way to do this because as far as I know to replace/update an SBOM using the API, the name and version must be exactly the same. (In my case, only the version would be different).

Example:

• ProjectX:
  ProjectX v1.2 is deployed on test Server
  ProjectX v1.4 is deployed on production Server1
  ProjectX v1.3 is deployed on production Server2

• ProjectY:
  ProjectY v2.2 is deployed on test Server
  ProjectY v2.4 is deployed on production Server3
  ProjectY v2.3 is deployed on production Server2

I would like to know if I deploy a newer version of ProjectY (v2.5) on Production Server3, how could I replace or update the Sbom for the Production Server3 environment in Dependency Track via the API.

In general, is there a best practice on how to organise in a scenario like this, should I use tags for environments (then my next question would be how to create tags for projects via the curl command) or is there a better way?