Add source attributions for affected component version ranges #2098

sahibamittal · 2022-10-26T14:58:37Z

Description

This PR adds source attributions for affected component ranges.

Starting with the OSV integration, we now have multiple sources contributing vulnerability intelligence data for the same vulnerability. For example, both the GitHub Advisories and OSV integration may contribute affected version ranges for the same GHSA vulnerability.

By tracking attributions, mirroring tasks are now able to differentiate between affected ranges they previously reported, and those reported by mirroring tasks for other sources. This makes it possible to dynamically prune outdated records, without interfering with other sources' data.

Prior to this PR, the OSV mirroring task would only ever append to the ranges already associated with a given vulnerability, while the GitHub Advisories mirroring task would bluntly replace everything with what was reported by GitHub.

Additionally, this information is exposed via REST API, and displayed in the Affected Components tab of the vulnerability details view:

Users can now see what source reported what, and when.

Addressed Issue

Closes #1815

Additional Details

Internally, Dependency-Track stores version ranges in VulnerableSoftware objects. Based on the data mirrored from sources, VulnerableSoftware records are associated with Vulnerability records, forming an "affected by" relationship.

The relationship between VulnerableSoftware and Vulnerability is M:N, meaning the same VulnerableSoftware record may be associated with multiple vulnerabilities. In fact, some are associated with over 1000 vulns:

We investigated adding the attribution fields to the VULNERABLESOFTWARE_VULNERABILITIES join table (possible with JDO, see this DataNucleus example). But this resulted in very messy code to maintain and update these relationships, so we decided against doing it this way.

Instead, attributions are now a separate object / table that just holds foreign keys to both Vulnerability and VulnerableSoftware. This is similar to the way we handle FindingAttributions already.

Signed-off-by: Sahiba Mittal <sahibamittal98@gmail.com>

src/main/java/org/dependencytrack/resources/v1/vo/AffectedComponent.java

sonatype-lift · 2022-10-26T15:04:52Z

⚠️ 16 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

Signed-off-by: Sahiba Mittal <sahibamittal98@gmail.com>

src/main/java/org/dependencytrack/model/AffectedVersionAttribution.java

Signed-off-by: Sahiba Mittal <sahibamittal98@gmail.com>

src/main/java/org/dependencytrack/tasks/GitHubAdvisoryMirrorTask.java

src/main/java/org/dependencytrack/tasks/OsvDownloadTask.java

src/main/java/org/dependencytrack/tasks/VulnDbSyncTask.java

src/main/java/org/dependencytrack/parser/snyk/SnykParser.java

src/main/java/org/dependencytrack/model/VulnerableSoftware.java

Signed-off-by: Sahiba Mittal <sahibamittal98@gmail.com>

…ns for the same vulnerability Previously, GitHub was blunty overriding any VulnerableSoftware<->Vulnerability relationships established by OSV, while OSV would just append on what's already there. Using attributions for these relationships, this issue is now solved. The performance impact so far has been minimal, although no real benchmarks have been made. Tests are still a WIP and will be added in a later commit. Signed-off-by: nscuro <nscuro@protonmail.com>