OWASP Dependency-Track integration
Send OWASP Dependency-Track findings to Konvu through the API or CLI for an exploitability verdict on each component vulnerability.
Integration details
Primary category
Software Composition Analysis
Sync direction
OWASP Dependency-Track → Konvu API
No native connector. A script sends Dependency-Track findings to the Konvu API on your schedule. Verdicts go out as fix pull requests, Slack alerts, and through the Konvu API.
Status
Available
Which Dependency-Track findings need action?
Dependency-Track keeps an inventory of the components in your SBOMs and flags every vulnerable one across your portfolio. Konvu has no native connector for Dependency-Track. A script or pipeline reads findings from the Dependency-Track API and sends them to the Konvu API, and Konvu checks each one against the code of the matching repository.
OWASP Dependency-Track findings Konvu analyzes
SCA
Dependency-Track project findings
Component vulnerabilities read from the Dependency-Track findings API for a project, sent through POST /sca_findings or konvu finding submit.
Not imported today
- Policy violations and license risk
Access and setup
Read findings with a Dependency-Track API key that can view the project's findings, then send them to Konvu with an organization API key. Konvu never connects to Dependency-Track.
To send findings
- A Konvu API key, scoped to your organization
- For each project: the repository URL and the branch it was built from
- For each finding: the CVE or GHSA ID, the component name and version, and the manifest file. Dependency-Track stores components from the SBOM, so the script supplies the manifest path.
To write back
No access to OWASP Dependency-Track 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-Track findings
What Konvu receives
The vulnerability, component, and version from Dependency-Track, plus the repository, branch, and manifest file your script adds.
What Konvu checks
- Whether the component is actually shipped by the application built from that repository.
- Whether the vulnerable function is reachable, and whether input an attacker controls gets to it.
- Whether your runtime and configuration match what the vulnerability needs.
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 protobufjs finding from Dependency-Track
A made-up service, written to show how an investigation reads. Not a customer result.
- 1
Scanner finding
Dependency-Track flags CVE-2023-36665 in protobufjs 7.2.3 for a Node.js project. protobufjs from 6.10.0 and before 7.2.5 is open to prototype pollution when it parses .proto definitions an attacker controls.
- 2
Application context
The service decodes messages with static code generated from .proto files at build time. It never loads .proto files at runtime.
- 3
Investigation
Konvu checks how protobufjs is used. The service imports only the generated static module and calls decode. There are no calls to protobuf.parse, load, or loadSync, and no code sets options from input.
- 4
Verdict
False positive. The parsing path the vulnerability needs never runs.
- 5
Evidence
The installed version, the generated module the service imports, and the search for runtime parsing calls.
- 6
Where it ends up
The finding is marked false positive in Konvu with its evidence. Konvu does not update the analysis in Dependency-Track, so the team records it there if they track decisions in both places.
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 script decides when findings reach Konvu.
What stays with your team
- Analysis decisions and suppressions in Dependency-Track.
- Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".
Evaluation questions
The technical detail
More integrations
View all
Arnica
Add exploitability verdicts with evidence to Arnica SCA and SAST findings, and send approved SCA dismissals back to Arnica.
- SCA
- SAST
- ASPM
Black Duck
Get an exploitability verdict with evidence for Black Duck Polaris SCA findings and Coverity SAST findings.
- SCA
- SAST
Checkmarx
Send Checkmarx One SCA and SAST results to Konvu for an exploitability verdict with evidence, through the Konvu API or a report upload.
- SAST
- SCA
Dependabot
Get an exploitability verdict for each Dependabot alert, and dismiss the false positives in GitHub with the evidence linked.
- SCA
Endor Labs
Add an exploitability verdict with evidence to Endor Labs SCA findings, on top of Endor's own reachability.
- SCA
GitHub
Prioritize GitHub CodeQL and Dependabot alerts by adding exploit context to each finding.
- SAST
- SCA
- Ticketing & Messaging