TrivyAnalysisTaskIntegrationTest#test fails with Trivy v0.51.2

[nscuro]

Current Behavior

Trivy v0.51.2 was released today, and since our integration tests run against Trivy's latest tag, they picked up the new release.

The test asserting for vulnerabilities in woodstox-core are failing. Trivy no longer reports vulnerabilities for it.

dependency-track/src/test/java/org/dependencytrack/tasks/scanners/TrivyAnalysisTaskIntegrationTest.java

Lines 92 to 127 in e87c5cc

	@Test
	public void test() {
	final var project = new Project();
	project.setName("acme-app");
	qm.persist(project);
	final var componentA = new Component();
	componentA.setProject(project);
	componentA.setGroup("com.fasterxml.woodstox");
	componentA.setName("woodstox-core");
	componentA.setVersion("5.0.0");
	componentA.setClassifier(Classifier.LIBRARY);
	componentA.setPurl("pkg:maven/com.fasterxml.woodstox/[email protected]");
	qm.persist(componentA);
	final var analysisEvent = new TrivyAnalysisEvent(List.of(componentA));
	new TrivyAnalysisTask().inform(analysisEvent);
	assertThat(qm.getAllVulnerabilities(componentA)).anySatisfy(vuln -> {
	assertThat(vuln.getVulnId()).isEqualTo("CVE-2022-40152");
	assertThat(vuln.getSource()).isEqualTo(Vulnerability.Source.NVD.name());
	// NB: Can't assert specific values here, as we're testing against
	// a moving target. These values may change over time. We do proper
	// assertions in TrivyAnalyzerTaskTest.
	assertThat(vuln.getTitle()).isNotBlank();
	assertThat(vuln.getDescription()).isNotBlank();
	assertThat(vuln.getCreated()).isNotNull();
	assertThat(vuln.getPublished()).isNotNull();
	assertThat(vuln.getUpdated()).isNotNull();
	assertThat(vuln.getCvssV3BaseScore()).isNotZero();
	assertThat(vuln.getCvssV3Vector()).isNotBlank();
	assertThat(vuln.getSeverity()).isNotNull();
	assertThat(vuln.getReferences()).isNotBlank();
	});
	}

The test succeeds when pinning Trivy to v0.51.1. Looks like a regression in Trivy.

Steps to Reproduce

1. Execute TrivyAnalysisTaskIntegrationTest#test

Expected Behavior

The test should not fail.

Dependency-Track Version

4.12.0-SNAPSHOT

Dependency-Track Distribution

Container Image, Executable WAR

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

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

[nscuro]

Not a regression, but an API change: aquasecurity/trivy#6633

Application.libraries was renamed to Application.packages: https://github.com/aquasecurity/trivy/pull/6633/files#diff-6e749acacaaabfff86d6fd4081426955f2ec744bff55dd5e9def2a2a020d62d1

Following this rename in our code here:

dependency-track/src/main/java/org/dependencytrack/parser/trivy/model/Application.java

Lines 23 to 25 in e87c5cc

	public class Application {
	private String type;
	private ArrayList<Library> libraries;

Makes the test pass again.

Question is how do we deal with this. Updating to 0.51.2 behavior will break things for users with older Trivy versions.

[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.