Scantist Integration with DefectDojo
Scantist Integration with DefectDojo
Scantist is a software composition analysis (SCA) platform from Scantist, a Singapore company founded in 2016 as a spin-off of the Cyber Security Lab at Nanyang Technological University. It identifies the open source components in an application, including from source code and binaries, and reports the security vulnerabilities, license issues, and policy violations tied to them. DefectDojo imports the vulnerability portion of a Scantist report in JSON format.
Scantist Integration with DefectDojo
We use Scantist to answer one question for every application: which third-party libraries are we shipping that have known vulnerabilities? DefectDojo is where those answers turn into tracked work. Each Scantist entry becomes a Finding on the right Asset, carrying the CVE, the library and version, the manifest it came from, and the version that fixes it. When a team upgrades a dependency and we reimport, the Finding closes on its own, and our SCA results get the same owners and SLAs as everything else in the program. On DefectDojo Pro, the Scantist connector removes the export step by pulling each project's latest results straight from the Scantist API.
Why Scantist Matters
A large share of the code in a typical application comes from open source libraries, and many of its known vulnerabilities live in those dependencies rather than in code the team wrote.
- Scantist maps libraries to public vulnerability IDs, so every result is tied to a CVE or similar identifier that can be looked up and tracked.
- Each result names the library, its installed version, and the patched version, which is what a developer needs to plan an upgrade.
- File paths point to the build file that pulled the library in, such as a Gradle or Maven manifest.
- On its own, a Scantist export is a list for one scan. It doesn't show whether a CVE is new this sprint or has been open since last year.
Advantages of This Integration
What we gained by sending Scantist results through DefectDojo:
- Clean imports. The parser keys each entry on its public ID and library name and keeps one Finding per pair, so a library listed twice in the same export doesn't produce duplicates.
- Reimport lifecycle. Reimporting the next scan into the same Test mitigates CVEs that disappeared after an upgrade, adds new ones, and reactivates any that return.
- CVE-level reporting. Public IDs are stored as vulnerability IDs, so you can search for a CVE across every Asset and see which applications carry it.
- SLAs on dependency risk. Scantist's severity label is carried into DefectDojo, so vulnerable libraries fall under the same SLA rules as findings from other scanners.
- SCA and SAST without exports on DefectDojo Pro. The Scantist connector imports both SCA and SAST findings, creates a Record for each Scantist project, and reads the most recent completed scan, so new projects appear without anyone setting up an import job.
- Ownership and ticketing. Findings can be assigned to the team that owns the manifest, risk-accepted with an expiration date, or pushed to Jira.
How This Integration Works
DefectDojo imports Scantist results with the Scantist Scan scan type. The parser expects a JSON array of vulnerability entries, the format Scantist produces for its vulnerability (security issues) report. Component and compliance reports are not parsed.
1. Export the vulnerability report as JSON from Scantist for the project or scan you want to track.
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Scantist Scan, and upload the file. To automate it, use the API in Community Edition or DefectDojo Pro:
curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
-H "Authorization: Token $DD_API_TOKEN" \
-F "scan_type=Scantist Scan" \
-F "file=@scantist-vulns.json" \
-F "product_name=billing-service" \
-F "engagement_name=Dependency Scans" \
-F "auto_create_context=true"
DefectDojo Pro users can run the same import with Universal Importer:
universal-importer import \
--defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
--scan-type "Scantist Scan" \
--report-path "./scantist-vulns.json" \
--product-name "billing-service" \
--engagement-name "Dependency Scans" \
--auto-create-context
3. Reimport on each build or release. Send later reports to /api/v2/reimport-scan/ for the same Test so upgraded libraries are closed and the history stays in one place.
Option: Scantist connector (DefectDojo Pro). Generate a Scantist API token in the Scantist UI under your account settings. Then add a Scantist connector in DefectDojo Pro and set:
- Location:
https://api.scantist.io - API Token: the token you generated.
- Minimum Severity (optional): limits which findings are imported.
Each Scantist project on the account becomes a Record, and its findings come from that project's most recent completed scan. Unlike the JSON file import, the connector also brings in Scantist SAST findings.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in Scantist JSON | Notes |
|---|---|---|
| Title | Public ID, Library |
Public ID and library name joined by a pipe character |
| Severity | Score |
Scantist's label (for example Medium) used as is; Info when missing |
| Description | Description |
The vulnerability description |
| Mitigation | Patched Version |
The version that fixes the issue, with no extra text |
| Vulnerability IDs | Public ID |
Enables CVE search and filtering |
| Component Name / Version | Library, Library Version |
The affected open source library |
| File Path | File Path |
Build or manifest file, for example build.gradle |
| References | references |
Set only when the entry includes it |
| Severity Justification | severity_justification |
Set only when the entry includes it |
| CWE | Fixed at 1035 | Vulnerable Third Party Component, for every entry |
| Finding type | Dynamic | The parser marks Scantist findings as dynamic |
| Deduplication | Legacy algorithm | No Scantist-specific setting; docs list title, CWE, line, file path, description |
Within one report, entries with the same public ID and library are merged into a single Finding. The table describes the Scantist Scan file parser; the DefectDojo Pro connector imports SCA and SAST findings per project from the latest completed scan.
Use Cases
In a CI/CD pipeline: Each build of a service runs a Scantist scan and reimports the JSON into a Test named for the repository. Developers see only the delta, and a release gate can query the DefectDojo API for new High or Critical findings.
When a major CVE lands: A security lead searches DefectDojo for the CVE ID and gets every Asset whose Scantist results include it, along with the owning team, instead of asking each team to rerun scans.
For upgrade planning: Because the patched version sits in the Mitigation field, platform teams can export open Scantist findings for an Asset and plan dependency upgrades in one sprint rather than one CVE at a time.
Alongside SAST and DAST: Dependency findings sit next to code and runtime findings for the same Asset, so reporting reflects the whole application.
Operational Tips
- Check the
Scorevalues in your export. The parser passes the label straight into the Severity field, so only values that match DefectDojo's severity names (Critical, High, Medium, Low, Info) will line up with your SLA rules. - The Finding type is set to dynamic even though the data comes from dependency analysis. Keep that in mind if you filter metrics by static or dynamic findings.
- Because every Finding gets CWE 1035, CWE-based reporting won't separate Scantist results by weakness class. Use vulnerability IDs and component names instead.
- If you use the connector, make sure scans complete in Scantist. The connector reads only the most recent completed scan, so a failed or still-running scan leaves the previous results in place.
- Pick either the connector or file imports for a given project, not both, so the same CVEs aren't tracked on two Records.
- Use one Test per repository or build artifact and reimport into it, so upgrades are recorded as mitigations rather than as a new Test with fewer findings.
- Tag imports with the branch or release (for example
tags=main,2.4.0) to compare dependency risk between releases. - Look for an empty Mitigation field. It means the entry had no patched version, which usually calls for a workaround or a risk decision instead of an upgrade ticket.
- Risk-accept CVEs that have no patched version yet, with an expiration date, so they come back for review when a fix is likely.