Add PQC Readiness Assessment Plugin

[anoncam]

Summary

This PR adds a new Post-Quantum Cryptography (PQC) Readiness Assessment Plugin that analyzes cryptographic assets in CBOMs for quantum vulnerability, calculates risk scores, tracks compliance timelines, and provides actionable migration guidance.

---

Motivation

Cryptographically-relevant quantum computers pose an existential threat to RSA, ECDSA, DH, and other public-key cryptographic algorithms currently protecting critical infrastructure. The "Harvest Now, Decrypt Later" (HNDL) attack vector means adversaries are already collecting encrypted data for future decryption.

With NIST finalizing PQC standards (FIPS 203/204/205) and compliance mandates like CNSA 2.0 setting migration deadlines as early as 2025, organizations need visibility into their quantum vulnerability surface. This plugin provides that visibility directly within the CBOM workflow.

---

Features

Quantum Vulnerability Classification

Classifies every cryptographic component by quantum threat model:

Status	Algorithms	Threat
quantum-vulnerable	RSA, ECDSA, DSA, DH, ECDH, Ed25519	Shor's algorithm (complete break)
quantum-partially-secure	AES-128/192, 3DES	Grover's algorithm (halved security)
quantum-resistant	SHA-256/384/512, SHA3, AES-256	Sufficient post-quantum security
hybrid-transitional	X25519Kyber768, ECDH+ML-KEM	PQC+classical hybrid schemes
quantum-safe	ML-KEM, ML-DSA, SLH-DSA	NIST PQC standards

PQC Algorithm Detection

Detects NIST-standardized PQC algorithms by OID and name pattern:

• ML-KEM (FIPS 203): Key encapsulation (Kyber)
• ML-DSA (FIPS 204): Digital signatures (Dilithium)
• SLH-DSA (FIPS 205): Stateless hash-based signatures (SPHINCS+)
• Hybrid schemes: X25519Kyber768, ECDH-P256+ML-KEM-768, etc.

HNDL Risk Scoring

Calculates "Harvest Now, Decrypt Later" risk on a 0-10 scale based on:

• Data sensitivity: Inferred from file paths, key usage, certificate properties
• Crypto lifetime: Certificate validity periods, key rotation indicators
• Vulnerability level: Complete break (1.0) vs. reduced security (0.5)
• Exposure level: Network-facing TLS vs. internal application crypto

Compliance Tracking

Checks against multiple compliance frameworks:

• CNSA 2.0: NSA timeline with category-specific deadlines (2025-2033)
• NIST SP 800-131A Rev 2: Algorithm deprecation status
• Custom deadlines: Configurable organizational migration policies

Migration Guidance

Provides actionable recommendations:

• Algorithm-specific PQC replacements (e.g., RSA → ML-KEM-768, ECDSA → ML-DSA-65)
• Migration path assessment (direct replacement vs. hybrid transition)
• Blocking factor identification (CA certificates, HSM dependencies, interoperability)

Filesystem Scanning

Actively scans for PQC configurations:

• OpenSSL configs with PQC cipher suites (Groups = kyber768)
• PQC-enabled TLS configurations in web servers
• PQC key files

---

Property Schema

Components are enriched with the following CycloneDX properties:

# Quantum Vulnerability
theia:pqc:quantum-status              = quantum-vulnerable | quantum-partially-secure | quantum-resistant | hybrid-transitional | quantum-safe
theia:pqc:quantum-threat              = shors-algorithm | grovers-algorithm | none
theia:pqc:classical-security-bits     = <integer>
theia:pqc:quantum-security-bits       = <integer>
theia:pqc:nist-quantum-level          = 0-5

# Risk Assessment
theia:pqc:hndl-risk-score             = 0.0-10.0
theia:pqc:hndl-risk-category          = critical | high | medium | low
theia:pqc:migration-priority          = critical | high | medium | low

# Migration Guidance  
theia:pqc:recommended-replacement     = ML-KEM-768,ML-DSA-65
theia:pqc:migration-path              = direct | hybrid-transition | requires-analysis

