Add cryptographic asset inventory for container images

Description

Add opt-in cryptographic asset inventory to Trivy image scans.

When enabled, Trivy discovers certificates, keys, and their algorithms in the image filesystem and adds them to CycloneDX 1.7 output as cryptographic-asset components. These components are included in the same BOM as the existing software components rather than being emitted as a separate CBOM document.

The inventory reports that a cryptographic asset is present and where it was found. It does not claim that the asset is actively used or evaluate whether it is secure.

Supported inventory

X.509 certificates

Support X.509 certificates in PEM and DER encoding, including common .pem, .der, .crt, and .cer files.

Record certificate metadata including:

• Subject and issuer
• Serial number
• Validity period
• Key usage, extended key usage, subject alternative names, and basic constraints
• SHA-256 fingerprint
• Certificate format
• Signature algorithm
• Subject public key

A file may contain multiple PEM blocks, such as a certificate chain, CA bundle, or combined certificate and key file. Every valid block must be inventoried. A malformed block must not prevent later valid blocks in the same file from being processed.

Keys

Support public and private keys in the formats that Go's standard library can parse:

• PKCS#1
• PKCS#8
• SEC1
• PKIX public keys
• PEM and DER encodings

Record metadata such as:

• Public or private key type
• Key size
• Elliptic curve
• Encoding and format
• Associated algorithm

Private-key material must never be included in the BOM.

Encrypted PKCS#8 containers should be inventoried as opaque encrypted material. Properties inside the encrypted container, such as the key algorithm and key size, are unavailable without decryption and should remain unset. Encryption must not be represented using the CycloneDX key lifecycle state, because encrypted is not a valid lifecycle state.

Algorithms

Create algorithm components for the algorithms associated with certificates and keys.

The initial inventory should cover the straightforward public-key and certificate-signature algorithms identified by Go's crypto/x509, including RSA, DSA, EC, Ed25519, DSA-with-SHA1/SHA256, ECDSA-with-SHA1, and MD5-with-RSA.

Generic SubjectPublicKeyInfo identifiers such as rsaEncryption and id-ecPublicKey do not always identify whether a key is used for signing, encryption, or key agreement. When the purpose cannot be determined reliably, report the algorithm with an unknown primitive rather than assigning an incorrect one.

An unknown OID must not fail the scan. It should produce a minimal algorithm component containing the OID and an unknown primitive.

Inventory behavior

• The inventory is enabled explicitly through the crypto scanner.
• It is supported for image targets with CycloneDX output.
• System and application cryptographic assets are both included. Their paths and image layers allow report consumers to distinguish and filter them.
• Certificates, keys, and algorithms are represented as separate components and connected through relatedCryptographicAssets.
• Identical assets found at multiple paths or in multiple layers are represented by one component with multiple occurrences.
• Each occurrence records the source path and image layer.
• Component identifiers are stable and derived from the asset identity and relevant algorithm parameters.
• Generated values must conform to the CycloneDX 1.7 schema and vocabulary.

Out of scope

The following are not part of this issue:

• Source-code, binary, or configuration-file analysis
• Determining whether an inventoried asset is actively used
• Weak or deprecated cryptography detection
• Certificate expiration findings or other policy evaluation
• classicalSecurityLevel and nistQuantumSecurityLevel calculation
• RSA-PSS, which requires parameter-aware handling to distinguish variants sharing the same OID
• Resolving ambiguous RSA or EC key purposes from usage context
• Extracting the KDF, PRF, cipher, or iteration count protecting an encrypted private key
• OpenSSH, PKCS#12, JKS, CRL, and OpenPGP formats
• Linking an asset to the package that introduced it
• Built-in filtering of system trust stores or test paths

These capabilities can be handled in follow-up issues on top of the inventory model.

Acceptance criteria

• trivy image --scanners crypto --format cyclonedx includes discovered cryptographic assets in the generated BOM.
• Supported certificate and key formats are represented with the expected metadata and relationships.
• Every valid PEM block in a multi-block file is inventoried.
• A malformed or unsupported cryptographic object does not abort the image scan.
• Duplicate assets found at different paths or layers produce one component with multiple occurrences.
• Private-key values are never serialized.
• Encrypted private-key containers do not use an invalid CycloneDX lifecycle state.
• Unknown OIDs do not cause the scan to fail.
• The generated BOM validates against the CycloneDX 1.7 schema.
• Automated tests cover certificates, supported key formats, bundles, duplicate occurrences, encrypted key containers, malformed blocks, and unknown algorithms.

Design discussion

The detailed design, implementation considerations, and follow-up ideas are documented in #10933.