sqlmap Integration with DefectDojo

sqlmap Integration with DefectDojo

sqlmap is an open source penetration testing tool, maintained by the sqlmapproject team on GitHub, that detects SQL injection in web application parameters and confirms it by exploiting the injection against the running application. It supports a wide range of database back ends and several injection techniques, including boolean-based blind, error-based, time-based blind, stacked queries, inline query, and UNION query. For each target sqlmap writes a log file in its output directory, and when testing multiple targets it also writes a CSV results file. DefectDojo imports either artifact.

sqlmap Integration with DefectDojo

Our testers use sqlmap to confirm suspected injection points that a DAST scan or a code review flagged, because a confirmed injection ends the debate about whether a finding is real. The output used to live in each tester's output directory, which meant nobody outside the engagement knew it existed. Importing sqlmap results into DefectDojo puts every confirmed injection point on the Asset that owns the application, as a High Finding with CWE-89, the affected parameter, and the techniques that worked. Developers get a clear fix, and the next sqlmap run shows whether it held.

Why sqlmap Matters

SQL injection is still one of the most damaging web application flaws because it can expose or alter the data behind the application. Many scanners report it with uncertainty. sqlmap removes the uncertainty.

• sqlmap only reports an injection point after confirming the injection works, so results are not pattern matches that may be wrong.
• It identifies which parameter is injectable and where it was found (for example, a GET or POST parameter), which is exactly what a developer needs.
• It records which techniques succeeded, which helps judge exposure and verify the fix.
• It is widely used in authorized penetration tests and red team engagements, so its output often arrives from external testers.
• A confirmed injection needs urgent, tracked remediation, not a line in a test report.

Advantages of This Integration

What we gained by sending sqlmap results through DefectDojo:

• One Finding per injectable parameter. The parser creates a Finding for each parameter, not each technique, and lists every confirmed technique in the description.
• High severity and CWE-89 by default. Every Finding is High with CWE-89 (SQL Injection), so it falls under the High SLA and appears in CWE-based reporting.
• Endpoints from the CSV. When you import the CSV results file, the target URL becomes the Finding's endpoint, which ties the injection to a specific location on the Asset.
• Evidence from the log. When you import the per-target log, the description records the title of each confirmed technique and the payload sqlmap used, which is the evidence a triager needs.
• Retest lifecycle. Reimporting a later run into the same Test mitigates injection points that no longer reproduce and reactivates any that return.
• No double counting. sqlmap appends to its files when a target is scanned again. The parser keys Findings on place and parameter (and URL for CSV), so resumed sessions do not duplicate them.

How This Integration Works

DefectDojo imports sqlmap output with the Sqlmap Scan scan type. The parser detects whether it received a CSV results file or a log.

1. Run sqlmap against an application you are authorized to test. Use --batch for non-interactive runs and --output-dir to control where results are written. For a single target, sqlmap writes the log to <output-dir>/<host>/log. Testing a list of targets (multiple targets mode) also writes <output-dir>/results-<timestamp>.csv:

sqlmap -m targets.txt --batch --output-dir=out

The two artifacts carry different information:

• The per-target log is the only place the confirmed payloads appear, but it does not contain the target URL, so Findings imported from a log have no endpoint.
• The CSV results file carries the target URL, so Findings get an endpoint, but it records only which techniques worked, not the payloads.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select Sqlmap Scan, and upload either file. For automation, 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=Sqlmap Scan" 
  -F "file=@out/results.csv" 
  -F "product_name=storefront" 
  -F "engagement_name=Q4 Pentest" 
  -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 "Sqlmap Scan" 
  --report-path "./out/results.csv" 
  --product-name "storefront" 
  --engagement-name "Q4 Pentest" 
  --auto-create-context

3. Reimport after a fix. When developers ship a fix, rerun sqlmap and send the result to /api/v2/reimport-scan/ against the same Test. Injection points that no longer reproduce are mitigated.

A run that finds nothing writes an empty log and a header-only CSV. Both import cleanly as zero Findings.

Data Granularity: What Gets Imported

The description is deliberately left out of the hash, because response sizes, detected versions, and payloads change between two runs against an unchanged target.

Use Cases

During a penetration test: Testers confirm injection points with sqlmap and import the results into the engagement for that application. Each confirmed parameter becomes a High Finding with an owner, so remediation starts before the final report is written.

For verifying DAST results: A DAST scanner reports a possible SQL injection. A tester runs sqlmap against the same parameter, imports the result into the same Asset, and the confirmed Finding is escalated while the scanner's Finding is closed with a note pointing to it.

For retesting fixes: After a fix ships, the tester reruns sqlmap and reimports. The Finding is mitigated if the injection no longer works, which gives a dated record that the fix was verified.

For audit and compliance evidence: Confirmed injections, their remediation dates, and the retest that closed them are all kept on the Asset, which answers the questions auditors ask about high-risk web findings.

Operational Tips

• Prefer the CSV results file when you can. Without an endpoint, the hash is effectively the title alone, so two different applications with an injectable GET parameter of the same name in one Asset would deduplicate against each other.
• If you import logs, keep each application in its own Asset, or use deduplication_on_engagement=true with one Engagement per target, so log-based Findings for different targets stay separate.
• Import the log alongside the CSV, into a separate Test, when testers need the payload evidence that the CSV does not carry.
• Every Finding imports as High. Raise it to Critical during triage when the affected data or privileges justify it, since that is a judgment about the application, not something sqlmap measures.
• In the CSV, technique letters are the first letter of each technique name, so an inline query appears as I even though the --technique flag spells it Q. The parser expands the letters for you.
• Clear or rotate the output directory between engagements. sqlmap appends to its files, and while the parser avoids duplicates, a fresh directory keeps each import tied to one test.
• Run sqlmap only against systems you have written permission to test, and record that scope in the Engagement description.