Open esnible opened 1 year ago
I came across this problem too. While waiting for it to be fixed, I managed to work around it for now by filtering the SBOM with this jq command:
jq '.components |= map(select(.name != ""))' sbom.json > sbom-filtered.json
Current Behavior
If I upload a CycloneDX SBOM with an invalid name (and/or?) purl DependencyTrack is unable to analyze the rest of the SBOM.
For example, I had an SBOM that included the component:
The UI couldn't see it at all and the API could see 12698 components but 0 vulnerabilities.
Removing this component allowed 1435 vulnerabilities to be identified.
The logs show
Steps to Reproduce
... to any SBOM with >0 vulnerabilities.
Expected Behavior
I'd like to see DependencyTrack complain about the invalid Component metadata but I am not sure where it should surface that complaint in the UI.
I'd like SBOM processing to continue when such a component is part of the SBOM
Dependency-Track Version
4.8.2
Dependency-Track Distribution
Container Image
Database Server
N/A
Database Server Version
No response
Browser
Google Chrome
Checklist