What a static PQC-readiness scan sees in Quarkus 3.39.2, as a follow-up to #55982

[Arpan0995]

In #55982 the conclusion was that Quarkus's post-quantum work sits in the TLS layer (Vert.x, Netty, the OpenSSL engine and the key-exchange-groups configuration) and in the JWT libraries, and @michalvavrik asked for focused follow-ups after analysing the current branch. This is one such follow-up from a different angle: a call-site scan of the Quarkus repository itself, to see how much asymmetric crypto Quarkus's own code touches.

I maintain a static auditor that finds where a Java codebase uses quantum-vulnerable asymmetric crypto and estimates what changing it would cost (https://github.com/Arpan0995/pqc-migration-readiness, Apache-2.0). It reads source only, no build. I ran 1.4.0 on the 3.39.2 tag.

Headline: Quarkus's own code has a small asymmetric-crypto surface, and it sits where you would expect. 22,057 files scanned, 80 findings in 17 modules, and the top of the ranking is Quarkus's own integration-test harnesses rather than shipped extensions.

#	Step	Sites	Where	Effort
1	Set up a PQC provider and an agility seam	n/a	n/a	~3–5 days
2	Decouple concrete key types from APIs	32	integration-tests/test-extension/extension/deployment, integration-tests/test-extension/extension/runtime, extensions/security-webauthn/runtime +4 more	~7–14 days
3	Regenerate keys with PQC or hybrid algorithms	16	integration-tests/test-extension/extension/deployment, integration-tests/elytron-security, integration-tests/bouncycastle +6 more	~2–4 weeks
4	Migrate signatures to ML-DSA	5	integration-tests/elytron-security, integration-tests/bouncycastle, test-framework/security-webauthn +1 more	~4–8 days
5	Re-issue persisted key material	11	integration-tests/test-extension/extension/deployment, integration-tests/elytron-security, integration-tests/bouncycastle +3 more	counted in the steps above
6	Widen fixed-size buffers and wire formats	1	test-framework/security-webauthn	counted in the steps above
7	Test and roll out	n/a	n/a	~2–9 weeks

The ranking as the tool prints it. One caveat first: its test-scope heuristic keys on src/test paths, and Quarkus keeps its integration tests as full modules with code under src/main, so rows 1 to 4, 7, 10 and 11 are test harnesses ranked as production. Discount them, and read the effort range above with the same discount, since most of its sites are theirs.

Rank	Module	Tier	Score S	Urgency U	Baseline B0	LOC
1	integration-tests/test-extension/extension/deployment	MEDIUM	27.6	34.0	3	3725
2	integration-tests/elytron-security	MEDIUM	24.33	22.0	6	202
3	integration-tests/bouncycastle	MEDIUM	18.7	23.0	6	197
4	integration-tests/test-extension/extension/runtime	MEDIUM	17.25	24.0	1	1223
5	extensions/security-webauthn/runtime	MEDIUM	16.5	18.0	3	1924
6	extensions/smallrye-jwt/runtime	LOW	9.9	14.0	1	453
7	test-framework/security-webauthn	LOW	8.8	11.0	2	607
8	extensions/devservices/oidc	LOW	4.4	8.0	1	1009
9	extensions/oidc-client-registration/runtime	LOW	3.3	6.0	0	1684
10	integration-tests/bouncycastle-fips	LOW	3.3	3.0	1	136
11	integration-tests/oidc-client-registration	LOW	2.2	4.0	1	620

What is left after discounting the harnesses is four production sites:

• extensions/security-webauthn/runtime: WebAuthnCredentialRecord rebuilds credential public keys through KeyFactory for EC, EdDSA and RSA (lines 123 to 133) and casts them to ECPublicKey, EdECPublicKey and RSAPublicKey. That is the seam a post-quantum WebAuthn credential would have to pass through once the COSE side of that settles.
• extensions/smallrye-jwt/runtime: PublicKeySubstitution is an ObjectSubstitution<RSAPublicKey, PublicKeyProxy> and rebuilds the key with KeyFactory.getInstance("RSA"). An ML-DSA verification key would not pass through it as written.
• extensions/devservices/oidc: RSA key generation in OidcDevServicesProcessor (line 436) for the dev-services token issuer.
• extensions/oidc-client-registration/runtime: ClientMetadata branches on RSAPublicKey and ECPublicKey when it serialises keys.

Everything else in the list is an integration test or the build-time test extension. The scan finds no TLS pins in production code at all, which matches where #56262 ended up: the key-exchange choice lives in configuration and in the engine, not in Java literals.

Two limitations to state plainly:

• Algorithm names that arrive from configuration or through wrapper methods are not resolved, so nothing Quarkus does through quarkus.tls.* or smallrye.jwt.* settings appears here. For Quarkus that is a property of the codebase, not a gap in it, and it is the reason the TLS half of Post-Quantum Cryptography (PQC) support: TLS key exchange and JWT signing readiness #55982 is invisible to this kind of scan by design.
• The repository needed a 12 GB heap to scan in one pass; the default 4 GB heap on a 16 GB machine runs out at this file count. That is a defect on my side, tracked as Scanning 20k+ files exhausts the default heap: every CompilationUnit is retained for constant propagation Arpan0995/pqc-migration-readiness#19.

Two questions for the security team:

1. Do the four production sites above match your own list of what would have to change in Quarkus proper for ML-DSA credentials and tokens, or is there a site the scan missed, for example one where the key type arrives through a Vert.x or Elytron API rather than the JCA?
2. When the jose4j or Nimbus ML-DSA work lands, is the SmallRye JWT substitution the place to watch in Quarkus, or does the whole concern move into the library?

The full report is 80 findings, so the JSON and SARIF are small; happy to attach them if useful.

[quarkus-bot[bot]]

/cc @Karm (securepipeline), @jerboaa (securepipeline)

[cescoffier]

Thanks for this inventory. I've been maintaining something similar (using a different tool: https://www.ibm.com/docs/en/quantum-safe/quantum-safe-explorer/2.x?topic=quantum-safe-explorer-overview). About JWT, we started discussing with @sberyozkin about support for ML-DSA, and it's in progress. For WebAuthN, we haven't started work yet, but we will follow the same approach as for JWT.

About your questions,

1. Yes, there are other call sites in Vert.x, Netty, Elytron...
2. Yes, there is a draft PR on smallry-JWT to switch to Nimbus and use ML-DSA.

[Arpan0995]

Thanks Clément, useful to know on all three. Quantum Safe Explorer is the build-and-semantic-analysis end of this; my scanner is deliberately the opposite trade, a no-build syntactic pass, so it is blind to exactly the Vert.x, Netty and Elytron sites you mention, where the algorithm arrives through an API rather than a JCA literal. Good to have that confirmed rather than assumed.

The SmallRye JWT move to Nimbus and ML-DSA is the one production site the scan did flag, PublicKeySubstitution rebuilding an RSAPublicKey through KeyFactory. If it helps, I am happy to re-run the auditor once that PR lands and post the residual here, so you can see what the switch clears and what is left. When WebAuthn starts, WebAuthnCredentialRecord is the equivalent seam.

If you found PQC Migration Readiness interesting, please leave us a star on our GitHub repository ⭐ https://github.com/Arpan0995/pqc-migration-readiness