crypto scanner: filesystem/repo targets and ML-KEM/SLH-DSA entries

[Johnbjoseph-cybersec]

I came to propose a CBOM scanner for post-quantum migration and found it already exists
(#10962, #10933, docs/guide/scanner/crypto.md). So this is only about gaps. Please say if
any of it is unwelcome.

1. Targets. The docs say crypto is image only. As far as I can read the code, app.go adds the
   scanner value to the image command only, and artifact/local/fs.go does not copy CryptoAssets
   into the blob. Certificates and keys committed to repos are an obvious source for a PQC
   inventory. Proposal: allow --scanners crypto on fs, rootfs and repo, with occurrences carrying
   a path and no layer (the CycloneDX encoder already leaves the layer out when there is none).
   Is image-only a deliberate boundary or just phase 1? For repos, should testdata paths be
   left to --skip-dirs, as for images?

2. ML-DSA is catalogued, but ML-KEM and SLH-DSA are not. On the question in Add cryptographic asset inventory for container images #10962 about
   ML-KEM keys stored as files: RFC 9935 defines X.509 certificates with ML-KEM subject public
   keys and PKCS#8 private key formats; RFC 9909 does the same for SLH-DSA. Go 1.27 adds only
   ML-DSA to crypto/x509. Proposal: catalog entries using the OID fallback, with kem and
   signature primitives, family names and patterns from the CycloneDX 1.7 definitions, fixed key
   sizes, and NIST categories as in NIST IR 8547 Tables 3 and 5. No new dependency, fixtures
   built in code. Should HashSLH-DSA OIDs be included, given RFC 9909 allows them in X.509?

3. Question only, no code. IR 8547 (final, October 2026) deprecates RSA, ECDSA, EdDSA and
   DH-based key establishment after 2030 and disallows them after 2035. The CBOM already carries
   nistQuantumSecurityLevel 0, so consumers can filter. Would you want a finding or a summary
   count for quantum-vulnerable assets, or is that out of scope given that a base image holds
   hundreds of public roots? I will not send code for this without your answer.

I am not proposing library detection, config or TLS analysis, or KeyUsage purpose resolution
(your phase 2 in #10933).

I can implement 1 and 2 as two small PRs. Would you accept them, and in what shape?

John B Joseph, Co-founder & CPTO, Purplecop Security

[nikpivkin]

Hi @Johnbjoseph-cybersec !

1. Crypto scanning stays image only for now. We are not ready to extend it to fs, rootfs and repo yet, so we will not take this part at the moment.
2. Yes to ML-KEM and SLH-DSA, in one PR. Certificates with these keys already reach the report, but only by their OID. So the PR needs catalog entries only, with no parser changes. A few details:

• Key size is the length of the encoded public key, as for ML-DSA.
• No classical security level, as for ML-DSA. NIST categories come from FIPS 203 and FIPS 205.
• Include HashSLH-DSA. RFC 9909 allows these OIDs in X.509. HashML-DSA has no entries because RFC 9881 forbids it.
• Build fixtures in code, as the existing tests do.

Private keys of these algorithms are still skipped, because Go cannot parse them. That needs a PKCS#8 fallback, which is a separate change. It was already offered in #10962, so check there first to avoid duplicate work.

3. We do not want a finding for this. RSA and EC keys are in almost every image, so it would fire hundreds of times per scan. Consumers can already filter by nistQuantumSecurityLevel.

[Johnbjoseph-cybersec]

Thanks, that's clear. The ML-KEM and SLH-DSA catalog entries, HashSLH-DSA included, are in #11635: key size from the encoded public key, NIST categories from FIPS 203 and 205, no classical level, fixtures built in code. Private keys and the fs/repo targets stay out, and there's no finding.

[nikpivkin]

I opened #11639 for ML-KEM and SLH-DSA.