OWASP Dependency-Check integration: CVE triage via API

Which Dependency-Check CVEs actually apply?

OWASP Dependency-Check matches your dependencies to CVEs through identifiers such as CPEs, which can flag the wrong package or a version you do not run. Konvu has no native connector for Dependency-Check. Your build sends the results to the Konvu API, and Konvu checks each CVE against your code and returns a verdict with evidence.

See it on your OWASP Dependency-Check findings

Access and setup

Generate the JSON report (--format JSON) in your build, turn each vulnerable dependency into a finding, and send it with an organization API key. Konvu never connects to Dependency-Check.

To send findings

A Konvu API key, scoped to your organization
For each finding: the CVE ID, the package name and version, and the manifest file that declares it
Dependency-Check reports the file it scanned, often a JAR, so map it to the pom.xml or build file that pulls it in

To write back

No access to OWASP Dependency-Check is needed.

Sending the same findings again updates them instead of creating duplicates, so the full result set can go up after every scan. Findings you stop sending stay open until you send them again with state "fixed" or "dismissed".
Konvu assesses a dependency finding once its repository is connected through GitHub or GitLab. Until then it appears in triage without a verdict.

How Konvu investigates OWASP Dependency-Check findings

What Konvu receives

The CVE, the dependency and version, and the manifest file you mapped it to, plus the repository and branch.

What Konvu checks

Whether the flagged package is really the one on your runtime classpath or in your bundle, at that version.
Whether the vulnerable code is called, and whether input an attacker controls reaches it.
Whether configuration settings that block the exploit are present.

What decides the verdict

Konvu returns exploitable, false positive, or inconclusive, with the reasoning behind it: the code it read, the conditions it tested, and what settled the call. When the answer depends on something only your team knows, Konvu asks a question instead of guessing.

Illustrative example

A Log4j finding from Dependency-Check

A made-up service, written to show how an investigation reads. Not a customer result.

1
Scanner finding
Dependency-Check reports CVE-2021-44228, known as Log4Shell, against log4j-core 2.14.1 in a Java API's build. Log4j 2 before 2.15.0 can load and run remote code when it logs an attacker-controlled string containing a JNDI lookup.
2
Application context
The API logs the User-Agent header of every request through Log4j.
3
Investigation
Konvu confirms log4j-core 2.14.1 is on the runtime classpath and follows the User-Agent header from the request filter to a logger.info call. Message lookups are not disabled in the configuration or the JVM flags.
4
Verdict
Exploitable. Any client can send a User-Agent that triggers a JNDI lookup.
5
Evidence
The installed version, the path from request header to log call, and the Log4j configuration Konvu checked.
6
Where it ends up
The finding is marked exploitable in Konvu with its evidence. Konvu can propose the log4j-core upgrade as a pull request through your GitHub or GitLab connection.

Writeback and controls

Where results go

Exploitable dependency findings can become a fix pull request in GitHub or GitLab, opened automatically if you turn that on for the repository.
Exploitable findings can be posted to Slack, so the team hears about them without opening Konvu.
Every verdict and its evidence can be pulled into your own tools through the Konvu API or CLI.

Who triggers it

Your build decides when results reach Konvu.

What stays with your team

Suppression files in Dependency-Check, if you want a false positive to stop appearing in its own report.
Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".

OWASP Dependency-Check integration

Integration details

Which Dependency-Check CVEs actually apply?

OWASP Dependency-Check findings Konvu analyzes