-
-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicated Components #3448
Comments
I'm currently evaluating DT as a compliance tool. Afaik there's no sane alternative (i. e. below a couple of thousands $/y). I also see that the project has some activity (despite the 600+ issues, many of them several years old). I'm just wondering if I'm too stupid to use it correctly or too stupid to find similar issues. Apparently, people DO use DT - but the component duplication renders it somewhat useless for license compliance imho. Where's the catch? Should I start digging into the code myself asap? Sorry for randomly pinging @lukas-braune and @nscuro - I just need to know if it's a layer 8 issue or an actual bug. |
I'm going to ignore the snarky bits in your issue, but please keep in mind that this is a project driven by volunteers, which as you pointed out correctly, you didn't pay a penny for :) Generally though, yes the license stuff needs more work. It hasn't exactly been a priority, but this is an open source project so community involvement is necessary to drive things forward.
The catch is that component identity is not limited to just a PURL. There are CPEs, hashes, properties, licenses, and things like pedigree and provenance (that haven't yet made it into DT). You can have two components with the same PURL, but different hashes etc. Up until v4.0, Dependency-Track used a global component model that worked like what it reads like you expected. However, it was found that this did not work for various reasons, and decoupling was necessary. Component identity is complicated, and trying to maintain "global" objects for them ends up being a total mess, with different BOMs contributing different and potentially conflicting information, and it gets worse the more metadata you add.
The intention is that the BOMs you're uploading are the source of truth. This is a simple principle and easy to reason about. So ideally, if you wanted your changes to persist across multiple uploads, you would enrich your BOM with additional license information before you upload it. While DT does allow manual modification and creation of components, it's not intended that it is used in conjunction with automatic BOM uploads to the same project. Admittedly, this should be documented better. With all this being said, I'd still welcome you to have a look and see if things can be improved. The project is very much active. |
@nscuro thanks for the quick reply!
Please do, it wasn't my intention to sound snarky. So, instead of manually adding the missing bits I should rather go to, e.g., trivy and check why it hasn't picked up the license information in the first place? Or if that doesn't work build some "middleware" that adds license information I know should be there? Can you point me towards some discussion about component identity issues? <3 |
Current Behavior
Maybe this is the intended behaviour and I'm just stupid, but I'd be surprised.
When I upload the very same SBOM for the very same project just with another version. All the components get duplicated. I can live with different project versions showing up as different projects (albeit confusing), but DT seems to think that the components are genuinely not the same. Even though they have the exact same PURL, name, and version. This doesn't make sense to me.
In my case, right now, I manually add license information for the components where automatic detection failed (for whatever reason). But the next time the pipeline runs and a new SBOM gets pushed - with the very same components - new components get created, policy violations fire and all the manual work was pointless.
Steps to Reproduce
/api/v1/bom
withprojectName=test
andprojectVersion=1.0
/api/v1/bom
withprojectName=test
andprojectVersion=1.1
Expected Behavior
Same PURL should mean same component. Things you add manually to components should not get lost when a new scan comes in - neither directly nor indirectly by duplicating the component.
Dependency-Track Version
4.10.1
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
16
Browser
Mozilla Firefox
Checklist
The text was updated successfully, but these errors were encountered: