CBOM: design & implementation plan (crypto files)

[nikpivkin]

1. Summary

Idea. Add CBOM (Cryptography Bill of Materials) generation to Trivy: while scanning an image, find cryptographic files (certificates, keys, and — later — keystores), extract their properties, and add them as cryptographic-asset components to the SBOM. Every asset is tagged with its layer, so system cryptography (base image, trusted roots, OS packages) is separated from the user's, and the report consumer filters for their own task.

Phase 1. A new crypto scanner, enabled manually and working only when scanning an image with CycloneDX output, plus an X.509 analyzer that extracts certificates and keys (PEM/DER), with no new dependencies — stdlib only (crypto/x509 + encoding/pem).

Out of phase 1 (section 10): the remaining formats (PKCS#12, JKS, OpenSSH, OpenPGP, CRL) — the same inventory extended by a new analyzer; detection of weak and deprecated cryptography.

2. Scope

In scope: inventory of cryptographic files — certificates, keystores, keys. Covers 3 of the 4 CycloneDX asset types: algorithm, certificate, related-crypto-material.

Out of scope:

• Source-code analysis (AST).
• Binary analysis.
• Config-file analysis (nginx, apache, etc.).

The inventory records that an asset is present and where it came from, but not the fact of its use.

3. File selection and detection

Formats

Certificates

• Format: X.509
• Encodings: DER (binary) / PEM (base64 + headers)
• Extensions: .der, .crt, .cer, .pem

Keys

• Formats:
  • PKCS#1 (RSA)
  • PKCS#8 — a universal container; the algorithm is given by an OID inside: RSA, EC, Ed25519, etc.
  • SEC1 (EC)
• Encodings: DER / PEM
• Extensions: .key, .der, .pem

Detection strategy

1. By extension (Required) — a cheap pre-filter without reading content: .pem, .der, .crt, .cer, .key.
2. By content (Analyze):
   • encoding — text -----BEGIN present → PEM, otherwise DER;
   • type — for PEM by the label, for DER by trying parsers.

TODO: check whether DER parsing is justified for private keys. Presumably (needs verification on real images) keys on disk are almost always PEM (openssl writes PEM by default; .key files are usually PEM), and DER for keys is rare — unlike certificates (.der/.cer). If confirmed, the DER path can be limited to certificates and skip the trial parsing for keys.

PEM labels:

-----BEGIN CERTIFICATE-----     → certificate
-----BEGIN PRIVATE KEY-----     → key (PKCS#8)
-----BEGIN RSA PRIVATE KEY----- → key (PKCS#1)
-----BEGIN EC PRIVATE KEY-----  → key (SEC1, EC)
-----BEGIN PUBLIC KEY-----      → public key (PKIX)
-----BEGIN ENCRYPTED PRIVATE KEY----- → encrypted key (PKCS#8)

Specifications

• PEM wrappers and -----BEGIN …----- labels: RFC 7468
• X.509 certificates and SubjectPublicKeyInfo: RFC 5280
• Keys: PKCS#1/RSA — RFC 8017; PKCS#8 — RFC 5958; EC/SEC1 — RFC 5915; EC SubjectPublicKeyInfo and namedCurve — RFC 5480

4. Parsing and data extraction

Analyzer model

Three layers, in processing order raw bytes → object → CryptoAsset:

• Analyzer — implements the analyzer.analyzer interface: Required selects a file by extension without reading content; Analyze reads the content and returns an AnalysisResult with crypto assets.
• Parser — works with raw bytes: strips the encoding (PEM wrapper, DER), obtains parsed objects, and runs them through the extractors. Specific to each analyzer.
• Extractor — works with an already-parsed object (*x509.Certificate, etc.): moves its fields into the CryptoAsset model (subject, algorithm, key size, curve, validity period). Shared, reused across analyzers. The certificate extractor returns one or more components: the certificate itself and, when expanded, the public key, the key algorithm, and the signature algorithm.

To cut boilerplate, a shared Parser type (Parse(ctx, r) ([]CryptoAsset, error)) and a crypto.Analyze(input, parser) function wrapping the parser call in an AnalysisResult can be introduced, by analogy with analyzer/language/analyze.go.

Analyzers

x509 — X.509 material in PEM or DER encoding.

• Required: .pem, .der, .crt, .cer, .key.
• Analyze: detects the encoding by content (text -----BEGIN...----- → PEM, otherwise DER), strips the PEM wrapper, decodes ASN.1, and dispatches to the Certificate or Key extractor by header/structure.
• Covers: certificates and keys (PKCS#1/PKCS#8/SEC1, public PKIX).
• Library: crypto/x509 + encoding/pem.

Files with multiple blocks (chains, bundles, cert+key)

A single file is 0..N objects, not one: a certificate chain, a CA bundle (hundreds of CERTIFICATE blocks), a certificate and key together. The parser walks every block via the rest that pem.Decode returns, calling the extractor on each object; a corrupt block is logged and skipped without aborting the rest. For DER a file usually contains a single ASN.1 object.

func parsePEM(data []byte) (assets []CryptoAsset) {
    for {
        var block *pem.Block
        block, data = pem.Decode(data) // data ← rest: the tail after the block
        if block == nil {
            break // no valid blocks left
        }
        a, err := extractBlock(block) // by block.Type → certificate / key
        if err != nil {
            log.Debug("skip crypto block", log.String("type", block.Type), log.Err(err))
            continue // one broken block does not lose the others (e.g. in a CA bundle)
        }
        assets = append(assets, a...)
    }
    return assets
}

crypto/x509.ParseCertificate rejects some certificates that do not conform to the spec — we skip those: for example, EC with explicit parameters (stdlib supports only namedCurve). DSA is a special case: stdlib parses a DSA public key (PublicKeyAlgorithm == DSA, "Only supported for parsing"); only verifying its signature is unsupported. So we inventory a DSA key like any other — the fact that a DSA signature cannot be verified has nothing to do with parsing the key.

Shared extractors

The Certificate and Key extractors live in the shared pkg/crypto package and are used by the x509 analyzer (the extracted fields themselves are in the next section).

Extracted data

Certificate → certificateProperties

• subjectName, issuerName
• notValidBefore, notValidAfter
• serialNumber
• relatedCryptographicAssets — references to two neighboring components: the signature algorithm and its own public key.
• certificateFormat (X.509)
• certificateExtensions (EKU, KeyUsage, SAN, Basic Constraints)
• fingerprint (SHA-256 of DER)

The signature algorithm and the public key are emitted as separate assets — that is what relatedCryptographicAssets points to.

Key (PKCS#1/PKCS#8/SEC1) → relatedCryptoMaterialProperties

• type (private-key / public-key)
• relatedCryptographicAssets: a reference to the key algorithm
• size (key length): RSA — modulus length, EC — from the curve, EdDSA — fixed
• format (PEM/DER)
• state (whether encrypted)

Sensitive data

Only metadata is extracted from private keys (type, size, curve, format, whether encrypted) — the secret material never reaches the CBOM. The Value field of relatedCryptoMaterialProperties is not filled for private keys (for public keys it is allowed). Certificates and public keys are not sensitive.

Encrypted private keys

The -----BEGIN ENCRYPTED PRIVATE KEY----- label is an EncryptedPrivateKeyInfo (RFC 5958 §3): the key is encrypted with a password (KDF + cipher). We cannot decrypt it — stdlib has no EncryptedPrivateKeyInfo decoder — so in phase 1 we inventory it as-is.

Because of the encryption, the SPKI is unavailable, so the usual sha256(SPKI) cannot be computed as the ID. Instead we take the hash of the DER of the encrypted container itself:

ID = crypto:related-crypto-material:private:enc:<sha256(EncryptedPrivateKeyInfo)>

(see "Identity scheme" in section 6). This ID identifies a specific encrypted blob, not the key inside it: the same key re-encrypted with a different salt gets a different ID, and it can no longer be linked to its certificate or public key.

The key's own properties — size, curve, algorithm — are inside the encrypted material and unavailable, so in phase 1 an encrypted key is inventoried as a related-crypto-material asset with type: private-key and state: encrypted only.

Extracting what protects the key (securedBy: the PBES2 scheme — KDF, PRF, cipher, iteration count) is deferred to phase 2 (section 10): it is a strength signal rather than inventory, and it is the only part that would require hand-rolled ASN.1 below stdlib's typed API. In phase 1 SecuredBy stays nil.

algorithmProperties — assembled from an OID and a registry

An algorithm has no parsing source of its own. In X.509/PKCS it never exists as a standalone object — only as an AlgorithmIdentifier inside a certificate or key: an OID plus optional parameters. There is no name, no indication of whether it is a signature or a hash, no family, no strength level in bytes — an OID is a pure identifier. So the algorithm component is derived and assembled from three sources:

• OID from the AlgorithmIdentifier — the component's identity;
• descriptive part (name, primitive, family, hash, strength levels) — from the OID → properties registry (pkg/crypto/algorithm.go), a static table; none of this is in the file itself;
• numeric key parameters — from the parsed object: the RSA size is taken from the modulus length, the EC curve from the OID in parameters.

From these sources the extractor fills algorithmProperties:

• primitive (signature, encryption, hash, etc.);
• parameterSetIdentifier;
• ellipticCurve — a value from the closed CycloneDX ellipticCurvesEnum (cryptography-defs.schema.json), with a namespace prefix (nist/P-256, nist/P-384, nist/P-521, other/Ed25519, other/Ed448); taken from the registry.

classicalSecurityLevel and nistQuantumSecurityLevel are not filled in phase 1 — these are strength estimates, not identity: there is no official source for them (they are not in cryptography-defs.json either), and classicalSecurityLevel additionally depends on key size (RSA-2048 ≈ 112, RSA-3072 ≈ 128), i.e. it requires a (family, size/curve) → level lookup table. Both fields and that table are added in phase 2 together with weak-crypto detection (section 5); until then they are absent from AlgoProps as well.

An unknown OID does not abort parsing: the registry does not find it, and the component is created minimally — the OID itself plus primitive: unknown.

The finished algorithm becomes a separate component with ID = OID + normalized parameters when those change the asset (RSA size, EC curve — see "Identity scheme" in section 6). A relatedCryptographicAssets{type:"algorithm", ref} reference points to it from the Certificate/Key, and identical (OID, parameters) are merged into one component.

Algorithm registry (pkg/crypto/algorithm.go)

The OID → properties registry is a static table and the only source of the descriptive part of an algorithm component. It has two layers with different sources of truth:

• Our layer (OID → family). Links an OID from an AlgorithmIdentifier to an algorithm family and defines where to take paramSet from. CycloneDX does not provide this: the official data (see below) contains no OIDs at all, while our identity is built precisely on the OID. Maintained by hand.

• Official layer. The descriptive fields tied to a family are extracted from the official CycloneDX file cryptography-defs.json:

  • family → {primitive, name pattern, standards} from the algorithms array;
  • curve name → ellipticCurvesEnum value from the ellipticCurves array (name + namespace fields).

  The extraction is done by a separate mage target, modeled on the SPDX license generation (magefiles/spdx.go, target SPDX.UpdateLicenseEntries): the target downloads cryptography-defs.json, selects the needed fields, and writes a committed data file into pkg/crypto that is wired in via //go:embed and read at startup. Generation instead of manual entry guarantees that primitive and curve values match the schema enum and do not drift from it on updates.

Record structure

// algoEntry — one registry record. Our layer manually sets, per OID, its
// family and the rule for where to take paramSet from; the remaining fields
// (primitive, name template) are filled by Family from the official layer
// (cryptography-defs.json).
type algoEntry struct {
    OID       string      // lookup key, from AlgorithmIdentifier
    Family    string      // CycloneDX family: "RSASSA-PKCS1", "ECDSA", "EdDSA", ...
    Primitive string      // official layer by Family: "signature" | "pke" | "hash" | ...
    Hash      string      // hash of a composite signature, e.g. "SHA-256"; empty if N/A
    ParamFrom paramSource // where to take paramSet from: rsaModulusBits | ecNamedCurve | none
}

// paramSource — which property of the parsed key yields paramSet. Filled
// manually in the registry; only key algorithms get a non-none value.
type paramSource int

const (
    none           paramSource = iota // paramSet is empty (EdDSA — parameter already in the OID; signatures)
    rsaModulusBits                    // RSA modulus length → "2048"
    ecNamedCurve                      // key curve via curveEnum → "nist/P-256"
)

// curveEnum — curve name from stdlib (elliptic.Curve.Params().Name) →
// ellipticCurvesEnum value. The key matches the name field of the official
// file, so the raw namedCurve OID is not needed: stdlib does not expose it,
// resolving it to an elliptic.Curve. Values come from the embedded file
// generated by the mage target (see above).
var curveEnum = map[string]string{
    "P-256": "nist/P-256",
    "P-384": "nist/P-384",
    "P-521": "nist/P-521",
}

Matching (OID + parsed object → algorithm component)

1. The OID is looked up in the table. Found — take Family, Primitive, Hash. id-ecPublicKey by itself does not define the key's purpose (signing or agreement), so primitive stays unknown and the curve is kept; ECDSA is not assigned without evidence of purpose. Determining ECDSA/ECDH via KeyUsage is deferred to phase 2 (section 10).
2. paramSet by ParamFrom: rsaModulusBits — the modulus size from the key ("2048", "4096"); ecNamedCurve — the enum curve value from curveEnum by pub.Curve.Params().Name (stdlib does not expose the raw namedCurve OID — it resolves it to an elliptic.Curve); none — empty (the parameter is already in the OID itself, as with EdDSA).
3. ID = crypto:algorithm:<OID>[:<paramSet>] (section 6). paramSet distinguishes by strength only those components whose parameter lies outside the OID (RSA size, EC curve); a signature OID (ecdsa-with-SHA256, etc.) already distinguishes the hash itself, so its paramSet is empty.
4. Name is assembled from the family template in the official layer with known parts substituted (e.g. RSA-2048, ECDSA-P-256-SHA-256).

Unknown OID

Parsing is not aborted: the OID is not found in the table — the component is created minimally (the OID itself, primitive: unknown), paramSet empty. The same for a curve absent from curveEnum: the ellipticCurve field stays empty rather than being filled with a value invalid for the enum.

Initial set (phase 1)

Public-key algorithms (SubjectPublicKeyInfo):

OID	Family	primitive	paramSet
1.2.840.113549.1.1.1	RSA	pke	modulus size
1.2.840.10040.4.1	DSA	signature	size (p length)
1.2.840.10045.2.1	—	unknown	curve
1.3.101.112	EdDSA	signature	— (in the OID)

The set corresponds to the four x509.PublicKeyAlgorithm values stdlib recognizes (RSA, DSA, ECDSA, Ed25519). Ed448 (1.3.101.113) is out of the set — Go does not support it.

Signature algorithms (Certificate.SignatureAlgorithm):

OID	Family	Hash	paramSet
1.2.840.113549.1.1.5	RSASSA-PKCS1	SHA-1	—
1.2.840.113549.1.1.11	RSASSA-PKCS1	SHA-256	—
1.2.840.113549.1.1.12	RSASSA-PKCS1	SHA-384	—
1.2.840.113549.1.1.13	RSASSA-PKCS1	SHA-512	—
1.2.840.10045.4.3.2	ECDSA	SHA-256	—
1.2.840.10045.4.3.3	ECDSA	SHA-384	—
1.2.840.10045.4.3.4	ECDSA	SHA-512	—
1.3.101.112	EdDSA	—	—

Named curves (curveEnum): nist/P-256, nist/P-384, nist/P-521.

The set covers the material that stdlib (crypto/x509) actually parses in phase 1; extending it comes down to adding rows to the tables.

5. Weak and deprecated crypto detection

Deferred out of phase 1. This also includes the classicalSecurityLevel and nistQuantumSecurityLevel fields (section 4) and the (family, size/curve) → strength level lookup table on which they and the detection rules (SHA-1, RSA < 2048, weak curves, expired certificates) are built.

6. Internal data model

The analyzer returns []CryptoAsset — an intermediate representation that is then translated into a BOM component (section 8). One file yields several assets (certificate + algorithm(s) + key) that are merged by ID at the encoding stage. The type:

// pkg/fanal/types — neutral types, with no dependency on cyclonedx-go
type CryptoAsset struct {
    ID       string      // stable id from content (see "Identity scheme" below)
    FilePath string      // where found (→ occurrence); one ID may have many paths
    Layer    Layer       // the file's layer (set by the applier); at encode time → occurrence, not component
    Type     string      // certificate | related-crypto-material | algorithm
    Name     string      // human-readable name (certificate subject / "RSA-2048")
    Props    CryptoProps // neutral asset properties
}

// CryptoProps holds the subset of fields Trivy actually extracts (section 4).
type CryptoProps struct {
    Certificate *CertProps       // for type=certificate
    Key         *KeyProps        // for type=related-crypto-material
    Algorithm   *AlgoProps       // for type=algorithm
    Related     []CryptoRelation // → relatedCryptographicAssets
}

// CryptoRelation.Ref points to another asset's CryptoAsset.ID.
type CryptoRelation struct {
    Type string // e.g. "algorithm" | "publicKey" | "privateKey"
    Ref  string // = target CryptoAsset's ID
}

The field composition of CertProps, KeyProps, and AlgoProps is defined below, and their semantics are described in section 4 ("Extracted data").

// CertProps — type=certificate → cdx.CertificateProperties
type CertProps struct {
    SubjectName    string          // subjectName
    IssuerName     string          // issuerName
    NotValidBefore string          // notValidBefore, RFC3339
    NotValidAfter  string          // notValidAfter, RFC3339
    SerialNumber   string          // serial number (hex)
    Format         string          // certificateFormat, always "X.509"
    Extensions     []CertExtension // certificateExtensions
    Fingerprint    string          // fingerprint: SHA-256 of DER → cdx.Hash{Algorithm: "SHA-256", Value}
}

// CertExtension — a single certificate extension → cdx.CertificateExtension (CommonCertificateExtension).
// Name — a predefined name from the CycloneDX enum; Value — a readable render of the extension content.
type CertExtension struct {
    Name  string // "keyUsage" | "extendedKeyUsage" | "basicConstraints" | "subjectAlternativeName" | ...
    Value string // e.g. "digitalSignature, keyEncipherment"; "CA:TRUE, pathlen:0"; "DNS:example.com, DNS:www.example.com"
}

// KeyProps — type=related-crypto-material → cdx.RelatedCryptoMaterialProperties
type KeyProps struct {
    Type      string     // "private-key" | "public-key"
    Size      int        // key length in bits (RSA — modulus, EC — from curve); 0 if unavailable (encrypted)
    Format    string     // "PEM" | "DER"
    Value     string     // public key (not filled for private ones — see "Sensitive data")
    SecuredBy *SecuredBy // what protects an encrypted private key; phase 2 (nil in phase 1)
}

// SecuredBy — the top-level AlgorithmIdentifier of an encrypted key (phase 2; see "Encrypted-key protection", section 10).
type SecuredBy struct {
    Mechanism    string // e.g. "PBES2: PBKDF2(HMAC-SHA1, 2048) + AES-256-CBC" (internal convention, not a standard)
    AlgorithmRef string // = ID of the cipher algorithm component
}

// AlgoProps — type=algorithm → cdx.AlgorithmProperties. A derived asset, assembled from OID + registry (section 4).
type AlgoProps struct {
    OID                      string   // identity, from AlgorithmIdentifier
    Primitive                string   // "signature" | "hash" | "pke" | "kdf" | "key-agree" | ... (CycloneDX enum)
    ParameterSetIdentifier   string   // parameterSetIdentifier: normalized size (e.g. "2048"); empty for EdDSA
    EllipticCurve            string   // ellipticCurve: an ellipticCurvesEnum value, e.g. "nist/P-256", "other/Ed25519"
    CryptoFunctions          []string // cryptoFunctions: "sign"/"verify"/"encrypt"/"decrypt"/"digest"/... (CycloneDX enum)
}

Identity scheme (ID)

The ID serves both as the deduplication key and (at encode time) as the bom-ref value. It is derived from content, so the same asset from different files and layers is merged into one component, and relationships resolve across files. Formula by type:

Type	ID	Why
certificate	crypto:certificate:<sha256(DER)>	DER is the canonical certificate encoding (RFC 5280 §4.1).
related-crypto-material (key)	crypto:related-crypto-material:<private|public>:<sha256(SPKI)>	SPKI carries only the public part (RFC 5280 §4.1.2.7), so a private key and its public counterpart yield the same sha256(SPKI). The private/public marker keeps them distinct assets — otherwise the presence of a private key would be masked by the public one.
algorithm	crypto:algorithm:<OID>[:<paramSet>]	An OID alone is not enough, because the distinguishing parameter lies outside it: the RSA size is set by the key modulus, not the OID (RFC 8017 §3.1), and the EC curve by a separate namedCurve in the parameters (RFC 5480 §2.1.1), while the AlgorithmIdentifier itself is identical for RSA-2048 and RSA-4096 (or P-256 and P-384) (RFC 5280 §4.1.1.2). So we add paramSet — the normalized key size or curve name — to the ID; otherwise algorithms of different strength would merge into one component. For EdDSA the parameter is already in the OID (Ed25519 ≠ Ed448), so paramSet is empty.

Two special cases of the scheme:

• Encrypted private key — the SPKI is unavailable, so ID = crypto:related-crypto-material:private:enc:<sha256(EncryptedPrivateKeyInfo)> (see "Encrypted private keys" in section 4).
• EC key — paramSet is taken from the curve name: crypto:algorithm:1.2.840.10045.2.1:nist/P-256.

A filled example (a self-signed certificate):

CryptoAsset{
    ID:       "crypto:certificate:ab12…",   // sha256(DER)
    FilePath: "etc/ssl/certs/server.crt",
    Type:     "certificate",
    Name:     "CN=example.com",
    Props: CryptoProps{
        Certificate: &CertProps{
            SubjectName:    "CN=example.com",
            IssuerName:     "CN=example.com",
            NotValidBefore: "2024-01-01T00:00:00Z",
            NotValidAfter:  "2025-01-01T00:00:00Z",
            Format:         "X.509",
        },
        Related: []CryptoRelation{
            {Type: "algorithm", Ref: "crypto:algorithm:1.2.840.113549.1.1.11"}, // sha256WithRSA
            {Type: "publicKey", Ref: "crypto:related-crypto-material:public:cd34…"}, // public:sha256(SPKI)
        },
    },
}

Through Related the certificate references two more assets — the signature algorithm (ID = crypto:algorithm:<OID>[:paramSet]) and the related-crypto-material with the public key (ID = crypto:related-crypto-material:public:<sha256(SPKI)>); the public key, in turn, references its own key algorithm. Each merges with same-named assets from other files (see "Identity scheme").

The types are neutral (no cyclonedx-go): they are reused by both the findings layer and core.Component (as it already reuses ftypes.PkgIdentifier), and only the cdx marshaler translates them to cdx.CryptoProperties. This keeps fanal/types (imported by hundreds of packages) and the neutral sbom/core model independent of the output format.

Required changes:

• new neutral types CryptoAsset, CryptoProps (CertProps/KeyProps/AlgoProps, Related), CryptoRelation in pkg/fanal/types;
• a new []CryptoAsset field in AnalysisResult (+ handling in Merge/isEmpty), ArtifactDetail, types.Result (the chain — section 9);
• a CryptoProperties *ftypes.CryptoProps field in core.Component (sbom/core) — reusing the neutral type from ftypes (section 8).

7. Provenance and attribution

An image or filesystem sees the whole tree, not only the user's artifacts, so every asset carries its path (occurrence) and is tagged with a layer.

Layer attribution

Trivy tags files by layer (DiffID). For packages the layer is a component property (aquasecurity:trivy:LayerDiffID/LayerDigest: sbom/io/encode.go → decode.go), and a single such property is enough because a package component is bound to one layer — packages are not merged by content across layers. Crypto assets, by contrast, are merged by ID across layers (section 6: a CA bundle of 130 certificates in the base and the user layer → 130 components, not 260), so one component has several layers and a single component property cannot hold them. Therefore the layer is a property of the occurrence: in CycloneDX that is EvidenceOccurrence.AdditionalContext (a field next to location, per-occurrence). The inventory stays complete, and the consumer filters by layer (base image / user). The alternative — not merging across layers and repeating the package scheme — was rejected: it brings back the very duplicates the content-derived ID was introduced to remove.

Noise

• CA bundles (/etc/ssl/certs/..., 130+ public roots) — the main source of noise. Such certificates are detected and marked as a system trust store but are not removed from the report; the criterion is in the subsection below.
• Base-image and OS-layer cryptography — separated by layer attribution (above).
• Test data (testdata/, sample certificates inside packages) — see the open question in section 11.

Detecting the system trust store

A system root is a root CA that lives in the OS trust store. Neither signal alone singles it out, so we emit both, and what we find is marked, not removed — the threshold is left to the consumer.

• Content → role (component level). A root CA is BasicConstraints: CA:TRUE and self-signed (Issuer == Subject); an intermediate CA is CA:TRUE but not self-signed; everything else is an end-entity (leaf) certificate. The signal is derived from the certificate itself, so it is path-independent, identical for all occurrences of a component (same DER → same ID), and works per certificate, including inside bundles. It answers "is this a root CA?", but not "is this the system store?": by content a public root is indistinguishable from a user's — a corporate internal CA is also self-signed CA:TRUE. The classification is computed in the extractor from BasicConstraints and Issuer/Subject. CycloneDX has no dedicated role field — it is derived from already-emitted standard fields (basicConstraints in certificateExtensions, subjectName vs issuerName) — so the marshaler duplicates it as a ready component property aquasecurity:trivy:CertificateRole (root-ca | intermediate-ca | leaf), the same mechanism as package properties: the consumer filters by a single property instead of parsing extensions itself.
• Path → provenance (occurrence level). Answers the second question — whether the certificate lies in the system trust store: known directories (/etc/ssl/certs, /etc/pki/tls/certs, /etc/pki/ca-trust, /usr/share/ca-certificates, /usr/local/share/ca-certificates) and typical bundle names (ca-certificates.crt, ca-bundle.crt, tls-ca-bundle.pem). The path is already in occurrence.location, so no separate field is introduced.

Trivy only exposes both attributes; the "this is noise" decision is made by the report consumer, combining them for their own task: a typical filter is role root-ca and a trust-store path, which drops the 130+ public roots while keeping a user root that lies outside the system directories. Neutrality is needed because "noise" depends on the task: when auditing your own CA the roots are wanted, when hunting for weak end-entity certificates they get in the way. Whether the marked roots stay in the output by default — and the flag that implies — is left open (section 11).

8. CycloneDX output mapping

cyclonedx-go v0.11.0 (Trivy emits CycloneDX 1.7) already contains the needed types — cdx.CryptoProperties (CertificateProperties, RelatedCryptoMaterialProperties, AlgorithmProperties) and the cdx.ComponentTypeCryptographicAsset component type; no spec upgrade is required.

The CBOM is not a separate document: crypto assets become additional components (type cryptographic-asset) in the same CycloneDX report as the SBOM.

Mapping chain

A crypto asset goes through the same path as the other BOM components — the sbom/core domain model and the marshaler. Three places need to be added:

1. pkg/sbom/core/bom.go — the core.Component domain model currently has no field for cryptography. Add:

   • a CryptoProperties *ftypes.CryptoProps field (the neutral type from ftypes) to core.Component;
   • a new core.ComponentType — TypeCryptographicAsset.

2. pkg/sbom/io/encode.go — Encode builds a core.BOM from report.Results. Add an encodeCryptoAssets branch:

   • merge by CryptoAsset.ID → one core.Component per unique ID; each source CryptoAsset (its own FilePath + Layer) yields its own evidence.occurrences[]: location = FilePath, the layer goes into AdditionalContext (section 7), i.e. per occurrence, not per component;
   • component.PkgIdentifier.BOMRef = asset.ID (the marshaler writes bom-ref from this field, marshal.go:126);
   • component.CryptoProperties = &asset.Props — the neutral type is carried over whole, together with Props.Related;
   • provenance relationships (dependsOn, see section 7) — via a separate mechanism through relationships in core.BOM.

3. pkg/sbom/cyclonedx/marshal.go:

   • componentType() — add core.TypeCryptographicAsset → cdx.ComponentTypeCryptographicAsset;
   • MarshalComponent() — translate component.CryptoProperties (ftypes.CryptoProps) into cdx.CryptoProperties: CertProps/KeyProps/AlgoProps → the corresponding nested objects, Related → relatedCryptographicAssets (ref = target.ID). This is the only place where the neutral model meets the cdx types.

   The marshaler writes relatedCryptographicAssets references directly from Related — they do not go through componentIDs (UUID→bom-ref), unlike top-level dependencies. So ref must literally match the target's bom-ref; this is guaranteed by BOMRef = ID (step 2) and Related.Ref = target.ID.

SPDX does not support cryptoProperties, so the mapping is implemented for CycloneDX only; the crypto field exists in the shared sbom/core domain model, but the SPDX marshaler ignores it.

Component example

The CryptoAsset from section 6 (a certificate) in CycloneDX:

{
  "type": "cryptographic-asset",
  "bom-ref": "crypto:certificate:ab12…",
  "name": "CN=example.com",
  "cryptoProperties": {
    "assetType": "certificate",
    "certificateProperties": {
      "subjectName": "CN=example.com",
      "issuerName": "CN=example.com",
      "notValidBefore": "2024-01-01T00:00:00Z",
      "notValidAfter": "2025-01-01T00:00:00Z",
      "certificateFormat": "X.509",
      "fingerprint": { "alg": "SHA-256", "content": "ab12…" },
      "relatedCryptographicAssets": [
        { "type": "algorithm", "ref": "crypto:algorithm:1.2.840.113549.1.1.11" },
        { "type": "publicKey", "ref": "crypto:related-crypto-material:public:cd34…" }
      ]
    }
  },
  "evidence": {
    "occurrences": [{ "location": "etc/ssl/certs/server.crt" }]
  }
}

FilePath goes into evidence.occurrences[].location, the rest into cryptoProperties. The algorithm (crypto:algorithm:…) and the public key (crypto:related-crypto-material:public:…) are separate neighboring components of the same document, referenced by relatedCryptographicAssets.

9. Integration into analysis and scanning

The crypto analyzers are enabled only for the image target and the cyclonedx format.

A new crypto scanner type, available only for image and enabled manually: in NewImageCommand add it to the allowed values of the --scanners flag but not to the default set (unlike k8s, where the default set is overridden):

scanners := flag.ScannersFlag.Clone()
// crypto — image-only and enabled manually: extend the allowed values, do not change the default set
scanners.Values = append(scanners.Values, string(types.CryptoScanner))
scanFlags.Scanners = scanners

If the crypto scanner is not enabled, disabledAnalyzers adds the crypto analyzers (listed in const.go) to DisabledAnalyzers. For an image without the cyclonedx format — a warning or error in checkOptions.

In pkg/fanal/analyzer create a crypto package, with the analyzers (analyzer.analyzer) in subpackages: Required selects by extension (section 3), Analyze parses and returns crypto material. For files with no recognizable extension — an open question in section 11.

The parser lives next to its analyzer; the shared extractors (X.509, keys), reused by several analyzers, are moved into the shared pkg/crypto package. A shared Parser/Analyze to cut boilerplate — see section 4.

Registration is via blank-import: by analogy with analyzer/config/all, create a nested aggregator analyzer/crypto/all and add it to the existing analyzer/all/import.go (already imported in pkg/scan/local/service.go).

Package tree:

pkg/fanal/analyzer/
├── const.go                # (existing) + crypto-analyzer Type and their group (for disabledAnalyzers)
└── crypto/
    ├── analyze.go          # shared Parser + Analyze (wraps the parser result in AnalysisResult)
    ├── x509/
    │   ├── analyzer.go     # Type/Version/Required/Analyze
    │   └── parser.go       # PEM/DER → object → extractor
    └── all/
        └── import.go       # blank-import x509 → wired into analyzer/all

pkg/crypto/                 # shared extractors, reused by analyzers
├── certificate.go          # *x509.Certificate → CryptoAsset
├── key.go                  # key → CryptoAsset
└── algorithm.go            # OID → algorithmProperties matching

Threading crypto assets to the report

The analysis result goes through the same chain as Secrets/Licenses, but diverges at the end (crypto assets are BOM components, not findings):

1. AnalysisResult (a new field, see section 6) — filled by the analyzer, handled in Merge/isEmpty.
2. ftypes.ArtifactDetail — a new field; filled in the applier (pkg/fanal/applier/docker.go): ApplyLayers sets each asset's Layer = {DiffID, Digest} for the layer it was found in (as for licenses/secrets), rather than looking up the layer by files as for packages. This is the layer of the specific occurrence; it is not reduced onto the shared component but goes into the occurrence at encode time (sections 7–8).
3. types.Result — a new field; filled in pkg/scan/local/service.go.
4. Then — not into findings, but into the BOM: the sbom/io/encode.go encoder builds components from this (section 8).

10. Delivery stages

Out of phase 1

• Weak and deprecated crypto detection (SHA-1, RSA < 2048, expired certificates, weak curves) — high value, but deferred: the inventory needs no consumer-facing API design, whereas detection does (thresholds + a verdict marker). Separated as a distinct assessment step on top of the asset model.
• Provenance linking (asset → package via dependsOn) — a separate post-processing step, reconstructed imprecisely.
• OpenSSH (id_*, *.pub, authorized_keys, known_hosts) — the nearest follow-up as a separate PR: high value, zero new dependencies (x/crypto/ssh is already in the tree). Deferred for architectural independence (its own format, its own extractor, detection by file name), not for cost.
• PKCS#12 (.p12/.pfx) — keystores. The built-in x/crypto/pkcs12 library is frozen and too limited: it reads only a single certificate and key (not all container entries), does not support modern encryption (AES, the OpenSSL 3 default), and only certificate stores. Full support requires a new dependency, sslmate/go-pkcs12, so the format is deferred out of phase 1.
• JKS (.jks/.keystore) — a separate PR: high value (Java/enterprise), low complexity, but requires a new external dependency (keystore-go). Phase 1 stays free of new dependencies.
• CRL (.crl) — rare as a standalone file, and its cryptographic signal (the CA's signature algorithm) duplicates the CA certificate itself. Parsing is cheap (x509.ParseRevocationList), but the value is low.
• OpenPGP (.gpg/.pgp/.asc, keyrings) — common (apt/rpm), but requires a new dependency (x/crypto/openpgp deprecated → the ProtonMail/go-crypto fork) and a separate packet-based parser. Deferred for cost, not rarity.
• Private keys in files with no recognizable name — extension-based detection misses them (e.g. a key embedded in a config). Options: reuse the secret scanner or add content-based detection. Implementation out of phase 1.
• Component decomposition — the sha256WithRSAEncryption signature algorithm can be decomposed into two assets plus a relationship: SHA-256 as a hash primitive, RSA as a pke primitive, and sha256WithRSAEncryption itself as a signature primitive referencing the first two. With the current focus on inventory rather than detection, decomposition is not required.
• Encrypted-key protection (securedBy) — in phase 1 an encrypted private key is inventoried as state: encrypted only; decomposing what protects it (the PBES2 scheme: KDF, PRF, cipher, iteration count) is deferred to phase 2. It is a strength signal, it is the only part that needs hand-rolled ASN.1 below stdlib's typed API, and it would require the registry to gain cipher/KDF OIDs that the phase-1 initial set does not have. Details below.
• ECDSA/ECDH split via KeyUsage — in phase 1 the EC key's purpose is not determined (primitive: unknown); determining signing vs. key agreement via the certificate's KeyUsage is deferred to phase 2 as its first item, right after the inventory. Details below.

ECDSA/ECDH split via KeyUsage

The OID 1.2.840.10045.2.1 (id-ecPublicKey, RFC 5480 §2.1.1) in SubjectPublicKeyInfo marks only "an elliptic-curve key", but does not indicate the purpose — signing (ECDSA) or key agreement (ECDH). In phase 1 the purpose is not determined: primitive is unknown, family is left empty, the curve is kept. Without confirmed purpose ECDSA is not assigned, so as not to attribute a wrong primitive to the key.

Determining the purpose is deferred to phase 2 as its first item: until this step is done, primitive is empty for all EC keys, including the most common case — end-entity TLS certificates on the P-256 curve. It relies on the certificate's KeyUsage: keyAgreement → ECDH (key-agree), digitalSignature/keyCertSign → ECDSA (signature); for a standalone key file, where KeyUsage is absent, the purpose stays unknown. This is the only registry record whose family and primitive are resolved not statically from the table but from KeyUsage in the certificate extractor, so it is implemented in the x509 extractor itself, without a separate file or analyzer.

The split also affects identity: the SPKI OID is the same for ECDSA and ECDH, so the purpose is not reflected in the ID by the OID alone. In phase 1 the ID is built on the plain OID (crypto:algorithm:1.2.840.10045.2.1:nist/P-256). In phase 2, so that ECDSA and ECDH components on the same curve do not merge into one with a contradictory primitive, the ID of a determined purpose is built from the family name:

crypto:algorithm:ecdsa:nist/P-256              # KeyUsage = digitalSignature/keyCertSign
crypto:algorithm:ecdh:nist/P-256               # KeyUsage = keyAgreement
crypto:algorithm:1.2.840.10045.2.1:nist/P-256  # KeyUsage absent → purpose undetermined

The key component itself (related-crypto-material by sha256(SPKI)) merges across files independently — only the algorithm reference differs.

Encrypted-key protection (securedBy)

Without the password, the top-level AlgorithmIdentifier of an EncryptedPrivateKeyInfo is readable (for PBES2 — the KDF, its PRF, and the cipher), and securedBy is filled from it. The model carries a single mechanism and a single algorithmRef, so they are distributed like this: the cipher becomes a separate algorithm component referenced via algorithmRef, and mechanism holds a string with the whole scheme, including the KDF and PRF:

"securedBy": {
  "mechanism": "PBES2: PBKDF2(HMAC-SHA1, 2048) + AES-256-CBC",
  "algorithmRef": "crypto:algorithm:aes-256-cbc"
}

The mechanism string format is an internal convention, not a standard: in CycloneDX it is free text with no grammar. It is assembled deterministically so the value is stable across scans: OIDs are run through an OID → name table (an unknown OID is emitted as-is, as a dotted string), plus iterationCount as a strength signal. The example values are the openssl genpkey default (HMAC-SHA1, 2048 iterations).

The top-level AlgorithmIdentifier is parsed with stdlib (encoding/asn1), without decryption and without external dependencies — the EncryptedPrivateKeyInfo / PBES2-params / PBKDF2-params structures are described by hand:

type encryptedPrivateKeyInfo struct {
	Algo          pkix.AlgorithmIdentifier // encryptionAlgorithm (PBES2)
	EncryptedData []byte
}
type pbes2Params struct {
	KeyDerivationFunc pkix.AlgorithmIdentifier // PBKDF2 / scrypt
	EncryptionScheme  pkix.AlgorithmIdentifier // AES-256-CBC, etc.
}
type pbkdf2Params struct {
	Salt           asn1.RawValue            // CHOICE, usually OCTET STRING
	IterationCount int
	KeyLength      int                      `asn1:"optional"`
	PRF            pkix.AlgorithmIdentifier `asn1:"optional"` // absent → HMAC-SHA1
}

block, _ := pem.Decode(data) // block.Type == "ENCRYPTED PRIVATE KEY"

var epki encryptedPrivateKeyInfo
asn1.Unmarshal(block.Bytes, &epki)

var p2 pbes2Params
asn1.Unmarshal(epki.Algo.Parameters.FullBytes, &p2)

var kdf pbkdf2Params
asn1.Unmarshal(p2.KeyDerivationFunc.Parameters.FullBytes, &kdf)

cipherOID := p2.EncryptionScheme.Algorithm  // → AES-256-CBC (algorithmRef)
kdfOID := p2.KeyDerivationFunc.Algorithm    // → PBKDF2
iterations := kdf.IterationCount            // → 2048

prfOID := oidHMACWithSHA1                    // default per RFC 8018 when the field is absent
if kdf.PRF.Algorithm != nil {
	prfOID = kdf.PRF.Algorithm
}

A subtlety with prf: in PBKDF2-params this field is declared DEFAULT algid-hmacWithSHA1 (RFC 8018, Appendix A.2), and by the DER rule (X.690 §11.5) a value equal to the default is omitted when encoding — so openssl does not write the field at all for HMAC-SHA1, and a spec-conformant decoder must treat its absence as HMAC-SHA1. encoding/asn1 does not expand DEFAULT itself (it leaves the zero value), so the substitution in code is not a heuristic but a literal following of the RFC. x509.ParsePKCS8PrivateKey is inapplicable here: it fails on an encrypted block.

Because the cipher is emitted as a separate algorithm component, this step also requires the registry (section 4) to gain symmetric cipher and KDF OIDs (AES-256-CBC, PBKDF2, ...), which the phase-1 initial set does not include.

11. Open questions

• Filtering test paths. Should testdata//test paths (a frequent source of sample cryptography) be filtered out, and would that lose real assets?

• System trust store: default and flag. The detection criterion and marking approach are chosen (section 7); the default is not. Two options, and each implies a flag:

  • system roots included by default → is a flag needed to exclude them (drop the system trust store from the output)?
  • system roots excluded by default → then a flag is needed to include them.

  So the real question is which default; a flag is likely needed either way. Also open: whether the list of trust-store directories is complete across distributions.

[knqyf263]

I reviewed the proposal against the CycloneDX 1.7 model and existing CBOM implementations. I think there are a few points we should clarify or adjust.

1. state: encrypted should not be emitted. relatedCryptoMaterialProperties.state represents the NIST key lifecycle state and only accepts pre-activation, active, suspended, deactivated, compromised, or destroyed. encrypted is not a valid value. For Phase 1, I suggest leaving state unset and representing the fact that the container is encrypted separately, for example in the neutral model or a custom property, until securedBy is implemented. See the CycloneDX 1.7 JSON reference.

2. The rsaEncryption SubjectPublicKeyInfo OID should probably be handled as conservatively as id-ecPublicKey. RFC 3279 explicitly states that this OID is used for both RSA signature keys and RSA encryption keys, with the intended purpose optionally indicated by KeyUsage. Mapping it unconditionally to primitive: pke may therefore misclassify RSA signing keys. Without decisive usage information, primitive: unknown seems safer. If KeyUsage contains both signature and encipherment usages, we should also define whether to emit multiple algorithm assets or retain a generic RSA asset. See RFC 3279 Section 2.3.1.

3. The initial signature OID table is narrower than the algorithms that Go crypto/x509 can identify while parsing certificates. Phase 1 should include straightforward missing mappings such as DSA-with-SHA1/SHA256, ECDSA-with-SHA1, and MD5-with-RSA. RSA-PSS should be explicitly excluded from Phase 1 and tracked as a follow-up because its variants share one OID and require parameter-aware handling to distinguish the hash and salt length.

4. I agree with omitting classicalSecurityLevel and nistQuantumSecurityLevel from Phase 1. For Phase 2, I suggest making their ownership explicit. A derived level such as RSA-2048 -> 112 should belong to the parameterized public-key algorithm component referenced by the key material. A signature OID alone should not receive a classical security level because its effective strength also depends on the issuer key parameters and the digest. In particular, the certificate subject public key must not be used as the signing key. If the issuer key cannot be resolved, the signature algorithm strength should remain unset. This is also consistent with the CycloneDX CBOM guide, which includes the RSA key size but omits classicalSecurityLevel from its RSA signature examples.

5. Since Trivy emits CycloneDX 1.7, the generated vocabulary should be pinned to the CycloneDX 1.7 cryptography definitions, rather than downloading from master. Otherwise, a future definition or enum added to master could produce output that is not valid against the 1.7 schema.

[ngr-dev1]

Consumer-side perspective, since I built an evaluator that grades CycloneDX CBOMs against the EO 14412 deadlines — this design decides what's gradable downstream, so a few notes from the receiving end.
On @knqyf263's point 2 (rsaEncryption → primitive: unknown): I'd argue strongly for unknown, and the reason is sharper than "safer."
Under EO 14412 the deadline turns on the primitive, not the algorithm:
key establishment (pke, kem, key-agree) → 31 Dec 2030 (§4(b)(ii), defined by reference to FIPS 203)
digital signatures (signature) → 31 Dec 2031 (§4(b)(iii), defined by reference to FIPS 186-5)
So rsaEncryption mapped unconditionally to pke doesn't just misclassify the primitive — it silently moves an RSA signing key's compliance deadline a year earlier, and does it invisibly, because the OID and modulus are identical either way. A consumer has no way to detect the error. primitive: unknown is recoverable; a confidently wrong pke is not.
For what it's worth, I made the mirror-image mistake in my own evaluator: my key-establishment test matched kem|key-agree|key-transport and omitted pke entirely, so a manifest that correctly declared RSA key transport reached the right deadline through the fallback path rather than by reasoning. Same class of bug, opposite direction. Both are invisible without the primitive being trustworthy.
What a consumer does with unknown: falls back to the earliest applicable deadline (2030) and flags the asset as not machine-assessable. That's the correct conservative behaviour, and it's only possible if generators emit unknown rather than guessing. If Trivy guesses, my evaluator can't tell a guess from a declaration — and neither can anyone else's.
On the KeyUsage split deferred to Phase 2: that's the single highest-value item in the deferred list from a compliance standpoint. keyEncipherment/keyAgreement → 2030, digitalSignature/keyCertSign → 2031. Until it lands, every RSA and EC key in a Trivy CBOM is undatable against the order, which is the thing federal contractors will be asked for. Worth pulling forward ahead of the format expansions (PKCS#12, JKS) if there's ever a choice.
On point 4 (ownership of security levels): agreed, and it matches what I ended up implementing — the level belongs to the parameterised public-key algorithm component, not to the signature OID. A signature OID has no key size in it, so any level attached there is a guess about the issuer's key.
Happy to contribute test vectors if useful — I maintain ten versioned conformance rules that test whether a CBOM can be machine-assessed at all, which is the functional requirement in EO 14412 §5(d) ("shall enable the automated assessment of the cryptographic assets utilized by a hardware or software element"). They'd double as a downstream conformance check for Phase 1 output.
The evaluator is free and uncapped, no account: https://cbomcompliance.com/check.html — if you point it at a Phase 1 CBOM, it'll tell you exactly which assets it can't grade and why.