The best time to catch a cryptographic vulnerability is before it reaches production. By integrating PQC policy checks into your CI/CD pipeline, you can enforce cryptographic standards automatically on every commit — catching quantum-vulnerable algorithm usage, weak key lengths, and policy violations before they ever leave the developer's machine.
Why Shift-Left Crypto Policy
Most organizations discover cryptographic issues through periodic audits — quarterly or annual reviews that produce a report, generate tickets, and slowly get addressed over weeks or months. This reactive approach has two fundamental problems:
- New vulnerable code is introduced faster than audits can catch it. Between audits, developers continue using whatever cryptographic APIs and configurations are familiar, often defaulting to quantum-vulnerable algorithms.
- Remediation is expensive after the fact. Changing a cryptographic algorithm in production code that has been running for months requires testing, coordination, and careful rollout. Catching it before merge is a one-line fix.
What to Check
Pipeline crypto checks should validate several categories of cryptographic usage against your organization's policy:
Algorithm Usage
Scan source code for usage of deprecated or quantum-vulnerable algorithms. This includes direct API calls (e.g., RSA.generate(2048) in Python or KeyPairGenerator.getInstance("RSA") in Java) as well as string constants that specify algorithm names in configuration files, connection strings, and infrastructure-as-code templates.
Key Lengths and Parameters
Even within approved algorithms, key lengths matter. Your policy might allow AES but require 256-bit keys. The scanner should flag AES-128 usage if your policy mandates AES-256. Similarly, RSA key lengths below 3072 bits (if RSA is still temporarily permitted) should be flagged.
Certificate Configurations
TLS configurations embedded in code or config files should be validated against your certificate policy. This includes minimum TLS versions (1.2 or 1.3), allowed cipher suites, certificate pinning configurations, and HSTS settings.
Protocol Versions
Connection configurations for databases, message queues, API endpoints, and other services should use current protocol versions. The scanner should flag any hardcoded references to deprecated protocol versions (SSLv3, TLS 1.0, TLS 1.1) and encourage protocol negotiation over hardcoded versions.
Implementation Approach
Rolling out crypto policy enforcement requires a phased approach to avoid disrupting development velocity:
Phase 1: Detection Only (Weeks 1-4)
Start in detection-only mode. The scanner runs on every PR and reports findings as comments but doesn't block merges. This gives you a baseline of your current crypto posture and lets teams start seeing the types of issues that will eventually be enforced. During this phase, collect metrics on finding frequency, affected repositories, and the most common violation types.
Phase 2: Soft Enforcement (Weeks 5-8)
Begin blocking merges for critical findings (known-broken algorithms like MD5 for integrity, DES, RC4) while leaving warnings for quantum-vulnerable but currently-secure algorithms. This addresses the most urgent issues without overwhelming teams.
Phase 3: Full Enforcement (Weeks 9+)
Gradually expand enforcement to cover all policy violations. Provide teams with migration guides, code examples, and approved alternative libraries for each flagged pattern. The goal is to make the right thing easy — developers should be able to fix a finding in minutes, not hours.
Measuring Success
Track these metrics to gauge the effectiveness of your pipeline crypto checks:
- Time to detection: How quickly are new crypto issues identified after introduction?
- Fix rate: What percentage of findings are resolved within the sprint they're discovered?
- New violation rate: Is the rate of new violations decreasing over time as teams internalize the policy?
- Coverage: What percentage of your repositories have crypto scanning enabled?