Category: Supply Chain Security · Cryptographic Attestation
Abstract
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.
The Problem: SBOMs Without Trust
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.
Integrity gaps
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.
Attestation gaps
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.
Provenance gaps
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?
The Architecture: Dual-Chain Verification
AxiomChain addresses these gaps through a dual-chain architecture that separates, and then cryptographically links, two distinct concerns.
Chain 1: Component Integrity Chain
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
- Cryptographic hashing at each lifecycle stage creates a verifiable lineage for every component.
- Drift detection is inherent: if a component's hash at deployment does not match its hash at scan time, the chain breaks visibly.
- The chain is append-only: historical records cannot be retroactively modified without invalidating subsequent attestations.
Chain 2: Remediation Provenance Chain
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
- Every security finding is linked to its remediation outcome, or explicit risk acceptance, through an auditable chain.
- Remediation is verified against the component integrity chain: a "patch applied" claim is validated against the component's updated hash.
- Risk acceptance decisions are recorded with the same evidentiary rigour as technical remediations, ensuring audit completeness.
The Link: Cross-Chain Attestation
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.
Practical Applications
Regulatory compliance
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.
Cyber insurance underwriting
Insurers increasingly require evidence of vulnerability management practices. AxiomChain provides verifiable proof of remediation timelines and risk acceptance decisions, directly supporting underwriting assessments.
Vendor risk management
When a customer asks "prove your software is secure," AxiomChain provides a portable attestation bundle that is independently verifiable without exposing internal infrastructure details.
Board and executive reporting
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.
Integration with the S3 Framework
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.
Current Status
AxiomChain is integrated into the AIOpenSec platform and is available to customers as part of the platform's attestation and compliance capabilities.
Further Reading
- The S3 Framework: Surface, Sequence, Seal
- On-Device Behavioural Pathway Analysis for Child Online Safety
Contact: [email protected]