The Quantum Threat to Today's Cryptography
Your codebase almost certainly relies on RSA and elliptic-curve cryptography — TLS, JWTs, SSH keys, signed tokens. All of it is breakable by a large enough quantum computer (Shor's algorithm). This isn't a distant threat; "harvest now, decrypt later" means data you encrypt today can be captured and decrypted in the future when quantum computers become powerful enough. Regulators are already taking notice. Mandates like CNSA 2.0 (US federal and suppliers), DORA (EU financial entities, effective January 2025), and NIS2 now require strict cryptographic risk management. At its core, this means understanding where your quantum-vulnerable cryptography resides—a requirement that necessitates a cryptographic bill of materials (CBOM).
The challenge for most development teams is that answering the simple question, "Where is our RSA/ECC used?" is often not readily available. This lack of visibility creates a significant blind spot, leaving organizations exposed to future cryptographic threats and regulatory non-compliance. Fortunately, integrating this visibility into your development workflow is becoming increasingly straightforward.
Automating Post-Quantum Readiness Checks
The solution lies in integrating automated checks directly into your Continuous Integration (CI) pipeline. By doing so, you ensure that every code push is assessed for its post-quantum readiness, providing immediate feedback and maintaining a consistent level of security hygiene. This approach transforms a complex, manual auditing process into an automated, on-demand report.
A new GitHub Action aims to simplify this process dramatically. Developed to be integrated with minimal effort, this action scans your entire repository, analyzes the cryptographic primitives in use, and assigns a post-quantum readiness grade ranging from A (most resistant) to F (most vulnerable). More importantly, it generates a CycloneDX 1.6 CBOM, a standardized format for listing software components and their associated metadata, including cryptographic dependencies. This CBOM is crucial for understanding your cryptographic attack surface and for meeting regulatory requirements.
The action is designed for ease of use. It requires only a few lines of configuration within your GitHub Actions workflow file. This minimal setup means teams can implement this critical security check without significant disruption to their existing development processes. The output is not just a grade but a tangible artifact—the CBOM—that can be used for further analysis, reporting, and remediation planning.
Understanding Your Cryptographic Bill of Materials (CBOM)
A Cryptographic Bill of Materials (CBOM) is akin to a software bill of materials (SBOM), but specifically focused on cryptographic algorithms, key sizes, and protocols. For a quantum-ready future, a CBOM should identify:
- Algorithms in use: Specifically noting classical algorithms like RSA and Elliptic Curve Cryptography (ECC) that are vulnerable to Shor's algorithm.
- Key lengths: For algorithms that may have quantum-resistant variants, the key length is critical.
- Protocols: Identifying protocols that rely on vulnerable primitives (e.g., older TLS versions).
- Dependencies: Pinpointing which libraries or components are responsible for the cryptographic operations.
The GitHub Action automates the generation of this CBOM in the CycloneDX 1.6 format. This standard ensures interoperability with other security tools and compliance frameworks. By having this detailed inventory, development teams can proactively identify risks. For instance, a project might be graded 'C' because it uses RSA-2048, but the CBOM reveals that this is only for a non-critical internal logging service, whereas a 'D' grade might indicate RSA is used for signing user authentication tokens, a far more severe risk.
Implementing the Action in Your Workflow
Integrating this post-quantum readiness gate into your CI is remarkably simple. For GitHub Actions users, it typically involves adding a new step to an existing workflow file (e.g., `.github/workflows/main.yml`). The action can be called with minimal parameters, often just specifying the output directory for the CBOM. Here’s a conceptual example of how it might look:
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Post-Quantum Readiness Scan
uses: brandonsellam/pq-readiness-action@v1 # Example action name
with:
output-dir: "./cbom"
- name: Upload CBOM artifact
uses: actions/upload-artifact@v3
with:
name: cbom-report
path: ./cbom
This snippet demonstrates checking out the code, running the action, and then uploading the generated CBOM as a build artifact. This artifact can then be reviewed, stored, or fed into other compliance tools. The beauty of this approach is its low barrier to entry. It doesn't require specialized knowledge of quantum cryptography or complex setup procedures. The action abstracts away the complexities, providing developers with actionable insights in a familiar CI environment.
Beyond the Grade: Strategic Implications
While the grade and the CBOM are valuable immediate outputs, the true benefit lies in the strategic advantage they provide. Knowing your cryptographic inventory allows for informed decision-making regarding migration to post-quantum cryptography (PQC) standards. Organizations can prioritize remediation efforts based on the severity of identified risks and the criticality of the affected components.
The