Category: Supply Chain Security · Cryptographic Attestation
Software supply chain attacks, from SolarWinds to the XZ Utils backdoor, have exposed a fundamental weakness in modern software delivery: the absence of a verifiable, tamper-evident link between what was built, what was scanned, and what was deployed. Software Bills of Materials (SBOMs) have emerged as a partial answer, but an SBOM is only as trustworthy as the process that generated it. This brief describes AxiomChain ↗, a dual-chain verification architecture that provides cryptographic attestation for SBOM integrity and remediation provenance across the software lifecycle.
Regulatory momentum behind SBOMs is accelerating. The US Executive Order 14028, the EU Cyber Resilience Act, and NIST SP 800-218 all mandate or strongly encourage SBOM generation. Organisations are producing SBOMs. The question is whether anyone can trust them.
Current SBOM workflows suffer from three structural weaknesses.
An SBOM generated at build time may not reflect what is actually running in production. Containers are patched, dependencies are hot-swapped, and configuration drift is endemic. There is no standard mechanism to verify that an SBOM remains accurate after generation.
Signing an SBOM proves who generated it. It does not prove that the security findings associated with its components were actually remediated. The gap between "vulnerability identified" and "vulnerability resolved" is where audit failures live.
When a downstream consumer, whether a customer, a regulator, or an insurer, receives an SBOM, they have no way to verify the chain of custody. Was this SBOM generated by an automated pipeline or manually curated? Were the associated security scans conducted by a qualified tool? Was remediation verified or merely claimed?
AxiomChain addresses these gaps through a dual-chain architecture that separates, and then cryptographically links, two distinct concerns.
The first chain tracks the identity and integrity of software components across the lifecycle. Each component, whether an open-source library, a proprietary module, or a container image, is assigned a cryptographic identity at the point of ingestion. As the component moves through build, test, scan, and deployment stages, each transition is recorded as an attested event.
This chain answers: Is this component the same one that was scanned, and is it the one that is running?
Key properties
The second chain tracks the security posture decisions made about each component. When a vulnerability scan identifies a finding, the finding is recorded. When a remediation action is taken, a patch applied, a compensating control implemented, or a risk accepted, that action is also recorded with its own attestation. The decision-maker, the timestamp, and the evidence are all captured.
This chain answers: Was this vulnerability actually fixed, by whom, and when, and can we prove it?
Key properties
The two chains are cryptographically linked through cross-chain attestation events. A remediation event on Chain 2 references the specific component state on Chain 1 that it addresses. This creates a tamper-evident bridge between "what exists" and "what was done about it."
The result is a single, verifiable record that a downstream consumer can audit without needing access to the organisation's internal security tooling.
Organisations subject to NIS2, the Cyber Resilience Act, or sector-specific regulations (PCI DSS 4.0, DORA) can generate compliance evidence as a byproduct of normal security operations, rather than as a separate manual exercise.
Insurers increasingly require evidence of vulnerability management practices. AxiomChain provides verifiable proof of remediation timelines and risk acceptance decisions, directly supporting underwriting assessments.
When a customer asks "prove your software is secure," AxiomChain provides a portable attestation bundle that is independently verifiable without exposing internal infrastructure details.
The dual-chain model translates naturally into board-level assurance: here is what we found, here is what we did about it, and here is the cryptographic proof.
AxiomChain serves as the Seal phase of the S3 Framework (Surface, Sequence, Seal). Findings discovered during the Surface phase and contextualised during the Sequence phase are attested and sealed through AxiomChain, creating a closed-loop workflow from discovery through verified remediation.
AxiomChain is integrated into the AIOpenSec platform and is available to customers as part of the platform's attestation and compliance capabilities.
Read more at axiomchain.io → ↗
Contact: [email protected]