Validate uploaded BOMs against CycloneDX schema

[nscuro]

Current Behavior

Uploaded BOMs are currently not validated against the CycloneDX schema.

Users who upload (unknowingly) invalid BOMs only get to know about that fact when inspecting the logs of the API server. Further, error logs from the BOM parser can be hard to understand. Instead of spewing out gibberish error messages, it should be stated clearly if the BOM is invalid to begin with.

Proposed Behavior

Validate uploaded BOMs against the CycloneDX schema synchronously, as an additional step of handling upload requests.

Users and clients should know immediately if the uploaded file is invalid and has no chance of being ingested.

This is already implemented in Hyades and merely needs backporting: https://github.com/DependencyTrack/hyades-apiserver/blob/ef39532e0b98962b7fc290902cb33edba52ade51/src/main/java/org/dependencytrack/resources/v1/BomResource.java#L438-L466

Note
There may be tools out there that generate BOMs that are valid JSON / XML, but not entirely schema conform. As a consequence, there will be users who will have to adjust / fix their tooling first. Dependency-Track should have an "escape latch" to disable validation for those users. However, validation should default to on.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[melba-lopez]

+1 on this.

• Not all DT Users will have admin privileges or the knowledge about cyclonedx cli tool for further validation.
• A general user should be able to get a toast notification that the BOM does not meet specification (and that is why the bom failed to upload).
• Additionally, it would be helpful for non-admin users to be able to navigate within DT to upload the BOM to a specification validator, so that they may see where the problem resides and/or get output with this data.

If a 3rd party vendor, supplier, etc. provides a malformed SBOM, giving users the basic data of why and where the problem is would reduce time to remediation/analysis.

[jhlmco]

There's plenty of tools to handle sbom validation. Perhaps just a response from dependency track saying "Malformed CycloneDX SBOM". I wouldn't duplicate what other tooling is doing.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.