Generating a Software Bill of Materials is only half the battle. An SBOM that cannot be trusted is worse than no SBOM at all — it provides a false sense of security while leaving the door open for supply-chain manipulation. SBOM signing is the cryptographic trust layer that proves an SBOM was produced by a known party and has not been altered since creation. In the automotive industry, where a single tampered SBOM could conceal a malicious dependency lurking inside a safety-critical ECU, signing and verification are not optional add-ons. They are foundational security controls.
This guide covers the complete SBOM signing and verification lifecycle for automotive supply chains: the cryptographic mechanisms available, how to build automated verification gates at OEM ingestion points, tamper detection strategies, key management at scale, archival integrity over 15-year vehicle lifecycles, and real-world attack scenarios that unsigned or poorly verified SBOMs enable. Whether you are an OEM building an SBOM ingestion pipeline or a Tier-1 supplier preparing to sign your deliverables, this article provides the actionable technical details you need.
The regulatory context reinforces the urgency. ISO/SAE 21434 requires organizations to ensure the integrity of cybersecurity-relevant work products exchanged across the supply chain. UNECE R155 demands that OEMs demonstrate controls over software identification and update processes. The EU Cyber Resilience Act explicitly mandates machine-readable SBOMs for products with digital elements. None of these frameworks are satisfied by an SBOM that arrives unsigned over email — SBOM integrity and SBOM authenticity must be cryptographically provable.
Why SBOM Integrity Matters in Automotive
An SBOM is a security-critical artifact. It drives vulnerability correlation, regulatory compliance evidence, and supply-chain risk assessments. If an attacker can modify an SBOM — removing a vulnerable component from the list, injecting a phantom dependency, or replacing version strings — every downstream process that relies on that SBOM becomes compromised. Vulnerability scans return clean results for a product that is actually vulnerable. Compliance audits pass with fabricated evidence. Risk assessments undercount exposure.
In automotive, the stakes are amplified by safety implications. An SBOM for a brake controller ECU that omits a known-vulnerable TLS library gives the OEM false confidence that no patch is needed. That unpatched vulnerability becomes an attack vector for remote exploitation. The regulatory frameworks understand this: ISO/SAE 21434 Clause 7 requires organizations to establish processes that ensure the integrity of cybersecurity work products, and SBOMs are explicitly among those work products. UNECE R155 Annex 5 references the need to verify the integrity of software update artifacts, which logically extends to the metadata describing that software.
The threat is not theoretical. Software supply-chain attacks have increased dramatically, with incidents like SolarWinds, Codecov, and the XZ Utils backdoor demonstrating that adversaries target the metadata and build pipelines surrounding software, not just the software itself. An unsigned SBOM transmitted between a Tier-2 supplier and a Tier-1 integrator over a shared portal or email attachment is trivially modifiable in transit. Without SBOM verification, there is no way to distinguish a legitimate SBOM from one that has been subtly altered to conceal a compromise.
The EU Cyber Resilience Act further raises the bar. Article 13 requires manufacturers to provide machine-readable SBOMs, and the accompanying guidance on supply-chain due diligence implicitly requires that those SBOMs be trustworthy. An OEM that ingests unverified supplier SBOMs into its CRA compliance documentation is building its regulatory house on sand. SBOM signing transforms the SBOM from a document you hope is accurate into a document you can cryptographically prove is authentic and unmodified.
SBOM Signing Mechanisms
Multiple cryptographic approaches exist for signing SBOMs, each with different trade-offs around key management complexity, ecosystem maturity, and suitability for long-term automotive use. The right choice depends on your supply chain’s existing PKI infrastructure, the SBOM format you standardize on, and whether you need signatures to remain verifiable for 15 years or more.
PGP/GPG Detached Signatures
PGP (Pretty Good Privacy) detached signatures are the oldest and most widely understood approach to SBOM signing. The supplier generates a PGP key pair, signs the SBOM file with their private key using gpg --detach-sign --armor sbom.cdx.json, and delivers the resulting .asc signature file alongside the SBOM. The OEM verifies by importing the supplier’s public key and running gpg --verify sbom.cdx.json.asc sbom.cdx.json. If the SBOM has been modified by even a single byte, verification fails.
PGP’s advantages for automotive are its maturity, universal tooling support, and the ability to work with any file format — CycloneDX JSON, SPDX JSON, SPDX RDF, or even proprietary formats. The signature is format-agnostic because it operates on the raw byte stream of the file. This makes PGP the lowest-friction option for heterogeneous supply chains where different suppliers use different SBOM formats.
The primary drawback is key management. PGP relies on a web-of-trust model that does not scale naturally to automotive supply chains with hundreds of suppliers. Each supplier must generate, protect, and eventually rotate their PGP keys. The OEM must maintain a trusted keyring of all supplier public keys, handle key expiry, and manage revocation when a supplier’s key is compromised. For organizations without existing PGP infrastructure, the operational overhead is significant.
Sigstore and Keyless Signing
Sigstore is a newer approach that eliminates long-lived signing keys entirely. Instead of managing PGP key pairs, suppliers authenticate through an OIDC (OpenID Connect) identity provider — their corporate SSO, GitHub Actions, or Google Workspace — and receive an ephemeral signing certificate from Sigstore’s Fulcio certificate authority. The certificate is valid for only minutes, just long enough to produce the signature. The signing event is recorded in Sigstore’s Rekor transparency log, creating an immutable public record that the SBOM was signed by a verified identity at a specific timestamp.
For automotive supply chains, Sigstore offers compelling advantages. The cosign tool (Sigstore’s signing CLI) integrates natively into CI/CD pipelines, enabling fully automated SBOM signing without human interaction or long-lived secrets. A typical pipeline step is: cosign sign-blob --yes --bundle sbom.cdx.json.bundle sbom.cdx.json. The resulting bundle contains the signature, the ephemeral certificate, and the Rekor log entry — everything the OEM needs to verify. Verification requires no pre-shared keys: cosign verify-blob --bundle sbom.cdx.json.bundle --certificate-identity supplier@example.com --certificate-oidc-issuer https://accounts.google.com sbom.cdx.json.
The trade-off is dependency on external infrastructure. Sigstore’s public instance (Fulcio CA, Rekor log) must be reachable during signing and verification. For air-gapped environments common in automotive manufacturing, organizations can deploy private Sigstore instances using the sigstore-scaffolding project. The Rekor transparency log also raises data sensitivity questions: while the SBOM content is not uploaded, the signing identity, timestamp, and artifact hash are publicly recorded. Organizations with strict confidentiality requirements may prefer a private Rekor instance.
CycloneDX Native Signing (JSR-353, XML-DSIG)
CycloneDX supports embedded signatures directly within the SBOM document. For XML-format CycloneDX SBOMs, the XML Digital Signature (XML-DSIG) standard allows the signature to be embedded as a <Signature> element within the BOM document itself. The signature covers the canonicalized XML content, meaning any modification to the SBOM body invalidates the signature without needing a separate signature file.
For JSON-format CycloneDX SBOMs, the specification supports signing through JSR-353 (Java API for JSON Processing) compatible mechanisms and JSON Web Signature (JWS). The CycloneDX specification defines a signature field within the BOM metadata that can carry the signer’s identity, algorithm, and signature value. This is particularly useful when SBOMs are exchanged through APIs or stored in document databases where keeping a separate signature file in sync is operationally fragile.
The advantage of native CycloneDX signing is that the SBOM is self-contained — a single file carries both the content and its integrity proof. The disadvantage is that it couples the signing mechanism to the SBOM format and version. Tools that parse the SBOM must understand the embedded signature structure, which limits interoperability with generic signature verification tooling. For organizations standardized on CycloneDX with supporting tooling, native signing is elegant. For heterogeneous supply chains, detached signatures (PGP or Sigstore) offer more flexibility.
SPDX Signing Approaches
SPDX does not define a native in-document signing mechanism in its 2.3 specification. Instead, SPDX SBOMs are typically signed using external mechanisms: PGP detached signatures, Sigstore cosign bundles, or by wrapping the SPDX document in a signed container such as an in-toto attestation envelope. The in-toto framework, part of the CNCF (Cloud Native Computing Foundation) supply-chain security ecosystem, wraps the SBOM as a subject within a DSSE (Dead Simple Signing Envelope) that carries the signature and signer identity.
For automotive organizations using SPDX, the recommended approach is to pair the SPDX document with a cosign bundle or PGP detached signature, stored alongside the SBOM in the artifact repository. When SPDX 3.0 reaches full adoption, its improved extensibility may enable native signing extensions, but current production deployments should rely on external signing mechanisms. The key principle is that regardless of the signing mechanism chosen, the SBOM and its signature must always travel together and be stored together — a signed SBOM separated from its signature is indistinguishable from an unsigned one.
Verification Workflows at the OEM Gate
Signing without verification is security theater. The value of SBOM signing is realized only when every SBOM entering the OEM’s systems passes through an automated verification gate that checks the cryptographic signature, validates the signer’s identity, and confirms the SBOM content has not been modified. This gate must be automated, mandatory, and non-bypassable.
Automated Signature Verification in CI/CD
The verification gate should be implemented as an automated step in the OEM’s SBOM ingestion pipeline. When a supplier uploads an SBOM (through a portal, API, or artifact repository), the pipeline immediately performs three checks before the SBOM enters any downstream processing.
First, signature validity: the pipeline verifies that the cryptographic signature is mathematically correct. For PGP, this means gpg --verify returns a good signature status. For Sigstore, cosign verify-blob confirms the signature matches the SBOM content and the Rekor log entry is valid. For CycloneDX embedded signatures, the pipeline validates the XML-DSIG or JWS signature against the document body.
Second, signer identity: a valid signature from an unknown party is not sufficient. The pipeline must verify that the signing identity matches an expected supplier. This means checking the PGP key fingerprint against the OEM’s trusted supplier keyring, or verifying the Sigstore certificate identity and OIDC issuer against the supplier’s registered identity. Maintaining this mapping — which signing identity corresponds to which supplier — is a critical configuration management task.
Third, timestamp validation: the signature timestamp must be plausible. A signature dated in the future, or significantly before the expected software delivery window, may indicate replay or pre-computed signature attacks. Sigstore’s Rekor log provides a trusted timestamp independent of the signer’s clock. For PGP signatures, embedding a trusted timestamp counter-signature from a Time Stamping Authority (TSA) provides the same assurance.
SBOM Hash Matching and Content Validation
Beyond signature verification, the OEM gate should validate that the SBOM content is internally consistent and matches the delivered software artifact. This involves computing cryptographic hashes (SHA-256 at minimum) of the software deliverable and verifying they match the hashes recorded within the SBOM. If the SBOM claims to describe a firmware image with hash sha256:a1b2c3..., the gate should compute the hash of the actual firmware file and confirm they match.
Content validation extends to structural checks: does the SBOM conform to the declared schema version? Are required fields present (supplier name, component versions, PURL identifiers)? Is the component count plausible for the type of software being delivered? A CycloneDX SBOM for a Linux-based infotainment system that lists only 10 components is almost certainly incomplete, regardless of whether its signature is valid. Structural validation catches a different class of problems than cryptographic verification — the SBOM may be authentically signed by the supplier but still be incomplete or poorly generated.
Handling Verification Failures
When verification fails, the pipeline must enforce a hard stop. The SBOM should not enter the vulnerability monitoring system, the compliance database, or any other downstream processing. The failure must be logged with full details: which check failed, the supplier identity, the artifact identifier, and the timestamp. The supplier should be automatically notified of the failure with a clear description of the issue and remediation steps.
Different failure modes require different escalation paths. A signature that does not verify (the SBOM was modified) is a potential security incident and should trigger investigation. A valid signature from an unrecognized key may simply indicate a key rotation that was not communicated — the supplier needs to register their new key. A structurally invalid SBOM with a valid signature indicates a tooling or process issue at the supplier that requires remediation but is not a security concern. The verification pipeline should classify failures into these categories and route them to the appropriate response team.
Tamper Detection and Audit Trails
SBOM signing provides point-in-time integrity: you can verify that the SBOM has not been modified since it was signed. But supply-chain security requires continuous integrity assurance throughout the SBOM’s lifecycle, from creation through transfer, storage, and eventual archival. Tamper detection mechanisms and audit trails extend the trust established by signing into an ongoing assurance model.
Detecting Modification in Transit
SBOMs travel between organizations through various channels: supplier portals, artifact repositories, email attachments, shared cloud storage, and API integrations. Each transfer point is a potential modification opportunity. Beyond cryptographic signature verification at the ingestion gate, organizations should implement hash comparison at every transfer boundary. When a supplier uploads an SBOM, the portal records the SHA-256 hash. When the OEM’s ingestion pipeline retrieves it, it re-computes the hash and compares. Any discrepancy — even one caused by encoding changes, line-ending normalization, or well-intentioned format conversion — should be flagged.
Transport Layer Security (TLS) protects SBOMs in transit from passive eavesdropping and active man-in-the-middle modification, but TLS terminates at the application layer. An SBOM stored on a shared portal server is vulnerable to modification by anyone with access to that server, whether a compromised account, a malicious insider, or an attacker who has breached the portal infrastructure. Cryptographic signatures provide end-to-end integrity that survives any number of intermediate storage and transfer points, which is why they are essential even when TLS is used for every connection.
Immutable Audit Logs for SBOM Exchanges
Every SBOM exchange event should be recorded in an append-only audit log that captures the artifact hash, the signature verification result, the signer identity, the timestamp, and the transfer parties. This log serves three purposes: forensic investigation when a tampered SBOM is detected, compliance evidence for regulatory auditors, and operational visibility into supply-chain SBOM flows.
Sigstore’s Rekor transparency log provides a public, immutable record for signing events when using cosign. For organizations that need private audit logs, append-only storage backends such as Amazon QLDB, Azure Immutable Blob Storage, or a custom Merkle-tree based log provide the same tamper-evident properties. The critical requirement is immutability: once a log entry is written, it must be computationally infeasible to modify or delete it without detection. A mutable audit log is not an audit log — it is a text file that an attacker can edit to cover their tracks.
Key Management for SBOM Signing
Cryptographic signing is only as strong as the key management practices that protect it. A signing key stored unencrypted on a developer laptop, shared across multiple engineers, or left active after an employee departure undermines every signature it has produced. Automotive supply chains must implement rigorous key lifecycle management for SBOM signing keys.
Supplier Key Provisioning and Rotation
When onboarding a new supplier, the OEM should establish a key provisioning process. For PGP-based signing, the supplier generates their key pair on a hardware security module (HSM) or at minimum on an air-gapped workstation, exports the public key, and delivers it to the OEM through an authenticated out-of-band channel — not the same portal used for SBOM delivery. The OEM verifies the key fingerprint through a separate communication channel (phone call, signed contract document) before adding it to the trusted keyring.
Key rotation should occur on a defined schedule (annually at minimum) and immediately upon personnel changes, suspected compromise, or algorithm deprecation. Each rotation requires updating the OEM’s trusted keyring and potentially re-signing historical SBOMs if the old key is being revoked rather than simply expired. For Sigstore-based signing, key rotation is inherently handled: ephemeral certificates are issued per signing event, so there are no long-lived keys to rotate. The supplier’s OIDC identity remains the trust anchor, and changes to that identity (domain changes, SSO provider migration) are the equivalent of key rotation events.
Root of Trust and Certificate Chains
For organizations with existing Public Key Infrastructure (PKI), SBOM signing can be integrated into the certificate hierarchy. The OEM operates a root CA or contracts with a trusted third-party CA. Suppliers request signing certificates from this CA, creating a certificate chain that the OEM can verify against a single root. This eliminates the need to maintain individual trust relationships with each supplier’s key — trust is transitive through the certificate chain.
The automotive industry already operates PKI infrastructure for V2X (Vehicle-to-Everything) communication certificates, secure boot code signing, and TLS-based telematics. Extending this infrastructure to cover SBOM signing leverages existing investment and operational expertise. The signing certificate should include a custom extension or key usage field that restricts it to SBOM signing, preventing a supplier from repurposing a code-signing certificate for SBOM attestation without explicit authorization. Certificate policies should specify the acceptable key algorithms (RSA-4096 or Ed25519 for long-term security) and validity periods.
Revocation Scenarios
Key compromise is not a matter of if but when across a supply chain with hundreds of participants. When a supplier’s signing key is compromised, the OEM must have a tested revocation procedure. For PGP, this means the supplier publishes a revocation certificate, and the OEM removes the key from its trusted keyring and adds it to a revocation list. All SBOMs signed with the compromised key after the estimated compromise date must be treated as untrusted and re-verified through alternative means — typically by requesting the supplier to re-sign them with a new key.
For PKI-based signing, the CA publishes a Certificate Revocation List (CRL) or responds to Online Certificate Status Protocol (OCSP) queries. The OEM’s verification pipeline must check revocation status during every signature verification, not just at key import time. A common failure mode is caching stale CRLs, which causes the pipeline to accept signatures from revoked certificates. For Sigstore, the transparency log provides a natural audit trail: if the supplier’s identity was compromised, all signing events from the compromised identity can be identified in Rekor and the corresponding SBOMs flagged for re-verification.
Archival Integrity Over Vehicle Lifecycles
Automotive vehicle platforms have lifecycles measured in decades. A vehicle launched in 2026 will still be on roads in 2041 and potentially beyond. SBOMs generated for that vehicle’s ECUs must remain verifiable, interpretable, and legally admissible for the entire period. This creates archival challenges that have no parallel in enterprise IT, where software is typically replaced every few years.
15-Year Retention Requirements
UNECE R155 requires OEMs to maintain cybersecurity management processes for the lifetime of vehicle types under their responsibility. ISO/SAE 21434 specifies that cybersecurity work products must be retained and accessible for auditing. The EU CRA requires documentation to be available for 10 years after the last product is placed on the market. For a vehicle platform produced from 2026 through 2032 with a 15-year on-road lifespan, this could mean retaining SBOMs until 2047 — over 20 years from creation.
Storage is the easy part. The harder challenge is ensuring that retained SBOMs remain verifiable. A PGP signature created with a 4096-bit RSA key in 2026 may be cryptographically weakened by advances in computing by 2040. The signing key will have expired. The PGP keyserver infrastructure may have changed. The SBOM format version may no longer be supported by current tooling. Each of these factors can render a technically valid archived SBOM practically unverifiable unless proactive measures are taken.
Format Migration and Re-Signing
SBOM formats evolve. CycloneDX has progressed from 1.0 through 1.6, with each version adding capabilities and sometimes changing schema structures. SPDX 3.0 introduced significant structural changes from 2.3. Over a 15-year retention period, the original SBOM format version will inevitably become legacy. Organizations must plan for format migration: converting archived SBOMs to newer format versions while preserving the original as a canonical reference.
Format migration requires re-signing. The migrated SBOM is a new document that the original supplier’s signature no longer covers. The OEM should sign the migrated version with its own key, creating a chain of custody: the original SBOM carries the supplier’s signature, and the migrated version carries the OEM’s signature along with a reference to the original. Both versions are retained. This dual-retention approach satisfies regulatory requirements for original documentation while ensuring the SBOM remains usable with current tooling.
Long-Term Signature Validation (LTV)
Long-Term Validation (LTV) is a technique from the document signing world (PDF Advanced Electronic Signatures, PAdES) that embeds all information needed for future signature verification directly into the signed artifact. For SBOM signing, LTV means including the complete certificate chain, the OCSP response or CRL proving the certificate was not revoked at signing time, and a trusted timestamp from a Time Stamping Authority (TSA).
With LTV, a verifier in 2040 does not need to contact the original CA, check a potentially defunct OCSP responder, or locate a keyserver to verify a 2026 signature. All verification material is bundled with the SBOM. Sigstore provides a form of LTV inherently: the Rekor transparency log entry contains the signing certificate, the proof of inclusion in the log, and the trusted timestamp. As long as the Rekor log (or a mirror of it) remains accessible, Sigstore signatures are independently verifiable regardless of the Fulcio CA’s current status.
For PGP-based signing, achieving LTV requires additional discipline: archiving the public key, any trust signatures, and a trusted timestamp alongside the SBOM and its detached signature. Without this bundle, a PGP signature from a key that has since expired or been removed from keyservers becomes unverifiable. Organizations choosing PGP for SBOM signing should establish an LTV archival procedure from day one, not as a retrofit years later when original keys are already lost.
Supply Chain Attack Scenarios Targeting SBOMs
Understanding how adversaries exploit the absence of SBOM signing motivates the investment in signing infrastructure. The following scenarios illustrate realistic attack paths that SBOM signing and verification directly prevent.
Scenario 1 — Malicious Dependency Injection via Unsigned SBOM
A Tier-2 supplier delivers a firmware update for a telematics control unit to the Tier-1 integrator. The delivery includes an SBOM listing 340 components. In transit through the shared file exchange portal, an attacker with access to the portal modifies the SBOM: they remove the entry for libcurl 8.5.0 (which has a known critical vulnerability, CVE-2024-XXXX) and add an entry for libcurl 8.7.0 (which is patched). The firmware binary itself is not modified — it still contains the vulnerable libcurl 8.5.0.
The Tier-1 integrator ingests the modified SBOM, runs vulnerability correlation, and finds no issues. The OEM receives the integrated software and its SBOM, also finding no issues. The vulnerable libcurl ships in production vehicles. When the vulnerability is eventually discovered through other means (a security researcher, a field incident), the investigation reveals that the SBOM was inaccurate, but the trail has gone cold. With SBOM signing, the modification would have been detected at the first verification gate: the Tier-2 supplier’s signature would not match the altered file.
Scenario 2 — SBOM Downgrade Attack
A supplier delivers a software update with an accompanying SBOM reflecting the new component versions. An attacker intercepts the delivery and replaces the current SBOM with a previously legitimate SBOM from an older software version. The older SBOM is authentically signed by the supplier — it was a real SBOM for a real previous release. But it does not describe the software being delivered.
The OEM’s verification gate checks the signature and finds it valid. The SBOM is accepted. However, the newer software contains a recently added dependency with a critical vulnerability that the old SBOM does not list. The vulnerability goes undetected. This attack is prevented by binding the SBOM signature to the specific software artifact it describes: the SBOM must include a cryptographic hash of the software deliverable, and the verification gate must confirm that hash matches the actual delivered binary. Timestamp validation also helps: if the SBOM’s signed timestamp predates the software build timestamp, the downgrade is detected.
Scenario 3 — Compromised Signing Key
An attacker compromises a Tier-1 supplier’s signing key through a phishing attack targeting a build engineer. With the key, the attacker can produce authentically signed SBOMs for any content. They modify a legitimate SBOM to remove entries for components with known vulnerabilities and re-sign it with the compromised key. The OEM’s verification gate accepts the signature because it matches a trusted key.
This scenario illustrates that signing alone is insufficient — it must be paired with key management rigor and complementary controls. Detection depends on anomaly monitoring: does the SBOM’s component count differ significantly from previous deliveries? Was the signing timestamp unusual (outside business hours, from an unexpected geographic location)? Did the supplier’s CI/CD system actually produce a build at the claimed timestamp? Cross-referencing the signed SBOM against independent build records, transparency logs (if using Sigstore), and historical baselines catches compromised-key attacks that signature verification alone cannot. When a key compromise is eventually detected, the revocation procedures described in the Key Management section enable rapid containment and re-verification of all affected SBOMs.
Key Takeaways
- SBOM signing is a foundational supply-chain control. An unsigned SBOM provides no assurance of integrity or authenticity. Treat SBOM signing as mandatory for every supplier exchange, not as an optional enhancement.
- Choose your signing mechanism based on your supply chain’s maturity. PGP detached signatures work everywhere with minimal tooling requirements. Sigstore keyless signing eliminates key management overhead and integrates naturally with CI/CD. CycloneDX native signing provides self-contained integrity for standardized toolchains.
- Automate verification at the OEM ingestion gate. Every SBOM must pass signature validation, signer identity confirmation, and content integrity checks before entering any downstream system. Make the gate non-bypassable.
- Implement immutable audit logs for every SBOM exchange. Append-only logs provide forensic traceability, compliance evidence, and tamper detection that extends beyond point-in-time signature verification.
- Plan key management before your first signature. Define provisioning, rotation, and revocation procedures for supplier signing keys. Consider PKI-based certificate chains to simplify trust management at scale.
- Design for 15-year archival from day one. Use Long-Term Validation (LTV) techniques to embed all verification material alongside signed SBOMs. Plan for format migration and re-signing as SBOM standards evolve.
- Model supply-chain attack scenarios. SBOM modification, downgrade attacks, and key compromise are realistic threats. Your verification pipeline must address each scenario with specific technical controls, not just generic signature checking.
- Bind SBOMs to their software artifacts. A signature proves the SBOM was not modified, but without a cryptographic binding (hash matching) between the SBOM and the software it describes, a valid SBOM can be paired with the wrong artifact. Always verify both the signature and the artifact hash.