Put `/v1/bom` overwrite fields like `classifier` in an existing Project

[ybelMekk]

Current Behavior

In DependencyTrack version 4.12.x and above, after initially creating a project and then updating it with an SBOM, the Project classifier set to APPLICATION in this case gets overwritten to CONTAINER. I’m wondering if this behavior is expected and possibly an undocumented change, as earlier versions of DependencyTrack didn’t overwrite the classifier in this way.

I also tried excluding the SBOM upload request and instead used the bomRef in the project creation step, but this didn’t produce/upload sbom with the same behavior as v1/bom.

Additionally, the SBOM processing neither completes successfully nor returns an error when bomRef is set.

Steps to Reproduce

1. Create a project using PUT v1/project with tags.
2. Upload the SBOM using v1/bom with autocreate set to false.

The returned project resource shows that the classifier has changed from APPLICATION to CONTAINER.

Expected Behavior

Expected the project resource to remain in the same state as before the SBOM upload to the existing project.

Dependency-Track Version

4.12.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

15

Browser

Google Chrome

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[larsriehn]

We encounter the same behaviour (Version 4.12.1).
Originally we create the projects with classifier CONTAINER or LIBRARY and with a SBOM upload they get overwritten as APPLICATION.
This is not what I expect.

[nscuro]

DT does not currently track which properties were manually modified, so it can't differentiate between a value having changed legitimately as a project's BOM evolves, or due to a manual change having been performed before.

A cheap solution could be to just keep track of the names of fields that were modified manually (i.e. via a new array column).

[ybelMekk]

When you say "manually," do you mean the system or me deciding whether a project is categorized as this or that? 🤔

With the new implementation, the code respects the SBOM and overrides certain fields in the project's configuration. However, I could argue that if you create your own project and then upload the SBOM to it, I would implicitly expect the project's values to remain the same. 😊

On the other hand, if you choose to use the SBOM upload with the auto project creation feature, I wouldn’t expect anything beyond defaults or values from other sources. 🚀

[larsriehn]

I agree with @ybelMekk.
Besides that, we create the SBOM with Trivy. Trivy sets "type": "application" with some unknown magic. There is no input parameter for Trivy to set a dedicated type.
If I am not able to set the classifier at the project creation in Dependency Track, I don't see a chance to set it elsewhere.

[nscuro]

With "manual" I meant any change that is not done implicitly via BOM upload. If you set the classifier upon project creation, that field should be marked as "locked" or "overwritten" or whatever, such that processing a BOM upload won't overwrite it.

[ybelMekk]

@nscuro agree 😌

[ChiragJaniEdlevo]

Hi @nscuro,

Thank you for looking into the issue regarding license resets. I wanted to highlight some additional considerations to help ensure the solution is robust and accommodates various scenarios. Manual changes in Dependency-Track span across several areas like suppression, license management, and application tagging (as mentioned in other discussions). However, licenses require special handling due to their criticality in compliance and cost management.

Scenarios to Consider

1. Packages Missing License Information:

   • For older packages without license data, manual setup of license information should be allowed. In this case, SBOM uploads should not overwrite the manually configured license.

2. Version-Specific License Changes:

   • A common scenario is when a package’s license changes across versions, e.g., version 1 uses license type X, and version 2 transitions to license type Y. This is often seen when open-source software becomes commercialized.
   • A solution here should enable version-specific license configurations, allowing manual or automated updates depending on the context. For example:
     • Version change highlights a compliance or cost impact.
     • The reverse scenario (commercial software going open-source) could also occur, requiring similar flexibility.

3. Internal Packages Without Licenses:

   • Many organizations use internal packages missing license information. In such cases, manual license assignments should not be overridden by SBOM uploads or other automated processes.

Suggested Solution

A possible approach could be to make this behavior configurable. Administrators should have the ability to define how license updates are handled in each scenario, tailoring the solution to their organization’s specific needs. This aligns with the idea that a "one-size-fits-all" approach is rarely effective in diverse environments.

By allowing configuration at the administrative level, Dependency-Track can better support both manual and automated workflows while ensuring compliance and cost objectives are met.

Looking forward to your thoughts on this approach!