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

feat(sbom): keep internal uuid to identify components #7550

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

knqyf263
Copy link
Collaborator

@knqyf263 knqyf263 commented Sep 19, 2024

Description

There is no guarantee that this approach will reliably identify identical components. In the current implementation, it is possible for multiple components to have the same name and type.

To prevent this, I used BOM-Ref in CycloneDX using the BOM-Ref, but it does not work in SPDX, and furthermore, the BOM-Ref is optional and may not exist.

Currently, intermediate BOMs are used internally to abstract multiple SBOM implementations, and each component is assigned a UUID. This ensures that the same component can be reused.

Related PRs

Checklist

  • I've read the guidelines for contributing to this repository.
  • I've followed the conventions in the PR title.
  • I've added tests that prove my fix is effective or that my feature works.
  • I've updated the documentation with the relevant information (if needed).
  • I've added usage information (if the PR introduces new options)
  • I've included a "before" and "after" example to the description (if the PR is a user interface change).

@knqyf263 knqyf263 self-assigned this Sep 19, 2024
@knqyf263
Copy link
Collaborator Author

@DmitriyLewen @afdesk I'm not confident about this idea and would like to get thoughts before proceeding with implementation.

@DmitriyLewen
Copy link
Contributor

Just make sure I got you right:

  1. (current logic): we create core.Component for each component from SBOM file (when unmarshalling SBOM file).
  2. (new logic): we will store UUID of these components in Package/Application/OS.
  3. (current logic): we will check packages/applications/os as usual (vulnerabilities etc.)
  4. (new logic): (for sbom formats): instead of creating new components for packages/applications/os - we will check each Packages/Applications and compare with original SBOM by UUID to use original component. In this case we will take only parsed/sorted components (packages/apps).

is this right?


The solution looks good, and “on paper” it should work.

@knqyf263
Copy link
Collaborator Author

Right. Other advantages are that types, properties etc. can also use the values of the original component.

@DmitriyLewen
Copy link
Contributor

I think this is good solution.
let's try to implement this - I hope we won't find any hidden problems in this solution

Copy link

This PR is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Nov 20, 2024
@DmitriyLewen DmitriyLewen removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants