Skip to content
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

Open
2 tasks done
black-snow opened this issue Feb 7, 2024 · 3 comments
Open
2 tasks done

Duplicated Components #3448

black-snow opened this issue Feb 7, 2024 · 3 comments
Labels
question Further information is requested

Comments

@black-snow
Copy link

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

  1. Fire up DT v4.10.1
  2. create some SBOM
  3. post the SBOM to /api/v1/bom with projectName=test and projectVersion=1.0
  4. post the same SBOM to /api/v1/bom with projectName=test and projectVersion=1.1
  5. in DT, navigate to components, search for one contained component
  6. you'll find it twice with the exact same data

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

@black-snow
Copy link
Author

black-snow commented Feb 8, 2024

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.

@nscuro
Copy link
Member

nscuro commented Feb 8, 2024

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.

[...] 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.

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.

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.

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 nscuro added question Further information is requested and removed defect Something isn't working in triage labels Feb 8, 2024
@black-snow
Copy link
Author

@nscuro thanks for the quick reply!

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 :)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants