Post-Quantum Cryptography in CI/CD Pipelines

Quantum computing is advancing fast, and it’s a threat to today’s encryption. Algorithms like RSA and ECC - used widely in CI/CD pipelines for tasks like code signing - are vulnerable to future quantum attacks. This means attackers could exploit encrypted data or forge signatures once quantum computers mature.

Here’s what you need to know:

• Post-Quantum Cryptography (PQC): Designed to resist both classical and quantum attacks, standards like ML-KEM and ML-DSA are already available.
• Why CI/CD Pipelines Matter: These systems rely on cryptography for secure deployments, making them a critical target for quantum threats.
• Challenges: Migrating to PQC involves identifying hidden cryptographic dependencies, dealing with larger key sizes, and ensuring legacy systems can handle new algorithms.
• Solutions: Automate cryptographic discovery, implement hybrid key exchanges, and plan for added resource demands.

Organisations should act now to secure their pipelines, as full adoption of PQC can take over a decade. Start with a cryptographic audit, enable hybrid systems, and invest in tools for seamless integration.

Towards a Quantum Proof Software Supply Chain with Post Quant... - Anitha Natarajan & Savita Ashture

Challenges of Adding Post-Quantum Cryptography to CI/CD Pipelines

::: @figure {Post-Quantum vs Classical Cryptography: Key Size and Performance Comparison} :::

As organisations prepare their CI/CD pipelines for a quantum-resistant future, they face a range of challenges. The integration of post-quantum cryptography (PQC) introduces technical, operational, and organisational hurdles that can disrupt established workflows if not approached carefully. These challenges arise from the fundamental differences between classical and quantum-resistant algorithms, as well as the complexity of modern software supply chains.

Finding Cryptographic Dependencies in Complex Codebases

One significant challenge is identifying all cryptographic elements within a codebase. Modern software projects often include 300 to over 1,000 transitive dependencies, many of which contain hidden cryptographic implementations buried deep within the supply chain [6]. Cryptography is frequently scattered across source code, configuration files, and third-party binaries, often with little to no centralised documentation [7]. The real difficulty lies in distinguishing between cryptographic libraries that are simply present in the environment and those actively used by application code - a critical difference between available and reachable cryptography [6].

This issue is compounded when CI/CD pipelines deploy software as binary executables, which are far more challenging to audit for quantum-vulnerable APIs than source code [5]. Without appropriate tools, teams may spend months manually tracing cryptographic usage. Automated solutions like QED can reduce this workload by over 90%, saving significant time and effort [5]. However, even after identifying dependencies, resource demands present another hurdle.

Performance and Resource Demands of PQC

Post-quantum algorithms consume more resources compared to traditional cryptographic methods. For example, Kyber768 (ML-KEM) public keys are around 1.2 KB, and Dilithium2 (ML-DSA) signatures can reach roughly 2.4 KB, dwarfing the compact 64-byte ECDSA signatures [4]. This increase in size impacts various layers of the CI/CD pipeline, from TLS handshakes to artefact signing and storage.

A PQC-only TLS handshake can grow to 17 KB, marking a 325% increase over classical methods. Hybrid handshakes, which combine classical and quantum-resistant algorithms, can expand further to 22 KB, a 450% increase [8]. Such large packets can exceed the standard TCP initial congestion window, potentially adding an extra round trip time to every connection [8]. This becomes particularly problematic in high-churn environments like serverless functions or ephemeral containers, where connection pooling is less effective [8]. Organisations are advised to reserve an additional 10–20% CPU capacity in TLS termination pools to handle the increased demands of hybrid post-quantum key exchanges [4]. Beyond performance, adapting legacy systems to PQC standards poses unique challenges.

Making Legacy Systems and Tools Compatible with PQC

Legacy systems often struggle to accommodate PQC without disrupting workflows. Larger handshake packets from PQC can cause issues with older middleboxes, Deep Packet Inspection (DPI) tools, and load balancers, which may drop connections or malfunction when handling unexpectedly large TLS ClientHello messages [4].

Another challenge is the delay in obtaining FIPS 140-3 validation for PQC algorithms in open-source libraries. Regulated environments cannot deploy PQC in production until the necessary cryptographic modules achieve CMVP validation, a process that typically takes over a year [2]. For instance, in January 2026, CIQ submitted its Network Security Services (NSS) module, which includes ML-KEM and ML-DSA implementations, to the NIST Modules in Process list for FIPS 140-3 validation. While the code is operational in Rocky Linux 9.6, full validation is not expected until Q2 2027 due to the NIST validation queue [2].

Additionally, existing tools such as vulnerability scanners, refactoring engines, and testing frameworks often fail to account for PQC's unique attributes, such as its probabilistic behaviour, sensitivity to side-channel attacks, and complex performance trade-offs [9].

Treating this as a routine 'library upgrade' is dangerously simplistic. - Lei Zhang, University of Maryland, Baltimore County [9]

Solutions for Integrating PQC into CI/CD Pipelines

To tackle the challenges of integrating post-quantum cryptography (PQC) into CI/CD pipelines, an effective plan involves three key strategies: automating discovery, enabling flexibility, and improving performance. These solutions aim to simplify the process, reduce manual work, and maintain strong security standards.

Automating Cryptographic Discovery and Updates

Tools like Automated Cryptography Discovery and Inventory (ACDI) help by scanning repositories during commits and pull requests to detect quantum-vulnerable algorithms such as RSA and ECDSA [3]. For example, CryptoDeps uses reachability analysis to distinguish between actively used and merely available cryptographic functions, making it easier to prioritise updates [6]. This approach cuts down on false positives and ensures teams focus on the most critical vulnerabilities.

The challenge? You can't migrate what you can't find. - CryptoScan [11]

CryptoScan, equipped with over 90 detection patterns and context-aware scoring, identifies cryptographic usage across various technology stacks with precision [11]. These tools also generate machine-readable inventories, which are useful for compliance checks [10][12]. By integrating solutions like CBOMkit-action into GitHub or GitLab workflows, teams can receive security alerts directly in pull requests via SARIF output [10][11]. To minimise disruptions, baseline files can store existing legacy issues, ensuring the CI/CD pipeline only flags new quantum-vulnerable dependencies [11]. This automation fits seamlessly into workflows designed for cryptographic flexibility.

Building Cryptographic Flexibility into CI/CD Workflows

Once vulnerabilities are identified, teams can implement flexible systems that support both traditional and quantum-resistant cryptography. Hybrid systems, for instance, combine classical algorithms (like ECDH or RSA) with quantum-safe alternatives (such as Kyber or Dilithium), maintaining backward compatibility while introducing quantum resistance [4][13].

A dual-signing strategy is another effective approach. This involves generating both a classical ECDSA signature and a PQC ML-DSA signature for the same artefact. Classical systems can verify the ECDSA signature, while PQC-aware systems rely on the quantum-safe signature [4][13].

Tools like OpenSSL 3.0’s provider model enable cryptographic agility, allowing teams to switch algorithms through centralised configurations without disrupting workflows [13]. Similarly, TLS 1.3 extensions support hybrid key exchange groups (e.g., X25519Kyber768), ensuring compatibility with classical methods if PQC isn't supported on the client side [4][13]. Alarmingly, 68% of enterprises currently lack frameworks for cryptographic agility, leaving them vulnerable to quantum threats [13].

Addressing Performance and Resource Issues

Integrating PQC without slowing down operations requires careful planning. Parallelising PQC tasks across multi-core runners can reduce latency, while GPU-based hardware acceleration can improve efficiency by up to 62%. Selective deployment of algorithms is another way to optimise performance. For instance, Dilithium is ideal for high-speed verification, whereas SPHINCS+ is better suited for low-frequency, high-assurance tasks like firmware signing.

Organisations should also plan for increased resource demands. For example, TLS termination pools may need 10–20% extra CPU capacity, and larger artefact sizes must be accounted for, as Dilithium signatures are roughly 40 times larger than ECDSA [13]. Phased rollouts can help manage costs and ensure a smoother transition [13].

Continuous Testing and Verification for PQC Readiness

Getting started with integration is only part of the journey. To truly ensure quantum resilience, organisations need continuous testing and verification. This ongoing effort works hand-in-hand with earlier automation and flexible workflows to maintain security as standards and threats change. Without it, there’s a real risk of deploying quantum-vulnerable code or missing performance issues that slipped through during initial integration.

Hybrid Testing Approaches for PQC

Sustaining security requires thorough validation of PQC implementations using tailored testing methods. For instance, during testing, dual-signing processes should be verified to ensure both classical and PQC signatures perform as intended. In this setup, classical systems validate the ECDSA signature, while PQC-aware systems focus on the quantum-safe alternative [4].

Canary rollouts offer a practical way to test hybrid implementations in production. By routing only 1–5% of traffic through PQC-enabled paths, teams can monitor handshake success, p99 latency, and CPU overhead without causing major disruptions [4]. This gradual rollout can also uncover compatibility issues, such as middleboxes or deep packet inspection tools struggling with the larger size of PQC packets.

Another useful method is reachability analysis, which helps reduce unnecessary alerts by distinguishing between cryptographic functions that are merely present and those actively used by your code. Tools like CryptoDeps categorise findings into three levels: CONFIRMED (directly called by your code), REACHABLE (accessible through your code's call graph), or AVAILABLE (present in dependencies but not invoked) [6]. This categorisation helps teams focus on addressing the most critical vulnerabilities first. Together, these testing strategies pave the way for automated audits that ensure long-term compliance.

Automated Security Audits

To further strengthen PQC readiness, automated audits play a key role. Integrated into deployment gates through tools like Open Policy Agent (OPA), these audits block artefacts signed with non-compliant or quantum-vulnerable algorithms, cutting down manual effort by as much as 90% [13].

Generating a Cryptographic Bill of Materials (CBOM) during each build is another essential step. This provides a detailed, machine-readable inventory of all cryptographic algorithms in use - critical for meeting emerging standards like OMB M-23-02 [6][11]. By exporting scan results in Static Analysis Results Interchange Format (SARIF), teams can get instant feedback directly within security dashboards on platforms like GitHub or GitLab. This allows developers to fix issues before the code ever reaches production [6].

For runtime environments, tools like CipherIQ use eBPF to monitor cryptographic operations in real time. This helps detect cryptographic drift - when runtime behaviour deviates from static configurations [14]. Combining static analysis with runtime monitoring ensures PQC implementations stay secure as infrastructure evolves, acting as a final safeguard in a robust PQC strategy.

Conclusion and Next Steps

Preparing for quantum threats by integrating post-quantum cryptography (PQC) into CI/CD pipelines is no longer optional - it's a necessity. The process, however, comes with its fair share of challenges. These include uncovering hidden cryptographic dependencies in sprawling codebases, addressing the performance impact of PQC, and ensuring older systems remain compatible with quantum-safe algorithms. Thankfully, there are practical solutions to tackle these hurdles. Automated tools for cryptographic discovery, modular designs that allow flexibility, and hybrid approaches that combine classical and post-quantum algorithms offer a clear way forward. Here's a breakdown of the key challenges and actionable steps to achieve quantum readiness.

Summary of Key Challenges and Solutions

The first step to quantum safety is identifying vulnerabilities. If you don’t know where quantum-vulnerable algorithms like RSA and ECDSA are being used, you can’t protect them. Tools integrated into CI/CD workflows can help by scanning for these algorithms and creating a Cryptographic Bill of Materials (CBOM) - a roadmap for migration. Performance is another major concern. PQC keys are much larger than traditional keys, which can lead to issues like packet fragmentation and connection failures when handshake messages exceed network MTU limits. For legacy systems, dual-signing workflows are essential. These allow both classical and quantum-safe signatures to coexist, ensuring compatibility across old and new environments [4].

Practical Steps for Post-Quantum Readiness

To address these challenges, organisations can take the following steps to implement PQC effectively:

• Start with a Cryptographic Audit: Use static analysis tools to identify where quantum-vulnerable algorithms like RSA and ECDSA are used. Prioritise these based on the sensitivity of the data and the lifespan of the assets. The NCSC recommends completing this phase by 2028, migrating high-priority assets by 2031, and achieving full migration by 2035 [1].

• Enable Hybrid Key Exchanges: Protect against harvest now, decrypt later attacks by combining classical and post-quantum algorithms. For example, pairing X25519 with Kyber768 for TLS and SSH is a straightforward way to enhance security. DebuggAI highlights this as a critical step:

If you do nothing else in 2025, enable hybrid TLS. It's the cleanest, least disruptive step to inoculate your transport confidentiality against future quantum advances [4].

• Invest in Cryptographic Agility: Design systems with modular libraries and policy-driven configurations to allow seamless algorithm swaps as PQC standards evolve. This flexibility ensures long-term resilience against both current and emerging threats.

For organisations needing additional support, Hokstad Consulting offers expertise in DevOps transformation and cloud infrastructure optimisation. They provide tailored automation solutions to streamline PQC integration while minimising performance trade-offs. Allocating 15–20% of your annual cybersecurity budget to PQC-related expenses - such as increased cloud KMS fees for larger keys and hardware upgrades - can also help ensure a smooth transition [13].

FAQs