Quantum-Safe Code Auditing: Static Analysis for Cryptographic Vulnerability Detection

Quantum-safe code auditing is the discipline of automatically locating, cataloguing and remediating calls to cryptographic algorithms that a sufficiently powerful quantum computer will be able to break, before that capability exists and before adversaries using harvest-now-decrypt-later strategies have already collected the ciphertext. For European public-sector bodies and regulated organisations, this is not a theoretical exercise: it is a compliance obligation with a tightening timeline.

The urgency is not distant. NIST finalised three post-quantum cryptographic (PQC) standards in August 2024 after evaluating 82 candidate algorithms over eight years. NIST IR 8547, published as an initial public draft in 2024, translates those standards into concrete migration guidance and makes a complete cryptographic inventory the first required step. The ENISA Post-Quantum Cryptography Integration Study 2022 reaches the same conclusion: you cannot migrate what you have not yet mapped.

Static Analysis Across Polyglot Codebases

Automated static analysis is the only practical way to find cryptographic algorithm calls at scale across codebases that span Java, Python, Go and C/C++ without manually reviewing every dependency. Several open-source approaches exist and can be combined.

IBM’s open-source cbomkit project scans Java bytecode and source for direct calls to JCA providers using RSA, ECDSA, ECDH or finite-field Diffie-Hellman. It emits findings in CycloneDX CBOM schema format, making the output directly consumable by downstream risk-scoring pipelines. For Python, Semgrep custom rulesets can match patterns such as cryptography.hazmat.primitives.asymmetric.rsa and flag key-size parameters below safe PQC thresholds. Go’s standard library usage, including crypto/rsa and crypto/elliptic, is detectable by AST-level rules in Semgrep or govulncheck extended with custom policies. For C/C++, CodeQL queries targeting OpenSSL API calls such as RSA_generate_key, EC_KEY_new_by_curve_name and DH_new cover the most common attack surface.

OWASP Dependency-Check and Syft can flag third-party libraries that expose only pre-quantum cipher suites through their software bill of materials metadata, even when the calling code itself is not directly instrumented. Combining direct-call scanning with dependency-level scanning is essential: a significant proportion of quantum-vulnerable algorithm usage in production systems lives inside transitive dependencies, not in first-party code.

Building and Using a Cryptographic Bill of Materials

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic primitive, protocol version, key length and library instance present in a system. The CycloneDX CBOM schema, maintained by the OWASP CycloneDX project, provides the interchange format used by cbomkit, Dependency-Track and an increasing number of commercial scanners.

NIST IR 8547 explicitly positions the CBOM as the prerequisite artefact for any PQC migration plan. The ENISA Post-Quantum Cryptography Integration Study 2022 echoes this, stating: “The integration of post-quantum cryptography into existing systems requires a thorough inventory of all cryptographic assets, protocols and dependencies before any migration can begin.”

Once generated, a CBOM becomes actionable only when fed into a risk-scoring model that accounts for three variables: asset sensitivity (is this a payment signing key or a session cookie?), data-retention lifetime (will the protected data still need to be confidential in 2040?), and exposure to harvest-now-decrypt-later interception (does this endpoint face the public internet or a foreign government-linked network?). An RSA-2048 key protecting a 25-year mortgage contract scores dramatically higher than one protecting a one-hour session token, even though both use the same vulnerable algorithm. This weighting is the mechanism that transforms a flat list of findings into a prioritised remediation backlog.

CI/CD Pipeline Gates for Sovereign DevSecOps Teams

Pipeline gates that block quantum-vulnerable algorithm introductions must be built into the merge-request stage, not as a post-deployment report. The practical implementation uses a two-layer approach.

The first layer is a pre-commit or PR-level Semgrep or CodeQL scan that flags any newly introduced call to a blocked algorithm. The gate compares the diff, not the full codebase, so it catches regressions without becoming a bottleneck for unrelated changes. The second layer is a full-codebase CBOM regeneration on every merge to a protected branch, with the updated CBOM committed to the repository’s artefact store and compared against the previous version to detect net increases in cryptographic risk score.

Policy exceptions are unavoidable, particularly for third-party dependencies with no upstream PQC patch. Each exception must be documented with: the specific library name and version, the vulnerable algorithm and key parameters, the risk score derived from the CBOM model, the business justification, a compensating control (such as network isolation or additional monitoring), and a remediation deadline. This documentation is not optional for regulated organisations: it constitutes the audit trail required under NIS-2 Article 21 and DORA Article 9 to demonstrate that residual cryptographic risk is consciously accepted and time-bounded.

Handling Third-Party Library Vulnerabilities Under the Cyber Resilience Act

The Cyber Resilience Act (CRA), in force from 2024 with phased applicability, creates explicit vulnerability disclosure obligations that interact directly with PQC migration. When a CBOM scan identifies a quantum-vulnerable algorithm in an open-source dependency and no upstream maintainer has yet published a PQC-compatible release, the organisation faces a gap that existing patch management processes were not designed to handle.

The responsible path is to raise an issue with the upstream project, document the disclosure in the organisation’s vulnerability register with a CVE or CRA-aligned identifier, implement a compensating control, and set a review date. If the upstream project is effectively unmaintained, CRA Article 13 obligations point toward forking the library under the organisation’s own maintenance, or replacing it entirely, rather than carrying an undocumented dependency indefinitely. For financial-sector organisations, the Europol-EBA PQC Migration Report (2026) reinforces this by recommending that institutions track third-party cryptographic dependencies at the same level of rigour as first-party code.

Regulatory Frameworks That Require a CBOM

