ssh-audit Integration with DefectDojo

ssh-audit Integration with DefectDojo

ssh-audit is an open source command-line tool for auditing SSH server and client configuration, maintained by Joe Testa (jtesta/ssh-audit on GitHub) as a fork of the original arthepsy project. It connects to an SSH service, reads its banner and the algorithms it negotiates, and flags key exchange methods, host key types, ciphers, and MACs that are considered weak, along with known CVEs for the detected server software. It also supports policy tests against hardened baselines. Results can be printed for humans or written as JSON with the -j flag, and that JSON is what DefectDojo imports.

ssh-audit Integration with DefectDojo

We run ssh-audit against our bastions and server fleet because SSH configuration drifts quietly: an old image comes back into rotation, someone copies a sshd_config from a wiki, and a deprecated key exchange is suddenly enabled again. Importing ssh-audit results into DefectDojo turns each weak algorithm and each server CVE into a Finding tied to the host and port it came from. Repeat scans update the same Test, so we can see when a hardening change actually took effect and which hosts still need it.

Why ssh-audit Matters

SSH is the administrative front door to most infrastructure, and its weaknesses rarely show up in application scanners.

• It checks what the server really offers during negotiation, not what the config file is supposed to say.
• It flags algorithms with known cryptographic problems, such as SHA-1 based key exchange or small RSA moduli, with a short explanation for each.
• It matches the server banner against known CVEs, which catches unpatched OpenSSH and Dropbear versions.
• It is fast and agentless, so it can sweep many hosts from a single runner.
• Its output is per host and per run. Without somewhere to store it, nobody can say which servers were fixed last quarter.

Advantages of This Integration

What we gained by sending ssh-audit results through DefectDojo:

• Per-host findings. Each finding carries the scanned host and port as an endpoint, so a weak MAC on twenty servers shows up as work on twenty endpoints instead of a line in a log.
• Lifecycle through reimport. Reimporting a new scan into the same Test mitigates algorithms that were disabled, adds anything newly exposed, and reactivates findings that returned after a rebuild.
• Severity that fits our SLAs. ssh-audit's fail and warn notes become High and Medium findings, and CVEs are scored from CVSS, so SSH hardening work runs on the same SLA clock as other infrastructure findings.
• Context next to other scans. SSH findings sit on the same Asset as TLS, network, and host vulnerability results for the same systems.
• Exceptions with an expiry. When a legacy client forces us to keep an older algorithm for a while, we risk-accept that finding with an end date instead of deleting it.

How This Integration Works

DefectDojo imports ssh-audit output with the SSH Audit Importer scan type.

1. Produce a JSON report. Run ssh-audit against a host with JSON output enabled and redirect it to a file:

ssh-audit -j bastion01.example.com > ssh-audit-bastion01.json

The parser reads the target field as host:port, the banner, and the cves, kex, key, and mac arrays. Each report covers one target, so scan hosts one at a time and import each file.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select SSH Audit Importer, and upload the JSON file. For automation, use the 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=SSH Audit Importer" \
  -F "file=@ssh-audit-bastion01.json" \
  -F "product_name=core-infrastructure" \
  -F "engagement_name=SSH Hardening" \
  -F "test_title=bastion01" \
  -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 "SSH Audit Importer" \
  --report-path "./ssh-audit-bastion01.json" \
  --product-name "core-infrastructure" \
  --engagement-name "SSH Hardening" \
  --auto-create-context

3. Reimport after changes. When you change sshd configuration or patch a server, scan it again and send the report to /api/v2/reimport-scan/ against that host's Test so the fixed items are closed.

Data Granularity: What Gets Imported

The parser does not set Mitigation, References, or CWE. It also does not read the enc (cipher) section, compression, fingerprints, or recommendations, so weak ciphers flagged by ssh-audit won't appear as findings.

Use Cases

Fleet hardening campaigns: A platform team rolls out a hardened sshd baseline. A scheduled job scans every host, reimports each report into that host's Test, and the team watches High findings close as the baseline lands. Hosts that still offer the old algorithms stand out by endpoint.

After base image updates: When a new golden image ships, scanning a fresh instance before rollout confirms the image doesn't reintroduce weak key exchange or host key algorithms, and the result is kept with the Asset for later review.

Patch verification: CVE findings are tied to the server banner. After an OpenSSH upgrade, the next import shows the old CVE findings as mitigated, which is evidence that the patch reached the host.

Audit preparation: Assessors often ask how SSH cryptography is controlled. DefectDojo shows each SSH finding's discovery date, owner, risk acceptance, and closure date per host.

Operational Tips

• Give each host its own Test (use test_title with the hostname) and reimport into it. One report covers one target, so this keeps history clean.
• Expect titles to change when the server banner changes. Because the banner is part of the title, upgrading OpenSSH mitigates the old findings and opens new ones for anything still weak under the new version.
• Check weak ciphers separately. The parser skips the enc section, so pair ssh-audit with your own review or another scanner if cipher coverage matters to you.
• Review the High count before setting tight SLAs. Every fail note becomes High, including some that are configuration preferences rather than exploitable issues, so tune with risk acceptance or minimum_severity.
• Tag imports with environment and role (for example tags=prod,bastion) so reporting can separate internet-facing hosts from internal ones.
• Use risk acceptance with an expiration date for algorithms you must keep for older clients, so they come back for review.