# Compliance
theia:pqc:compliance:overall-status   = compliant | non-compliant | transition-needed
theia:pqc:compliance:earliest-deadline = 2030-12-31
theia:pqc:compliance:cnsa-2.0:status  = compliant | non-compliant

---

Usage

# Enable the plugin
cbomkit-theia scan --plugins=pqcreadiness <target>

# Combine with other plugins
cbomkit-theia scan --plugins=certificates,pqcreadiness <target>

---

Files Added

scanner/plugins/pqcreadiness/
├── pqcreadiness.go              # Main plugin implementation
├── quantum_vulnerability.go     # Vulnerability classification logic
├── pqc_detection.go             # PQC algorithm detection
├── pqc_scanner.go               # Filesystem scanning for PQC configs
├── security_levels.go           # Security level calculations
├── risk_scoring.go              # HNDL risk scoring engine
├── migration.go                 # Migration guidance generation
├── compliance.go                # Compliance framework checking
├── config.go                    # Configuration management
├── database.go                  # Embedded database loading
├── algorithms.json              # Classical algorithm vulnerability DB
├── pqc_oids.json               # PQC OID and parameter database
└── pqcreadiness_test.go        # Unit tests (16 tests)

Modified:

• scanner/scanner.go: Register plugin constructor

Total: +4,272 lines across 14 files

---

Testing

$ go test ./scanner/plugins/pqcreadiness/... -v
=== RUN   TestNewPQCReadinessPlugin
=== RUN   TestClassifyQuantumVulnerability_RSA
=== RUN   TestClassifyQuantumVulnerability_ECDSA
=== RUN   TestClassifyQuantumVulnerability_AES
=== RUN   TestClassifyQuantumVulnerability_SHA
=== RUN   TestDetectPQCAlgorithm_ByOID
=== RUN   TestDetectPQCAlgorithm_ByName
=== RUN   TestCalculateSecurityLevel
=== RUN   TestRiskScoring
=== RUN   TestMigrationGuidance
=== RUN   TestComplianceTracking
=== RUN   TestNIST131ACompliance
=== RUN   TestAlgorithmDatabaseLoading
=== RUN   TestPQCOIDDatabaseLoading
PASS
ok      github.com/cbomkit/cbomkit-theia/scanner/plugins/pqcreadiness   0.993s

All existing tests continue to pass.

---

Example Output

A vulnerable RSA certificate component after processing:

{
  "type": "cryptographic-asset",
  "name": "example.com",
  "cryptoProperties": {
    "assetType": "certificate",
    "algorithmProperties": {
      "parameterSetIdentifier": "2048"
    }
  },
  "properties": [
    {"name": "theia:pqc:quantum-status", "value": "quantum-vulnerable"},
    {"name": "theia:pqc:quantum-threat", "value": "shors-algorithm"},
    {"name": "theia:pqc:classical-security-bits", "value": "112"},
    {"name": "theia:pqc:quantum-security-bits", "value": "0"},
    {"name": "theia:pqc:hndl-risk-score", "value": "7.8"},
    {"name": "theia:pqc:hndl-risk-category", "value": "high"},
    {"name": "theia:pqc:recommended-replacement", "value": "ML-KEM-768,ML-DSA-65"},
    {"name": "theia:pqc:migration-path", "value": "hybrid-transition"},
    {"name": "theia:pqc:compliance:cnsa-2.0:status", "value": "non-compliant"},
    {"name": "theia:pqc:compliance:cnsa-2.0:deadline", "value": "2030-12-31"}
  ]
}

---

Breaking Changes

None. This is a new opt-in plugin that does not affect existing functionality.

---

Future Enhancements

• Integration with certificate transparency logs for PQC certificate detection
• Support for additional PQC algorithms (FN-DSA/Falcon when standardized)
• Configurable risk weight profiles for different industries
• HTML/PDF report generation for executive summaries

---

References

• NIST Post-Quantum Cryptography
• FIPS 203 (ML-KEM)
• FIPS 204 (ML-DSA)
• FIPS 205 (SLH-DSA)
• NSA CNSA 2.0
• NIST SP 800-131A Rev 2

