Sslyze Integration with DefectDojo

SSLyze Integration with DefectDojo

SSLyze is an open source TLS configuration scanner written in Python, created and maintained by Alban Diquet (nabla-c0d3/sslyze on GitHub). It connects to a server, enumerates the SSL and TLS versions and cipher suites it accepts, validates the certificate chain against several trust stores, and tests for known issues such as Heartbleed, OpenSSL CCS injection, and insecure renegotiation. Because it runs locally, it can test internal services that public scanners can't reach. Current releases write results as JSON with --json_out; SSLyze 2 also produced an XML report. DefectDojo imports both.

SSLyze Integration with DefectDojo

We picked SSLyze because it runs anywhere we can run Python, including inside private networks and CI jobs, and because its JSON is predictable enough to automate. Feeding SSLyze results into DefectDojo turns "this server still accepts TLS 1.0" into a Finding on the right Asset and endpoint, with an owner and an SLA. When we retire old protocols across a fleet, reimporting the next scan shows exactly which hosts are done and which still need work.

Why SSLyze Matters

TLS settings live in load balancers, ingress controllers, application servers, and appliances, and they drift independently.

• SSLyze tests what each server actually negotiates, protocol by protocol and cipher by cipher.
• It reaches internal and non-HTTP TLS services such as SMTP with STARTTLS, LDAP, and database listeners.
• It validates certificates against multiple trust stores and checks that the certificate matches the hostname.
• It is scriptable and fast, so the same check can run on every deploy instead of once a year.
• Its output describes one scan. Knowing whether TLS 1.0 was really retired everywhere requires history across scans.

Advantages of This Integration

What we gained by running SSLyze through DefectDojo:

• Findings per host and port. Every finding includes the scanned host and port as an endpoint and in the title, so the same weakness on ten servers becomes ten trackable items.
• Protocol retirement tracking. Reimporting into the same Test mitigates "TLS 1.0 not recommended" findings as hosts are reconfigured, and reactivates them if an old image comes back.
• Deduplication. JSON imports are deduplicated on title and description, so repeated scans of the same host don't stack duplicates.
• Shared workflow. TLS findings get assignment, notes, risk acceptance, and Jira push like any other DefectDojo finding.
• One view with other infrastructure scans. SSLyze findings sit next to network, SSH, and host vulnerability findings on the same Asset.

How This Integration Works

The parser supports two scan types. Use SSLyze Scan (JSON) for SSLyze 3 and later, and Sslyze Scan for XML reports from SSLyze 2. The parser picks the JSON or XML reader by file extension, so keep the .json or .xml suffix on the file you upload.

1. Produce a report. With a current SSLyze release, scan one or more targets and write JSON:

sslyze --json_out=sslyze-results.json api.example.com:443 mail.example.com:465

One JSON file can hold several servers; each entry under server_scan_results is parsed separately.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select SSLyze Scan (JSON), and upload the file. To automate it, 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=SSLyze Scan (JSON)" \
  -F "file=@sslyze-results.json" \
  -F "product_name=edge-services" \
  -F "engagement_name=TLS Baseline" \
  -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 "SSLyze Scan (JSON)" \
  --report-path "./sslyze-results.json" \
  --product-name "edge-services" \
  --engagement-name "TLS Baseline" \
  --auto-create-context

3. Reimport after changes. Scan the same host list again after a TLS policy change and send the report to /api/v2/reimport-scan/ for the same Test.

Data Granularity: What Gets Imported

JSON reports (SSLyze Scan (JSON))

XML reports (Sslyze Scan)

Neither format sets CWE or Mitigation, and certificate expiry is not checked separately from trust validation.

Use Cases

Retiring TLS 1.0 and 1.1: A platform team scans every internal TLS listener weekly and reimports. The count of "not recommended" protocol findings becomes the progress measure, and each remaining host has an owner.

Pre-production gates: A deploy job runs SSLyze against the staging endpoint and imports the result. A release check can query the DefectDojo API for open findings on that endpoint before promotion.

Certificate hygiene: Findings for hostname mismatches and chain validation errors surface misconfigured internal certificates, which tend to go unnoticed until a client library becomes stricter.

Compliance baselines: Teams aligning with BSI or similar guidance use the cipher suite findings as a checklist, risk-accepting suites they must keep for specific clients.

Operational Tips

• Set severity during triage, or adjust it with your own rules. The parser assigns Medium to every JSON finding and Info to every XML finding, regardless of whether it is Heartbleed or a cipher preference.
• Remember that the TLS 1.2 cipher check uses the parser's built-in BSI 2020 list. If your policy differs, expect findings for suites you consider acceptable and risk-accept them with a note.
• Keep host lists stable across runs. A target that disappears from the scan is mitigated on reimport.
• Move to JSON if you still use SSLyze 2 XML. The JSON reader flags deprecated protocols outright and checks certificates, which the XML reader does not.
• Use one Test per environment (for example test_title=prod-edge) so staging and production TLS posture don't mix.
• Tag findings with the service type (for example tags=smtp,starttls) to separate web and non-web listeners in reports.