Share your scan results here

[Arpan0995]

Post what the auditor found on a codebase you know. Phase 1 of this project produces estimates, and the only way to learn where the ranking is right and where it is wrong is to put it next to people who know the code. Every report posted here feeds that comparison.

What to include

• Auditor version (1.4.0 at the time of writing) and the JDK you ran it on.
• The command, including any --exclude or --skip-tests.
• The "Migration plan at a glance" table and the module ranking from readiness-report.md. Hotspot tables too, if the code is public.
• Your view: does the ranking match what you know about the code? Which hotspots are real, which are noise, and what did the scan miss?

A private codebase can be posted with module names redacted; the plan table and the ranking still tell the story. If something looks like a detection gap, please file it with the "Detection gap" issue template so it gets tracked, and link it from your post.

---

Eclipse Californium 3.14.0 (pinned case study), auditor 1.4.0, JDK 21

java -jar pqc-readiness-auditor-1.4.0-all.jar case-studies/californium/repo --out out --name californium-3.14.0

1001 files scanned, 34 findings across 4 modules. Estimated effort for one engineer: ~4–9 weeks (change work ~2–4 weeks, testing ~1–4 weeks, plus ~3–5 days of one-time setup).

#	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	10	element-connector, scandium-core	~2–5 days
3	Regenerate keys with PQC or hybrid algorithms	12	element-connector	~6–11 days
4	Migrate signatures to ML-DSA	1	element-connector	~6–11 hours
5	Rework pinned TLS configuration	3	element-connector-tcp-netty, cf-utils/cf-cli-tcp-netty	~2–4 days
6	Test and roll out	n/a	n/a	~1–4 weeks

Rank	Module	Tier	Score S	Urgency U	Baseline B0	LOC
1	element-connector	HIGH	46.82	70.0	15	35472
2	element-connector-tcp-netty	MEDIUM	14.79	16.0	4	3356
3	scandium-core	MEDIUM	13.2	22.0	3	60956
4	cf-utils/cf-cli-tcp-netty	LOW	3.3	4.0	1	166

What I take from it:

• The plan is carried by element-connector: KeyFactory and KeyPairGenerator sites for EC, EdDSA and RSA in Asn1DerDecoder and JceProviderUtil, one ECDSA Signature site, and ECPublicKey couplings. That module is the credential and key-loading layer, so the work concentrating there makes sense.
• The TLS step comes from pinned protocol versions and cipher-suite lists in the two netty connectors (TlsClientConnector, TlsServerConnector) and the CLI utility. Those pins are where a hybrid key exchange would be blocked once the runtime offers one.
• scandium-core, the DTLS implementation, ranks third with 60k LOC and shows only ECPublicKey couplings and EC KeyFactory use. Its ECDHE key agreement in XECDHECryptography goes through ThreadLocalKeyAgreement wrappers: the getInstance call sits inside a helper class with the algorithm passed in as a constructor argument, and the auditor's constant propagation does not follow method parameters. The DTLS handshake therefore produces no key-establishment step, which understates that module. Tracked in Model enums and registries so dynamically selected algorithms are found #5.
• Eight of the 34 findings sit under test source roots in element-connector, element-connector-tcp-netty and scandium-core. They are counted in the totals and left out of the plan.

The reports for the other three case studies (jjwt 0.13.0, Apache MINA SSHD 2.13.1, Apache Shiro 2.2.1) are under case-studies/ in the repository.