TestSSL parser: track post-quantum readiness across reimports

[AAH20]

⚠️ Note on feature completeness ⚠️

This is a pre-approval request for a parser-only enhancement. It would not add a model, database migration, API route, UI page, or third-party service integration.

Is your feature request related to a problem? Please describe

testssl.sh is discussing stable, machine-readable post-quantum readiness results in testssl/testssl.sh#3116. DefectDojo already imports TestSSL CSV, but the current parser treats every non-OK row as a conventional finding and builds its internal duplicate key from the title, description, and CVE.

For migration posture, the evidence and description legitimately change across scans. For example, an endpoint may move from classical-only key exchange to X25519MLKEM768, or from a legacy Kyber draft group to standardized ML-KEM. If changing evidence changes finding identity, a rescan can create another finding instead of representing remediation or regression on the same endpoint/control.

Key-exchange posture also needs to remain distinct from certificate authentication posture: classical key exchange is relevant to harvest-now-decrypt-later collection, while authentication migration has a different urgency and deployment path. Neither should be presented as a currently exploitable CVE.

Describe the solution you'd like

As a DefectDojo operator, I want TestSSL post-quantum readiness results to have stable endpoint-scoped identity so that reimports can track remediation and regression without duplicate findings.

Subject to the final upstream output contract, enhance only the existing TestSSL parser to:

• recognize stable readiness result IDs such as PQC_KEX and PQC_AUTH (or the final IDs selected upstream);
• import classical-only key exchange as an informational migration finding, not a vulnerability with a CVE;
• distinguish standardized hybrid KEX, legacy PQ draft groups, classical-only KEX, and unknown evidence;
• keep key-exchange/HNDL posture separate from authentication posture;
• populate unique_id_from_tool from stable evidence dimensions such as result ID, hostname, port, and protocol rather than the changing description;
• preserve the observed groups, certificate algorithm, and scanner evidence in the description;
• keep unknown values unknown instead of inferring quantum safety;
• retain all existing behavior for TestSSL result IDs unrelated to PQC.

The PR would target dev and include parser fixtures and tests for:

• classical-only -> standardized hybrid remediation;
• standardized hybrid -> classical-only regression;
• legacy Kyber draft -> standardized ML-KEM migration;
• a certificate change that does not change KEX finding identity;
• the same readiness result on multiple hosts and ports;
• duplicate rows, malformed rows, and unknown groups;
• compatibility with current TestSSL CSV fixtures;
• importer query/task counts if the change affects the performance baselines.

The implementation would be parser-only and use existing Finding fields and reimport/deduplication behavior.

Describe alternatives you've considered

1. Import every readiness row generically. This works syntactically but gives changing posture descriptions unstable lifecycle semantics and does not separate HNDL exposure from authentication migration.
2. Add PQC-specific database fields or a dashboard. DefectDojo's contribution guidance explicitly discourages new models and UI pages for this type of enhancement, and they are unnecessary for an initial integration.
3. Maintain an external transformation layer. That duplicates parser logic for every DefectDojo user and makes remediation closure dependent on private glue code.
4. Wait until all PQC standards and certificate ecosystems are complete. This prevents organizations from managing the immediate inventory and key-exchange transition work already represented by standardized X25519MLKEM768.

Additional context

• Upstream TestSSL feature and maintainer discussion: [Feature request] Add PQC-safe (Shor/Grover) reporting testssl/testssl.sh#3116
• Existing TestSSL parser documentation: https://docs.defectdojo.com/en/connecting_your_tools/parsers/file/testssl/
• The proposed scanner output is informational and should not alter DefectDojo severity policy or claim present-day quantum exploitation.
• I can provide synthetic, organization-neutral CSV fixtures once the upstream result IDs are confirmed.

Disclosure: I maintain a related open-source PQC implementation and work through A2Z SOC, which provides scoped PQC exposure and migration-readiness assessments. The proposed parser, fixtures, tests, and documentation would remain vendor-neutral and contain no service promotion.