DawnScanner Integration with DefectDojo
DawnScanner Integration with DefectDojo
Dawnscanner (the dawn command) is an open source security scanner for Ruby web applications, written by Paolo Perego and released under the MIT license. It supports Ruby on Rails, Sinatra, and Padrino applications, detecting the framework from Gemfile.lock, and runs a knowledge base of checks that are mostly CVE bulletins for gems and the Ruby interpreter, with additional checks drawn from the OWASP Ruby on Rails cheat sheet and other code patterns. Version 1.6.x can write results as JSON with the -j option, which is the format DefectDojo imports.
DawnScanner Integration with DefectDojo
We run Dawnscanner against our Ruby services because it checks both the framework version and the gems we ship against known vulnerabilities, and DefectDojo is where those results get owners. Each issue from a Dawnscanner JSON report becomes a Finding on the right Asset, with Dawnscanner's remediation advice as the mitigation and a CVE ID when the check is a bulletin. That puts Ruby-specific results next to our other SAST and SCA findings, measured against the same SLAs.
Why DawnScanner Matters
Rails applications inherit risk from the framework version and a long tail of gems, and outdated dependencies are a common source of serious vulnerabilities in Ruby stacks.
- Most of its checks map to published CVEs for gems or the Ruby interpreter, so findings come with a clear upgrade path.
- It understands three Ruby web frameworks rather than treating the app as generic Ruby code.
- Each finding includes a severity, a message, and usually a remediation such as the gem versions that fix the issue.
- It runs locally against a source directory, so it fits in a CI job without sending code anywhere.
- A Dawnscanner run is a snapshot of one checkout. Without a tracking platform, the same CVE shows up in every run with no indication of whether anyone is working on it.
Advantages of This Integration
What we gained by importing Dawnscanner results into DefectDojo:
- Remediation in the finding. Dawnscanner's
remediationtext becomes the Finding's mitigation, and DefectDojo marks a fix as available whenever that text is present. - CVE IDs for search and reporting. When a check name is a CVE ID, it is stored as the finding's vulnerability ID, so the CVE can be found across every Asset.
- A lifecycle per application. Reimporting each run into the same Test mitigates issues that disappeared after an upgrade and adds new ones.
- Shared SLAs. Dawnscanner severities map onto DefectDojo's scale, so Ruby findings are measured with the same rules as other scanners.
- Ticketing and ownership. Findings can be assigned, commented on, risk-accepted, or pushed to Jira from DefectDojo.
How This Integration Works
DefectDojo imports Dawnscanner output with the DawnScanner Scan scan type.
1. Run Dawnscanner with JSON output. From the application's parent directory, write JSON to a file:
dawn -j -F dawnscanner.json ./storefront
The parser expects the JSON structure produced by Dawnscanner 1.6.x, with a scan_started timestamp and a vulnerabilities array whose entries have name, severity, message, and optionally remediation and cve_link. Newer Dawnscanner releases describe different output options, so confirm your version produces this layout before wiring it into a pipeline.
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select DawnScanner Scan, and upload the file. To automate it, use the import API, available in Community Edition and DefectDojo Pro:
curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
-H "Authorization: Token $DD_API_TOKEN" \
-F "scan_type=DawnScanner Scan" \
-F "file=@dawnscanner.json" \
-F "product_name=storefront" \
-F "engagement_name=Ruby SAST" \
-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 "DawnScanner Scan" \
--report-path "./dawnscanner.json" \
--product-name "storefront" \
--engagement-name "Ruby SAST" \
--auto-create-context
3. Reimport on each run. Send later reports to /api/v2/reimport-scan/ for the same Test so upgraded gems close their findings.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in Dawnscanner JSON | Notes |
|---|---|---|
| Title | name |
Usually the CVE ID or the check name |
| Severity | severity |
Capitalized, so medium becomes Medium |
| Description | message |
The check's explanation of the issue |
| Mitigation | remediation |
Typically the gem versions that fix the issue |
| Fix Available | remediation |
True when remediation text is present, otherwise false |
| References | cve_link |
Link to the CVE entry |
| Vulnerability IDs | name |
Set when the name starts with a CVE ID |
| Date | scan_started |
Same date for every finding in the report |
| Finding type | Static | All findings are static |
| Deduplication | Legacy algorithm | No per-scanner entry; default hashcode fields are title, CWE, line, file path, description |
The parser does not set file path, line, component, or CWE. Report-level details such as target, mvc, and mvc_version are not imported.
Use Cases
In a Ruby CI job: Each merge to main runs Dawnscanner on the application and reimports the JSON into a Test per repository. A gem bump that fixes a CVE shows up as a mitigated finding on the next run.
Planning a Rails upgrade: Framework CVEs often cluster around older Rails versions. Seeing them in DefectDojo, with severity and remediation, helps a team justify and scope an upgrade.
Across a Ruby portfolio: Organizations with many small Sinatra or Rails services import each into its own Asset. A search on a CVE ID shows every service affected by the same gem bulletin.
Alongside general SCA: Teams that also run a dependency scanner can compare its results with Dawnscanner's bulletins on the same Asset and decide which tool to rely on for gem coverage.
Operational Tips
- Reimport into a stable Test per application. Dawnscanner findings carry no file path, line, or endpoint, and DefectDojo's documentation notes that legacy deduplication typically does not occur without them, so cross-Test duplicates are likely if you create a new Test each run.
- Add the gem or framework name as a tag during triage if you want component-level filtering, since the parser doesn't set component fields.
- Check that the target framework was detected. Dawnscanner relies on
Gemfile.lockfor detection, and when detection fails you have to name the framework yourself. - Set
minimum_severityon import if informational checks add noise to the security queue. - Risk-accept CVEs that don't apply to your usage with an expiration date, so they are reviewed again when you next upgrade.
- Confirm the JSON layout after upgrading Dawnscanner, since the parser targets the 1.6.x structure.