VEX Documents (including OpenVEX) And .trivyignore Are Ignored During SBOM Ingestion And Re-analysis
Current Behavior
Dependency-Track, a popular software bill of materials (SBOM) management tool, currently ignores both .trivyignore-based suppressions and externally attached VEX documents (e.g., OpenVEX) during SBOM ingestion and re-analysis. This behavior is causing issues for users who rely on automated pipelines to generate SBOMs using Trivy.
The Problem with .trivyignore Suppressions
When using Trivy to generate SBOMs, users can suppress certain CVEs by creating a .trivyignore file. However, these suppressions are not respected by Dependency-Track, causing the suppressed CVEs to still appear in the tool's interface. This is a significant issue for users who rely on automated pipelines to generate SBOMs, as it requires manual intervention to apply the suppressions.
The Problem with External VEX Documents
In addition to ignoring .trivyignore suppressions, Dependency-Track also ignores externally attached VEX documents, such as OpenVEX. Users have attempted to use OpenVEX to attach a VEX document to the SBOM before pushing it to Dependency-Track, but these suppressions are also ignored. This is a significant issue for users who rely on external VEX documents to manage their SBOMs.
The Workaround
While it is possible to manually download the VEX report from Dependency-Track, edit it in-place to match the tool's expected schema, and upload it back, this is not a scalable solution for automated pipelines. This workaround requires uploading the BOM, downloading the generated VEX, programmatically modifying it, and re-uploading it, which is not feasible in CI/CD environments.
Expected Behavior
Dependency-Track should respect .trivyignore suppressions during SBOM ingestion, accept and apply external VEX documents such as OpenVEX, and allow automated suppression flows during SBOM push. Additionally, it would be beneficial to support global VEX or suppression lists, allowing teams to centrally manage suppressions across all projects and pipeline executions.
Steps to Reproduce
To reproduce this issue, follow these steps:
- Create a Trivy-generated SBOM and suppress one or more CVEs using .trivyignore.
- Upload the SBOM to a Dependency-Track project.
- Observe that the CVEs marked to be ignored still appear.
- Create a VEX document using vexctl (OpenVEX format) containing not_affected entries for the same CVEs.
- Attach the VEX to the SBOM or upload it separately using the “Apply VEX” feature.
- Observe that the VEX is either ignored or rejected due to schema mismatch.
- Manually download the VEX report from the same project, edit it in-place to match DT’s expected schema, and upload it back — now suppression works.
Possible References
- #3554 Export and Import VEX fails to match Vulnerabilities correctly
- #1921 Help needed for BOM-VEX link
Dependency-Track Version**
4.13.0
Dependency-Track Distribution
Container Image
Database Server
N/A
Database Server Version
No response
Browser
Google Chrome
Checklist
- [x] I have read and understand the contributing guidelines
- [x] I have checked the existing issues for whether this defect was already reported
VEX Documents and .trivyignore Ignored During SBOM Ingestion and Re-analysis: Q&A ====================================================================================
Q: What is the current behavior of Dependency-Track regarding .trivyignore suppressions and external VEX documents?
A: Dependency-Track currently ignores both .trivyignore-based suppressions and externally attached VEX documents (e.g., OpenVEX) during SBOM ingestion and re-analysis.
Q: Why is this behavior a problem for users?
A: This behavior is causing issues for users who rely on automated pipelines to generate SBOMs using Trivy. The suppressions are not respected by Dependency-Track, causing the suppressed CVEs to still appear in the tool's interface.
Q: What is the workaround for this issue?
A: While it is possible to manually download the VEX report from Dependency-Track, edit it in-place to match the tool's expected schema, and upload it back, this is not a scalable solution for automated pipelines. This workaround requires uploading the BOM, downloading the generated VEX, programmatically modifying it, and re-uploading it, which is not feasible in CI/CD environments.
Q: What is the expected behavior of Dependency-Track?
A: Dependency-Track should respect .trivyignore suppressions during SBOM ingestion, accept and apply external VEX documents such as OpenVEX, and allow automated suppression flows during SBOM push. Additionally, it would be beneficial to support global VEX or suppression lists, allowing teams to centrally manage suppressions across all projects and pipeline executions.
Q: How can I reproduce this issue?
A: To reproduce this issue, follow these steps:
- Create a Trivy-generated SBOM and suppress one or more CVEs using .trivyignore.
- Upload the SBOM to a Dependency-Track project.
- Observe that the CVEs marked to be ignored still appear.
- Create a VEX document using vexctl (OpenVEX format) containing not_affected entries for the same CVEs.
- Attach the VEX to the SBOM or upload it separately using the “Apply VEX” feature.
- Observe that the VEX is either ignored or rejected due to schema mismatch.
- Manually download the VEX report from the same project, edit it in-place to match DT’s expected schema, and upload it back — now suppression works.
Q: Are there any possible references or related issues that I should be aware of?
A: Yes, there are two possible references that you should be aware of:
- #3554 Export and Import VEX fails to match Vulnerabilities correctly
- #1921 Help needed for BOM-VEX link
Q: What is the Dependency-Track version that is affected by this issue?
A: The Dependency-Track version that is affected by this issue is 4.13.0.
Q: What is the recommended browser to use when experiencing this issue?
A: The recommended browser to when experiencing this issue is Google Chrome.
Q: Have you checked the existing issues for whether this defect was already reported?
A: Yes, I have checked the existing issues and I have confirmed that this defect was not already reported.