[san-zrl]

Hi @anoncam,

Thanks again for the new PR. While it’s a natural extension to cbomkit-theia, I’m hesitant to accept it in its current form. Quantum-readiness of cryptographic assets remains an active area of research. Discussions around the quantum safety of specific algorithms are ongoing. For this reason, I’d prefer to keep the definition and evaluation of policies, such as quantum-readiness conditions, separate from the core functionality of cbomkit.

For this reason cbomkit (CBOM generation from scanning github repos) defines a compliance checking service interface. This service implementing this interface can be provided either by an external service instance or via a built-in default implementation. Both the default implementation and the existing external service (not part of our open-source repositories) already perform quantum-readiness checks for CBOMs. Merging your PR into cbomkit-theia would duplicate this functionality and could potentially lead to inconsistent results—something I’d like to avoid.

That said, your PQC-readiness check could be integrated as an implementation of the cbomkit compliance checking service interface. This approach would allow cbomkit and cbomkit-theia to rely on the same service, ensuring consistent results. Please have a look at the compliance packages in the cbomkit repository:

• domain
• usecases
• infrastructure
• presentation

I’m aware that your implementation and our service definition does not quite fit together yet. The cbomkit service makes use of location data that may not be available in cbomkit-theia. PQC-readiness result predicates also seem to differ. Feel free to extend the corresponding cbomkit code as you need to support this.

[anoncam]

Hi @anoncam,

Thanks again for the new PR. While it’s a natural extension to cbomkit-theia, I’m hesitant to accept it in its current form. Quantum-readiness of cryptographic assets remains an active area of research. Discussions around the quantum safety of specific algorithms are ongoing. For this reason, I’d prefer to keep the definition and evaluation of policies, such as quantum-readiness conditions, separate from the core functionality of cbomkit.

For this reason cbomkit (CBOM generation from scanning github repos) defines a compliance checking service interface. This service implementing this interface can be provided either by an external service instance or via a built-in default implementation. Both the default implementation and the existing external service (not part of our open-source repositories) already perform quantum-readiness checks for CBOMs. Merging your PR into cbomkit-theia would duplicate this functionality and could potentially lead to inconsistent results—something I’d like to avoid.

That said, your PQC-readiness check could be integrated as an implementation of the cbomkit compliance checking service interface. This approach would allow cbomkit and cbomkit-theia to rely on the same service, ensuring consistent results. Please have a look at the compliance packages in the cbomkit repository:

• domain
• usecases
• infrastructure
• presentation

I’m aware that your implementation and our service definition does not quite fit together yet. The cbomkit service makes use of location data that may not be available in cbomkit-theia. PQC-readiness result predicates also seem to differ. Feel free to extend the corresponding cbomkit code as you need to support this.

@san-zrl

Thank you for the detailed feedback and for pointing me to the compliance service architecture. After reviewing the cbomkit compliance packages, I understand your vision for keeping policy evaluation separate and ensuring consistency across both tools.

I see several paths forward and would like your guidance on the preferred approach:

Option 1: Standalone PQC Compliance Service (Recommended)

Create a standalone service (potentially in Go, leveraging my existing implementation) that:

• Implements the cbomkit compliance service REST API contract
• Can be deployed as an external service (similar to your ext-compliance deployment model)
• Provides the sophisticated PQC readiness analysis from my PR
• Can be consumed by both cbomkit and cbomkit-theia

Benefits:

• Maintains language choice (Go) and existing sophisticated logic
• Follows your ext-compliance architecture pattern
• Both tools use identical compliance logic via API
• No duplication of functionality

Questions:

• Would you accept this as a new repository under cbomkit (e.g., cbomkit-pqc-compliance-service)?
• Should it implement the exact REST API from /api/v1/compliance/check?

Option 2: Port to Java and Extend Interface

Port my Go implementation to Java and:

• Add it to cbomkit as an enhanced compliance service implementation
• Extend the IComplianceService interface to support richer result types (beyond simple compliance levels)
• Make cbomkit-theia call this service via API

Benefits:

