Sslscan Integration with DefectDojo

Sslscan Integration with DefectDojo

sslscan is an open source command-line tool that tests SSL/TLS services by connecting to a host and enumerating the protocol versions and cipher suites it accepts. The actively maintained version is published on GitHub by rbsec. It also reports details such as the preferred cipher, key exchange strength, certificate information, renegotiation and compression support, and Heartbleed exposure. Results can be written as XML with the --xml option, which is the format DefectDojo imports.

Sslscan Integration with DefectDojo

We run sslscan across our external endpoints because it is quick, scriptable, and tells us exactly which ciphers a server will accept. The output is easy to read for one host and tedious for two hundred. Importing sslscan XML into DefectDojo turns each weak cipher and each Heartbleed-vulnerable protocol into a Finding tied to the host and port, deduplicated against earlier runs. When the load balancer team removes a cipher suite, the next reimport closes the Finding, and we have a dated record of when it happened.

Why Sslscan Matters

TLS configuration drifts. A new appliance ships with old defaults, a library upgrade re-enables a cipher, or a legacy endpoint is forgotten.

• sslscan shows the cipher suites a server actually negotiates, not what the configuration file claims.
• It classifies each accepted cipher by strength, which makes weak suites easy to spot.
• It tests for Heartbleed on each protocol version it finds.
• It is lightweight and needs no agent, so it can run against any reachable TLS service, including network devices.
• Repeated runs on their own leave no history. You can't easily answer how long a weak cipher was exposed on a given host.

Advantages of This Integration

What we gained by sending sslscan results through DefectDojo:

• Findings per host and port. Each Finding carries an endpoint built from the scanned host and port, so TLS issues are attached to the service that has them.
• Only the problems. The parser imports ciphers whose strength is something other than acceptable or strong, plus Heartbleed results marked vulnerable, so good configurations don't create noise.
• Reimport lifecycle. Reimporting the next run into the same Test mitigates findings for ciphers that were removed and reactivates any that return after a configuration change.
• SLAs and ownership. Findings can be assigned to the team that owns the endpoint, given a severity that fits your policy, and pushed to Jira.
• History for audits. DefectDojo keeps discovery and mitigation dates, which helps answer questions about TLS configuration from PCI-DSS or customer security reviews.

How This Integration Works

DefectDojo imports sslscan output with the Sslscan scan type. It expects the XML document sslscan writes, with a document root element and one ssltest element per target.

1. Run sslscan with XML output:

sslscan --xml=sslscan-api.xml api.example.com:443

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Sslscan, and upload the XML. 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=Sslscan" \
  -F "file=@sslscan-api.xml" \
  -F "product_name=public-endpoints" \
  -F "engagement_name=TLS Checks" \
  -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 "Sslscan" \
  --report-path "./sslscan-api.xml" \
  --product-name "public-endpoints" \
  --engagement-name "TLS Checks" \
  --auto-create-context

3. Reimport on a schedule. Send each later run for the same target to /api/v2/reimport-scan/ against the same Test.

If you scan many hosts, loop over them in your job and write one XML file per host, then import each file into a Test named for that host or service. The Operational Tips below explain why one target per file matters for this parser.

Data Granularity: What Gets Imported

Within one file, findings with the same title and description are imported once. The cipher name is in the description, so each weak cipher on each protocol version becomes its own Finding.

Use Cases

For external attack surface checks: A nightly job runs sslscan against every public hostname and reimports each result. When a CDN or load balancer change re-enables a weak suite, the Finding reappears the next morning with the affected host.

During a TLS hardening project: The platform team removes legacy ciphers across a fleet of services. Reimported results show which hosts still accept them, and the mitigated dates document progress.

For compliance reviews: Weak cipher and Heartbleed findings, with their discovery and closure dates, give auditors evidence of how TLS configuration is monitored.

Alongside other infrastructure scans: sslscan findings sit on the same Asset as network scanner and DAST results for the same service, so TLS issues aren't tracked in a separate spreadsheet.

Operational Tips

• Scan one target per XML file. Within a file, findings are merged by title and description only, so when the same weak cipher appears on a second host, that host's endpoint is not added. Separate files keep every host visible.
• Plan for the severity gap. Every sslscan Finding arrives as Info, so set severity during triage (for example High for Heartbleed) before SLAs and dashboards depend on it, and don't use minimum_severity above Info for this scan type.
• The parser doesn't report certificate expiry or deprecated protocol versions on their own. Pair sslscan with another check if those matter to you.
• Use one Test per target and reimport into it, so each removed cipher is recorded as a mitigation.
• Tag imports with the environment or service owner (for example tags=external,cdn) so weak TLS findings can be filtered by team.
• Risk-accept weak ciphers that a legacy client truly requires, with an expiration date and a note naming the client, so the exception is revisited.