HuskyCI Integration with DefectDojo

HuskyCI Integration with DefectDojo

HuskyCI is an open source tool from Globo.com (published under the globocom GitHub organization, BSD 3-Clause license) that runs security tests inside CI pipelines. Rather than scanning code itself, it orchestrates other open source scanners in containers and stores their results centrally: Bandit and Safety for Python, Gosec for Go, Brakeman for Ruby, npm audit and Yarn audit for JavaScript, SpotBugs with Find Sec Bugs for Java, TFSec for HCL, and Gitleaks for secrets. Each analysis produces a JSON document with the results grouped by language, tool, and severity, which DefectDojo can import.

HuskyCI Integration with DefectDojo

We adopted HuskyCI so that every repository got a baseline of language-appropriate checks without each team wiring up its own scanners. What HuskyCI doesn't do is follow a finding after the pipeline ends. Importing its JSON into DefectDojo turns each result into a Finding on the right Asset, with an owner, an SLA, and a history across runs. Because one HuskyCI report can contain output from several tools, a single import brings code, dependency, infrastructure-as-code, and secret findings into one Test.

Why HuskyCI Matters

HuskyCI is a pragmatic way to give many repositories a consistent security gate.

• One integration point covers several languages, each with a well-known scanner chosen for it.
• Tools run in containers managed by HuskyCI, so teams don't install or update scanners in every pipeline.
• Results are normalized into one JSON structure, with a common set of fields (title, details, file, line, code, confidence, tool) across tools.
• HuskyCI is aimed at blocking risky changes in CI. Tracking remediation over time, across repositories, and against SLAs is outside its scope.

Advantages of This Integration

What we gained by importing HuskyCI results into DefectDojo:

• One Test for many tools. Findings from Bandit, Safety, Gosec, Brakeman, and the rest arrive together, each labeled with the tool that produced it.
• Lifecycle across runs. Reimporting a newer HuskyCI result into the same Test mitigates findings that are gone, adds new ones, and reactivates regressions.
• Deduplication. DefectDojo compares title, CWE, line, file path, and description, so the same issue reported on the next run matches the existing Finding instead of creating a copy.
• SLAs and ownership. High, Medium, and Low results map directly to DefectDojo severities, so they inherit your SLA rules and can be assigned, commented on, or pushed to Jira.
• Context next to other scanners. HuskyCI findings sit on the same Asset as DAST, container, or pentest results, which gives a complete picture of the application.

How This Integration Works

DefectDojo imports HuskyCI output with the HuskyCI Report scan type.

1. Get the analysis JSON. HuskyCI stores each analysis as a JSON document identified by an RID, with repository URL, branch, container details, and a huskyciresults section. The parser reads only huskyciresults, which is organized as language, then tool output (for example pythonresults and banditoutput), then severity buckets such as highvulns, mediumvulns, and lowvulns. Save that document as a .json file.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select HuskyCI Report, and upload the file. To automate, use the API (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=HuskyCI Report" \
  -F "file=@huskyci-result.json" \
  -F "product_name=billing-service" \
  -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 "HuskyCI Report" \
  --report-path "./huskyci-result.json" \
  --product-name "billing-service" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on each run. For repositories scanned on every merge, send later results to /api/v2/reimport-scan/ against the same Test so fixes close automatically. Keep one Test per repository and branch stream. HuskyCI runs every applicable tool for the languages it detects, so a run that suddenly reports nothing from one tool may mean the tool failed rather than that everything was fixed. Check the analysis status before trusting a large drop in findings.

Data Granularity: What Gets Imported

Inside one report, entries that are exactly identical are imported once.

Use Cases

As a baseline gate for many repositories: A platform team adds HuskyCI to every pipeline and imports each result into DefectDojo under the repository's Asset. Security leads see which repositories carry open High findings without opening hundreds of CI logs.

For polyglot services: A service with Python and Terraform code produces Bandit, Safety, and TFSec results in one HuskyCI run. Importing that one file gives the team a single Test to triage, with the tool name in each description.

For secret exposure: Gitleaks results from HuskyCI become Findings with file and line, so a security engineer can assign the rotation to the owning team and track it to closure under a short SLA.

When migrating tooling: Teams moving from HuskyCI to running scanners directly can import both for a while. DefectDojo keeps the history of what HuskyCI found, so nothing is lost in the switch.

Operational Tips

• Know what gets dropped. Results in buckets other than high, medium, and low (for example Bandit's nosecvulns) are skipped, which is usually correct for suppressed items.
• There is no CWE or CVE field, so filtering by vulnerability ID won't find HuskyCI findings. Use tags or search on title and description instead.
• Tag imports with the branch or commit (for example tags=main) so you can tell which run a finding came from.
• Fill in Mitigation during triage for findings you push to Jira. The import sets it to "N/A", which gives developers nothing to work from.
• Reimport only full-branch analyses into the main Test. A partial run reimported there will mitigate findings that still exist in the code it skipped.
• If you later run one of these scanners directly (for example Bandit or Gosec), use its own DefectDojo parser. The direct parsers usually carry more fields, such as CWE and confidence mapping.