ESLint Integration with DefectDojo

ESLint Integration with DefectDojo

ESLint is an open source, pluggable linter for JavaScript and TypeScript, created by Nicholas C. Zakas and now a project of the OpenJS Foundation. It parses source code and applies configurable rules, each set to report as a warning or an error. Out of the box most rules target correctness and style, and security teams extend it with plugins such as eslint-plugin-security or eslint-plugin-no-unsanitized that flag risky patterns like dynamic code evaluation, non-literal file paths, unsafe regular expressions, and unsanitized DOM writes. ESLint can write results in several formats, including JSON, which DefectDojo imports.

ESLint Integration with DefectDojo

Our front-end and Node.js teams already run ESLint on every commit, so adding security rules to it was the fastest way to get secure coding checks into their workflow. The catch is that lint output scrolls past in a terminal and gets fixed or ignored on the spot. Importing ESLint JSON into DefectDojo keeps a record of the security-relevant results per Asset, so we can see which rules keep firing, assign the ones that matter, and report on them next to our other SAST and SCA findings.

Why ESLint Matters

ESLint is already part of most JavaScript projects, which makes it a low-friction place to enforce secure coding rules.

• Security plugins catch dangerous APIs and patterns at the line where they are written, before code review.
• Rules are configured in the repository, so teams can tune them and review the configuration like code.
• It understands modern JavaScript and, with the TypeScript parser, TypeScript, so it fits most front-end and Node.js code bases.
• Lint results are transient by design. Nobody outside the pull request sees them unless they are collected somewhere.

Advantages of This Integration

What we gained by importing ESLint results into DefectDojo:

• Lint results with a lifecycle. Each ESLint message becomes a Finding that can be assigned, commented on, risk-accepted, or marked false positive, and reimporting the next run mitigates messages that are gone.
• Severity follows your rule configuration. Rules set to error import as High, rules set to warn import as Medium, so the severity your team chose in ESLint carries over to SLA rules.
• File and line on every finding. Findings carry the file path and line number from the report, which lets engineers jump straight to the code.
• One view per application. ESLint findings sit on the same Asset as dependency, container, and DAST findings for the same service.
• Trend reporting. DefectDojo metrics show whether security rule violations are going down over time, which is hard to see from per-commit lint output.

How This Integration Works

DefectDojo imports ESLint results with the ESLint Scan scan type, which reads the output of ESLint's built-in JSON formatter.

1. Run ESLint with JSON output. From the project root, with your security plugins configured:

npx eslint . -f json -o eslint-report.json

Run it from the same directory layout every time. ESLint writes absolute file paths into the JSON, and file path is part of how DefectDojo matches findings between runs.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select ESLint Scan, and upload the file. To automate, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=ESLint Scan" \
  -F "file=@eslint-report.json" \
  -F "product_name=web-frontend" \
  -F "engagement_name=CI" \
  -F "minimum_severity=Medium" \
  -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 "ESLint Scan" \
  --report-path "./eslint-report.json" \
  --product-name "web-frontend" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on each build. Send later reports to /api/v2/reimport-scan/ against the same Test so fixed violations are closed.

Consider a separate ESLint configuration for the security import that enables only security rules. A full style rule set can produce thousands of messages that are not security findings.

Data Granularity: What Gets Imported

ESLint doesn't report CWE or remediation text, so those fields stay empty or "N/A". The rule ID in the title points to the rule's documentation for fix guidance.

Use Cases

In a CI/CD pipeline: Each merge to the main branch runs ESLint with the security configuration and reimports into a Test for the repository. New High findings (rules set to error) get an owner and an SLA, and the finding date shows which build introduced them.

Rolling out security rules gradually: A team turns on eslint-plugin-security rules as warnings first. They import with minimum_severity=Medium, triage the results in DefectDojo, mark false positives, and then promote the rules that proved useful to errors.

Comparing with a deeper SAST tool: Teams that also run a data-flow SAST tool on the same code can see both tools' findings on one Asset and judge which rules ESLint catches early and which need the heavier tool.

Measuring progress on legacy code: For an older code base with many violations, DefectDojo metrics show the count of open ESLint security findings dropping release by release.

Operational Tips

• Keep file paths stable. ESLint writes absolute paths, so CI runners that check out code into different directories produce different paths and new findings on every import. Check out to a fixed path, or rewrite paths in the JSON to be relative before import.
• The parser builds each finding's description by accumulating file and line entries across all messages in the same file, so a new message early in a file can change the descriptions of later ones. If reimport shows unexpected new findings in a busy file, this is the likely cause.
• Parse errors arrive as High findings titled with the parser's message and no rule ID. Fix the parser configuration rather than triaging them as vulnerabilities.
• Use minimum_severity=Medium to drop Info entries, and keep style-only rules out of the security run altogether.
• Tag imports with the repository and branch (for example tags=web-frontend,main) to filter findings in reports.
• Mark rule-level false positives in DefectDojo and, where the pattern is safe by design, add an inline ESLint disable comment with a reason so the finding stops appearing at the source.