NIST IR 8547 is the most direct regulatory anchor: it mandates a cryptographic inventory as the first phase of any PQC migration programme for US federal systems, and European organisations that interact with US federal counterparts or that align their security programmes to NIST frameworks inherit this obligation by reference. The ENISA PQC Integration Study 2022 provides the European equivalent, mapping inventory requirements to the NIS-2 risk management obligations.

The Europol-EBA PQC Migration Report (2026) adds sector specificity for financial services, recommending milestone-based timelines for completing inventories and beginning migration of long-lived data assets. Dustin Moody, NIST’s PQC project lead, has stated: “Organizations should not wait for quantum computers to become a reality before acting. The time to migrate is now, while the standards are fresh and the threat is still approaching rather than present.” For DORA-regulated entities, this translates into ICT risk management documentation that must include cryptographic inventory outputs and migration plans to be audit-ready.

The average cost of a data breach reached USD 4.45 million globally in 2023, according to IBM’s Cost of a Data Breach Report. For organisations holding long-retention records, the retrospective cost of a harvest-now-decrypt-later attack would be compounded by regulatory fines under GDPR Article 83 and sectoral penalties, making the business case for early PQC auditing straightforward.

LLM-Assisted Code Analysis: Capability and Governance

Rule-based static analysis has a known limitation: it detects what its rules describe, and cryptographic algorithm usage is sometimes indirect, for example when an algorithm identifier is constructed dynamically from a configuration file or passed as a string parameter at runtime. LLM-assisted code analysis can reason about data flow and configuration context in ways that pattern-matching rules cannot, improving detection coverage for these cases.

However, the governance constraint is absolute: sending proprietary or regulated source code to a US-operated LLM API (OpenAI, Anthropic, Google Gemini) places that code under CLOUD Act and FISA 702 jurisdiction. For government bodies and regulated financial or healthcare organisations, this is not an acceptable tradeoff. The solution is to run the inference locally on a self-hosted open-source model such as Code Llama or a fine-tuned Mistral variant, deployed on sovereign infrastructure, whether on-premises or in a Swiss-hosted environment outside US legal reach. The auditing pipeline must route all LLM inference calls to an endpoint under the organisation’s own data-processing agreement. This requirement should be formalised in the organisation’s AI governance policy and verified during any third-party audit of the DevSecOps pipeline.

Practical Implementation Path

A sovereign organisation starting this programme should sequence as follows: first, deploy cbomkit and Semgrep with PQC rulesets against the most sensitive repositories, generating an initial CycloneDX CBOM. Second, weight the findings by asset sensitivity and data-retention lifetime to produce a prioritised backlog. Third, install CI/CD gates on protected branches with documented exception governance. Fourth, register third-party library gaps under the CRA-aligned vulnerability register and engage upstream maintainers. Fifth, align the CBOM output to NIST IR 8547 inventory requirements and ENISA PQC Integration Study recommendations for use in regulatory reporting. Finally, evaluate local LLM-assisted scanning for dynamic algorithm usage patterns, with clear sovereign-infrastructure constraints in the tool governance policy.

This sequence produces an audit-ready artefact trail that satisfies the inventory obligations in NIST IR 8547, the risk management documentation requirements in NIS-2 and DORA, and the vulnerability disclosure framework in CRA Article 13, all without exposing source code to foreign jurisdiction.

FAQ

Which open-source tools can detect quantum-vulnerable algorithm calls in a Java and Python codebase?

IBM’s open-source cbomkit project and Semgrep with custom PQC rulesets cover Java and Python respectively. For Java, cbomkit scans JCA provider calls and emits CycloneDX CBOM output. For Python, Semgrep rules targeting the cryptography.hazmat.primitives.asymmetric namespace and key-size parameters catch direct usage. OWASP Dependency-Check adds coverage at the dependency level for libraries that expose only pre-quantum cipher suites.

What is a CBOM and why does it matter for PQC compliance?

A Cryptographic Bill of Materials (CBOM), expressed in the CycloneDX CBOM schema, is a structured inventory of every cryptographic algorithm, key length, protocol and library version in a system. NIST IR 8547 and the ENISA PQC Integration Study 2022 both treat a complete CBOM as the prerequisite for any migration plan, because remediation priorities cannot be set without knowing what exists.

How should a CI/CD gate handle a third-party library that uses RSA-2048 with no upstream PQC patch available?

The gate blocks the merge by default. A policy exception requires documented justification: library name and version, vulnerable algorithm, risk score, compensating control and a remediation deadline. Under CRA Article 13, the organisation must also assess whether the absence of an upstream patch constitutes a vulnerability requiring disclosure to ENISA or the national CSIRT.

Can an LLM-based code analysis tool be used for PQC detection without exposing source code to a foreign cloud?

Yes, provided the model runs locally on sovereign infrastructure, such as a self-hosted Code Llama or Mistral instance on-premises or in a Swiss-hosted environment. Sending regulated source code to a US-operated LLM API creates CLOUD Act and FISA 702 exposure. The auditing pipeline must route all LLM inference calls to an endpoint under the organisation’s own data-processing agreement and physical control.

How do the Europol-EBA PQC migration recommendations apply to a financial institution’s code auditing programme?

The Europol-EBA PQC Migration Report (2026) recommends that financial institutions complete a full cryptographic inventory by defined milestones and prioritise assets handling long-lived data such as loan contracts and customer records. In practice, this means weighting the CBOM risk score by data-retention lifetime: an API endpoint that signs 25-year mortgage data ranks higher than one signing ephemeral session tokens, and CI/CD blocking thresholds must reflect that prioritisation.