refactor(sbom): add intermediate representation for BOM

[knqyf263]

Overview

This PR introduces refactoring of the SBOM implementation, which is complicated now. The primary focus is to abstract the intermediate representation of BOMs, transition from a CycloneDX-specific model to a more generic structure, and pave the way for supporting additional formats like SPDX with increased efficiency and reduced code duplication.

Key Changes

• Introduction of core.BOM: To address the limitations of the tightly coupled implementation with CycloneDX, we've introduced a new intermediate representation, core.BOM. This abstraction not only facilitates a cleaner and more generic implementation but also simplifies future extensions to support other standards.
• Decoupling and Reducing Code Duplication: Previously, decoding directly from CycloneDX and SPDX to types.SBOM led to redundant code and disparities in feature support between the two formats. By converting to core.BOM first, we streamline the decoding process, ensuring that improvements and fixes benefit both formats equally.
• Preparation for SPDX Support: While this PR lays the groundwork for converting BOM representations to and from SPDX, the actual implementation of SPDX conversion will be addressed in a subsequent PR, furthering our goal of supporting multiple SBOM standards efficiently.
• Unique Identifier Handling: Recognizing the issue of non-unique BOM-Refs in CycloneDX, we have implemented a strategy to include file paths in PURL qualifiers. This PR changes the way of handling colliding BOM-Refs by preparing to switch to UUIDs in cases where PURL collisions occur within an SBOM.

Next Steps

This PR focuses on introducing a more loosely coupled intermediate representation and incorporating reverse conversion capabilities. The conversion to SPDX, alongside additional enhancements and optimizations, will be covered in upcoming pull requests.

Design

Current

Goal

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

[chen-keinan]

@knqyf263 lgtm , I have added some nit comments

[chen-keinan]

nit:
keep function call consist, in some cases dependency.ID called directly in some cases it has a wrapper packageID in another case there is a wrapper ID

[knqyf263]

If it is called once, I'd call dependency.ID directly. If it is called several times. I defined packageID. As you said, ID and packageID should be aligned. Fixed in 0e025f9. Thanks!

[DmitriyLewen]

Can you help me understand why we can't just always use dependency.ID?

---

If it is called once, I'd call dependency.ID directly. If it is called several times. I defined packageID

Add packageID:

• pkg/dependency/parser/java/pom/parse.go

Use dependency.ID:

• pkg/dependency/parser/swift/swift/parse.go

[DmitriyLewen]

@knqyf263 take a look comment above.

[knqyf263]

Fixed. But it is not that strict policy. It won't end the world even if we don't follow it.
1057d92
5bfb04c

[DmitriyLewen]

Looks good. Left 2 comments.

[codefromthecrypt]

@knqyf263 what do you use to draw that diagram? looks neat.

[knqyf263]

@codefromthecrypt This one https://excalidraw.com/

[knqyf263]

@DmitriyLewen @chen-keinan I've resolved all comments. Can you please take another look?