All integrations

Rubocop Integration with DefectDojo

RuboCop Integration with DefectDojo

RuboCop is an open source static code analyzer, linter, and formatter for Ruby, created by Bozhidar Batsov and maintained by the RuboCop community on GitHub. It checks code against rules called cops, grouped into departments such as Layout, Style, Lint, and Security, and many offenses can be corrected automatically. RuboCop prints results in several formats, and its JSON formatter (--format json) produces the report DefectDojo imports.

RuboCop Integration with DefectDojo

We bring RuboCop into DefectDojo for one narrow reason: its Security department flags risky Ruby calls that deserve the same tracking as any other static analysis finding. Most RuboCop output is style, and nobody wants line-length complaints in a vulnerability backlog. The DefectDojo parser handles that for us. It imports only offenses from cops whose names begin with Security, so what lands on the Asset is the short list of unsafe deserialization, unsafe file opening, and similar issues, each tied to a file and line with an owner and an SLA.

Why RuboCop Matters

RuboCop is already in the toolchain of most Ruby and Rails teams, which makes its security cops a cheap first layer of static analysis.

  • The Security cops target well-known Ruby hazards, such as loading YAML, JSON, or Marshal data in unsafe ways and passing untrusted input to Kernel#open.
  • Running on every commit, it catches those patterns at the moment they are introduced, while the author still has context.
  • Offenses report the exact file and line, and RuboCop marks whether each one can be corrected automatically. For several Security cops, the safe alternative is a one-line change, which makes these some of the quickest static findings to close.
  • Lint output by itself scrolls past in a CI log. Security offenses that aren't tracked tend to be suppressed or ignored rather than fixed.

Advantages of This Integration

What we gained by sending RuboCop results through DefectDojo:

  • Security-only signal. Style, layout, and lint offenses are filtered out by the parser, so only Security department cops become Findings.
  • Stable deduplication. DefectDojo hashes RuboCop Findings on the cop name, file path, and line, so rerunning on unchanged code doesn't create duplicates.
  • Lifecycle on reimport. Reimporting into the same Test mitigates offenses that were fixed, adds new ones, and reactivates any that come back.
  • Ruby next to everything else. RuboCop Findings sit on the same Asset as Brakeman, bundler-audit, and DAST results, so a Rails application's security picture is in one place.
  • Ownership and ticketing. Findings can be assigned to the team that owns the file, pushed to Jira, or risk-accepted with an expiry when a call is known to be safe.

How This Integration Works

DefectDojo imports RuboCop results with the Rubocop Scan scan type, from RuboCop's JSON output.

1. Run RuboCop with the JSON formatter. To limit the run to the Security department:

rubocop --only Security --format json --out rubocop-report.json

Running the full rule set also works, because the parser drops any offense whose cop name doesn't start with Security.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Rubocop Scan, and upload the 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=Rubocop Scan" \
  -F "file=@rubocop-report.json" \
  -F "product_name=billing-rails" \
  -F "engagement_name=CI" \
  -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 "Rubocop Scan" \
  --report-path "./rubocop-report.json" \
  --product-name "billing-rails" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport per branch or per build into the same Test so fixed offenses close automatically.

Data Granularity: What Gets Imported

DefectDojo Field Source in RuboCop Report Notes
Title message The offense message RuboCop prints
Severity severity info to Info; refactor, convention, warning to Medium; error to High; fatal to Critical
Description message, correctable, location Message, whether RuboCop can autocorrect it, and location details
File Path files[].path Path relative to where RuboCop ran
Line location.start_line First line of the offense
Vuln ID from Tool cop_name For example Security/YAMLLoad
Finding type Static All RuboCop Findings are static
Filtering cop_name prefix Only cops starting with Security are imported
Deduplication Hashcode Vuln ID from tool, file path, line

Use Cases

On every pull request: CI runs the Security cops and reimports into a Test for the main branch. Reviewers see whether a change introduced a new Security offense, and the Finding links straight to the file and line.

Alongside Brakeman in Rails applications: Brakeman covers Rails-specific flaws, while RuboCop's Security cops catch general Ruby hazards in libraries, scripts, and background jobs that Brakeman may not analyze. Importing both into one Asset gives AppSec a fuller static view of the codebase.

Across many Ruby services: A team maintaining 20 Ruby services imports each into its own Asset. Filtering by vuln ID from tool shows which services still call, for example, unsafe YAML loading, which helps plan a fleet-wide fix.

Cleaning up legacy code: An older Ruby codebase gets its first RuboCop run. Importing the Security offenses produces a finite backlog with owners, instead of a style report so long nobody reads it.

Operational Tips

  • Expect most Security offenses to arrive as Medium. Unless your configuration sets a Severity for a cop, offenses are typically reported as convention or warning, and the parser maps both to Medium. Set Severity: error in .rubocop.yml for the Security cops your policy treats as High, and they will import as High.
  • If you want a hard gate, combine RuboCop's own exit code in CI with DefectDojo tracking. The pipeline stops the merge, and DefectDojo keeps the record of what was found, who fixed it, and when.
  • Keep the RuboCop version and .rubocop.yml consistent between runs. Disabled cops or new cop versions change what is reported, and a sudden drop in Findings may be a configuration change rather than a fix.
  • Because line is part of the hash, edits above an offense can shift its line number and create a new Finding while mitigating the old one. Reimport into one Test so the history stays readable.
  • Run RuboCop from the repository root every time. File paths are relative to the working directory, and a different starting point changes the hash.
  • Don't rely on inline rubocop:disable comments to hide security offenses. If a call is safe, risk-accept or mark the Finding as a false positive in DefectDojo so the decision is recorded.
  • Tag imports with the repository and branch so Findings from feature branches can be separated from the main line.