• Single language ecosystem (Java)
• Integrated with cbomkit directly

Challenges:

• Significant porting effort (~4,272 lines of Go → Java)
• May require extending your compliance interface
• Loss of my existing implementation's testing and validation

Option 3: Go Library + Adapter Pattern

Create a Go library from my implementation that:

• cbomkit-theia uses directly (as a refined version of my current plugin)
• Expose as a REST service that cbomkit can call
• Provide an adapter in cbomkit that translates the rich results to your ComplianceLevel model

---

My Specific Questions

1. Compliance Result Richness

My implementation provides 30+ properties per asset (risk scores, HNDL factors, compliance deadlines, migration paths). The current IComplianceService returns simple compliance levels. Should I:

• Map my rich analysis to simple levels (losing detail)?
• Propose extending the interface to support detailed results?
• Return detailed results via a custom property structure?

2. Location Data

You mentioned location data may not be available in cbomkit-theia. Can you clarify:

• What location data does cbomkit provide?
• Is this file path, line numbers, or something else?
• Should my service gracefully handle missing location data?

3. Policy Identifiers

My current implementation supports multiple compliance frameworks (CNSA 2.0, NIST SP 800-131A, custom). Should these be:

• Separate policy identifiers (e.g., pqc_cnsa_2_0, pqc_nist_800_131a)?
• Combined under a single pqc_readiness policy?
• Configurable via compliance service configuration?

4. Timeline and Approach

Would you prefer:

• A standalone service (Option 1) that I can develop independently and submit for review?
• Close collaboration on extending cbomkit's compliance interface first?
• Incremental PRs (interface extension → implementation → integration)?

---

I'm committed to aligning with your architecture and ensuring consistent results across both tools. The sophistication of my PQC analysis (HNDL risk scoring, multi-framework compliance, migration guidance) adds significant value beyond simple quantum-safe checking, and I'd like to preserve that while fitting your design.

What's your preferred path forward?

[san-zrl]

Hi @anoncam,

Thanks a lot for your friendly response. I appreciate your commitment to contribute to the project. Before diving into the details, just a quick update: CBOMKit has recently become a PQCA project. We now have a Technical Steering Committee (TSC), and there’s a bi-weekly TSC call on Tuesdays at 4 PM CET. If the time works for you, I’d like to invite you to join the next call on January 13, 2026. You can find details on https://pqca.org/calendar.

Regarding the design options, I also prefer Option 1 – the stand-alone PQC Compliance Service. It keeps things nicely modular and reduces implementation effort compared to Options 2 and 3. The service could be invoked from cbomkit-theia when scanning an image or from cbomkit when scanning a GitHub repository. To support both, it would need to implement an extended version of /api/v1/compliance/check. Developing this in a separate repo is a great idea — I’ll request the creation of cbomkit-pqc-compliance-service for that.

On your specific questions:

1. Compliance Result Richness: Please go ahead and propose an extended version of the interface to include more detailed results. Ideally, the results should be mappable to the current simpler version so we can keep the cbomkit UI as is for now and add richer data later. Currently, the only way to perform a PQC-readiness analysis on the cbomkit-theia output is to load it into the cbomkit viewer. With the service we could do this directly. In my opinion it is still an open question where to store the results of this analysis when called from cbomkit-theia. Strictly specking, the CBOM standard is not a good place for this as we have to squeeze the analysis result into the properties. An alternative would be to write a separate document in a format of our choice.
2. Location Data: This includes file paths, line numbers, offsets, and other context that cbomkit collects when scanning source code (see CycloneDX 1.5 Evidence Occurrences). Looking at the BasicQuantumSafeComplianceService implementation, it seems that this data is not used at all. Since findings from cbomkit-theia may not include this detail, it’s fine for the service to handle missing fields gracefully.
3. Policy Identifiers: Configurable identifiers would be great — /api/v1/compliance/check already accepts a policyIdentifier argument.
4. Timeline and Approach: As mentioned above, I’d prefer the stand-alone service. You could develop independently of other activities and submit at a convenient point in time.

Looking forward to your proposal.