feat(sbom): add `BOMID` field to match packages and decoded BOM components
Description
This PR fixes an issue with matching vulnerabilities to packages and components when working with SBOM (Software Bill of Materials) files. The main problem was that vulnerabilities weren't being properly matched to their corresponding components during SBOM processing, particularly in VEX (Vulnerability Exploitability eXchange) filtering scenarios.
The solution introduces a new BOMID field that provides a reliable UUID-based identifier for matching components between decoded SBOM data and vulnerability information. This ensures accurate component-to-vulnerability associations in both SBOM scanning mode and regular scanning modes.
Made Changes
- Added BOMID field: Introduced BOMID uuid.UUID field to PkgIdentifier struct in pkg/fanal/types/package.go to uniquely identify SBOM components
- Enhanced component matching: Updated Match() method to check BOMID first when matching package identifiers
- SBOM decoding integration: Modified pkg/sbom/io/decode.go to populate the BOMID field with the component's UUID during SBOM decoding
- Improved vulnerability mapping: Refactored pkg/sbom/io/encode.go to use BOMID instead of BOM-Ref for vulnerability-to-component mapping, providing more reliable associations
- Fixed VEX filtering: Updated pkg/vex/vex.go to use a hybrid approach for component matching:
- Uses BOMID for SBOM mode scenarios
- Falls back to UID for regular scanning modes
- Added comprehensive documentation explaining the key selection logic
These changes ensure that vulnerabilities are correctly filtered and associated with their corresponding components regardless of whether they come from SBOM files or regular package scans.
Related issues
- Close #9593
Related PRs
- [x] #9439
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).
This PR is stale because it has been labeled with inactivity.