feat: inventory X.509 certificates for CycloneDX CBOM output

[AAH20]

What would you like to be added?

Add an opt-in file cataloger that discovers public X.509 certificates in container images and filesystems and represents them as cryptographic assets in CycloneDX 1.6+ output.

A possible initial scope:

• recognize PEM and DER encoded X.509 certificates, including PEM bundles
• parse with Go's crypto/x509 and encoding/pem
• record the certificate fingerprint, subject, issuer, serial number, validity period, public-key algorithm and size/curve, signature algorithm, key usage, extended key usage, CA flag, and source locations
• use a stable certificate fingerprint for identity so the same certificate at multiple paths is deduplicated while its locations remain observable
• emit the assets using CycloneDX cryptoProperties for formats that support CBOM
• ignore private-key contents and avoid serializing secret material
• make malformed or unsupported certificates non-fatal
• keep output deterministic

I think the clean model is a first-class Syft cryptographic-asset collection populated by catalogers and consumed by format encoders, rather than making the CycloneDX encoder perform discovery. I would appreciate maintainer guidance on that boundary before implementing it.

The initial implementation would deliberately cover certificate inventory only. Discovery of private/public keys, SSH material, keystores, cryptographic libraries/API usage, and live TLS endpoints can be considered separately.

Why is this needed?

Organizations preparing for post-quantum cryptography migration first need a reliable inventory of where classical cryptography is deployed. Container images and filesystems commonly contain trust stores, service certificates, CA certificates, and application-specific certificate bundles, but this material is absent from conventional package-only SBOMs.

Syft already performs repeatable filesystem and image discovery and emits CycloneDX. Adding certificate inventory would let the same established scan produce the first useful slice of a Cryptography Bill of Materials, without requiring another inventory agent or a separate manual collection process.

This would support concrete workflows such as:

• identifying RSA and elliptic-curve certificate dependencies for migration planning
• finding expired, not-yet-valid, unexpectedly duplicated, or unusually long-lived certificates
• comparing cryptographic inventory across builds
• attaching a machine-readable CBOM to release evidence
• mapping certificates back to packages, files, and container layers in later iterations

This cataloger should report inventory facts, not label a certificate as a vulnerability or make a compliance determination.

Additional context

NIST's NCCoE migration guidance identifies cryptographic asset discovery and inventory as an early step in migration to post-quantum cryptography:

• https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/FAQ/
• https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc

CycloneDX 1.6 introduced CBOM support for algorithms, certificates, keys, protocols, and related cryptographic properties:

• https://cyclonedx.org/capabilities/cbom/
• https://cyclonedx.org/news/cyclonedx-v1.6-released/

Suggested acceptance tests include PEM, DER, certificate bundles, duplicate certificates at different paths, malformed input, CA and end-entity certificates, expired certificates, RSA/ECDSA/Ed25519 certificates, private-key files being ignored, and deterministic serialization.

I am willing to implement the initial certificate cataloger and tests once the preferred internal model and output boundary are agreed.

[CAOShurong]

Data points from walking the current code (bf82010f) that seem relevant to the boundary question:

1. The internal-model suggestion matches how every other file-artifact family already works. sbom.Artifacts (syft/sbom/sbom.go) is a set of map[file.Coordinates]T collections — FileMetadata, FileDigests, FileContents, FileLicenses, Executables, Unknowns — each populated by a cataloger task (internal/task/file_tasks.go) and consumed independently by each format encoder. A certificate collection there gives you "catalog once, encode many" for free; doing discovery inside the CycloneDX encoder would mean re-walking the filesystem during CDX encoding and leaving SPDX/syft-json unable to see the inventory at all.

2. On packages vs. a separate collection — there are working precedents for both, with different costs:

• Package-shaped (like the binary/ELF classifiers emit pkg.Package): shows up in every output format automatically, gets relationship handling and dedup from pkg.Collection, appears in table/text output. Cost: certificates aren't software packages, so you'd need the generic purl or a new purl-type discussion, and the --select-catalogers semantics get muddier.
• File-artifact-shaped (like FileLicenses): cleaner conceptually, keyed by Coordinates, but each format encoder has to opt in — today FileLicenses only surface where they're representable. For CBOM that's arguably correct behavior anyway.

My read: a file-artifact-shaped collection plus explicit opt-in in the CDX encoder is the lower-risk slice, with the option to promote to packages later if maintainers want certificates in every format.

3. One spec-version trap worth deciding up front. Syft's default CDX target is now 1.7 (DefaultVersion in syft/format/internal/cyclonedxutil/versions.go), which helps here because 1.7 added the fingerprint field on certificateProperties — exactly the stable identity this proposal needs for cross-path dedup. But note what cyclonedx-go v0.11.0's downgrade path does: convert() trims the 1.7-only subfields (fingerprint, certificateState, certificateExtensions, relatedCryptographicAssets, creation/activation/deactivation dates, ...) yet never removes cryptoProperties itself, even when targeting ≤1.5 documents where the element doesn't exist in the schema. So with -o cyclonedx-json@1.5, certificate components would survive into a document that fails strict schema validation unless syft gates the new content itself. Worth an explicit decision: drop certificate inventory below 1.6, or keep it and accept non-schema-strict output?

4. Determinism/dedup detail: fingerprinting the DER encoding with SHA-256 makes same-certificate-different-path dedup deterministic and independent of PEM wrapping/order; bundle files then decompose into N coordinates → 1 logical asset, which maps naturally onto the existing coordinate-keyed relationship model.

Happy to take a run at the initial slice once the maintainers weigh in on #2/#3 — those two decisions change where most of the code lands.

[AAH20]

Thanks for digging into this so thoroughly — the file-artifact-shaped collection + explicit per-format opt-in matches my read too, and the CDX downgrade gap you found (cryptoProperties surviving into <1.6 targets after the 1.7-only subfields get stripped) is a real bug independent of this proposal. On the version question, I'd lean toward gating certificate inventory below 1.6 rather than shipping non-schema-strict output. You've clearly done the deepest research on this already — happy to have you take the initial slice if you want it, otherwise I'll pick it up.