Machine-processable attestation
Section 5 of the ENISA Secure by Design and Default Playbook asks what it would take for a security claim to be checked by a machine rather than read by a person. It answers with a cascade, a disclosure split and a survey of eleven formats. It deliberately answers with no schema at all.
Read this before you build on it
Section 5 states three times over that it defines nothing. It “does not propose a new schema or prescribe a specific format”, its information grouping “is illustrative and does not define a schema, field names or a required implementation format”, and the field names in its worked example are “illustrative only”. The example itself carries a disclaimer that it is a conceptual model and is not a definitive proof of compliance with the CRA.
That is worth taking at face value. Anyone selling you an ENISA attestation format has invented it. What the section does give you is vocabulary that is stable enough to design against, and a clear statement of the thing most attestation projects get wrong, which is that a manufacturer asserting something about itself is not evidence.
ENISA separates three activities that tend to get collapsed into one. An attestation provides claims and links them to supporting evidence. Verification checks the integrity, scope, currency and consistency of those claims and that evidence. Independent assessment evaluates whether the controls and evidence are sufficient for the product and its risks. A signed JSON file gets you the first one only.
The four properties
ENISA puts four properties to SME engineering teams. They are reproduced here in full because the distinction between them carries the argument, and summarising tends to collapse demonstrability into verifiability. The first is about what you produce, the second about what someone else can check, and the last two about whether any of it survives contact with a supply chain.
Demonstrability
The proactive capacity of a system and its development process to provide objective, machine-processable evidence that specific security requirements have been implemented. It represents the shift from “claiming” security in a static document to “showing” security through generated artefacts, such as signed build logs, automated test results, and standardised metadata.
Verifiability
The ability for an independent party, whether an automated tool, a customer, or a regulator, to programmatically authenticate and validate the integrity of security claims. A verifiable system ensures that attestations are transparent, tamper-evident, and mapped to a recognised root of trust, allowing for the continuous, low-friction audit of a product’s security posture.
Reusability
The ability to use existing attestations for further build on existing developments directly integrating cybersecurity in the development cycle and enabling an continuous cybersecurity improvement with minimal effort.
Reliability
The ability to rely on existing attestations also for third party components, simplifying due diligence based on a structured attestation demonstrating security properties of a component with additional option for third party verification
The cascade
Each security objective links to the actions that implement it and to the results that verify it. ENISA is explicit that the layers need not live in one document, and that claims, SBOMs, vulnerability information, build provenance and test results may be separate but linked artefacts. Where component identifiers such as PURL, CPE or SWHID are used, a recipient can tell not only that a security activity happened but which components, versions and builds it covered.
The note under each layer is our own assessment rather than ENISA’s, and it is the short version of where this platform actually stands. 2 of the 4 layers have a machine-readable output today.
Product identity and scope
Defines product identity, versioning, scope to which the information applies and the manufacturer’s cryptographic signature
On this platform Held per product, and carried into the Annex VII technical dossier export. Not signed, and not published as a standalone artefact.
Control layer
Defines structured security objectives aligned with requirements, security principles and/or applicable security policies or regulations
On this platform Two OSCAL catalogs are published at /oscal, one for the CRA vulnerability-handling articles and one for EN 40000-1-3, cross-linked as a crosswalk.
Implementation layer
Maps identified threats and security objectives to implemented controls, secure-default settings and supporting implementation information
On this platform At platform level, an OSCAL component-definition at /oscal states which EN 40000-1-3 clauses this platform implements and by what. Per product it is present as data, since the threat model, the Annex I applicability decisions and the secure by design release gates all record it, but that leaves the platform as a document rather than as structured claims.
Assessment and verification layer
Records assessment results and links to supporting evidence, such as test results, configuration checks, SBOMs and build-artefact hashes
On this platform Partly present. Evidence links, sign-offs and SBOM findings are recorded, and CSAF advisories are machine-readable. There is no OSCAL assessment-results output and no evidence hashing.
2 of the 4 layers have no machine-readable output here yet. Saying so is cheaper than being found out by an integrator who asked for one.
Not everything belongs in public
Attestation evidence contains compiler flags, internal test logs and cryptographic configuration. ENISA says plainly that granting every stakeholder full visibility may be impractical or insecure, and splits the record in two. This is the part of section 5 with the clearest product consequence, because it decides what a public artefact can contain before anyone argues about its format.
Public attestation layer
cryptographically signed security claims, provenance information and other non-sensitive information that can be independently verified
Restricted technical overlay
detailed test results, tool configurations, build parameters and other sensitive evidence, made available to authorised recipients through an authenticated and access-controlled API endpoint, such as the Transparency Exchange API
The format landscape
ENISA surveys the ecosystem rather than picking a winner. 3 of the 11 are already in play here, and the label on each row says which and in which direction.
NIST's compliance-as-code model. Expresses control catalogues, system security plans and assessment results, so the status of a control can be updated as evidence arrives rather than restated in a document each cycle.
Two catalogs and one component-definition, for the control and implementation layers. No assessment-results, because those are per-product data rather than a publishable file.
OWASP's SBOM format, standardised as ECMA-424, extended into full-stack transparency. Documents claims about security requirements alongside the bill of materials, and includes VEX for whether a vulnerability actually affects a product and CBOM for cryptographic inventory.
CycloneDX SBOMs are ingested for component and findings tracking. Attestations are not produced.
Carries vulnerability information inside an SPDX document, including severity and how a vulnerability affects a given element, and whether a fix exists.
SPDX SBOMs are ingested. The security profile is not read.
A YAML specification for projects to publish security facts such as bug bounty details and security contacts in machine-processable form.
Automated assessment of open-source projects against security best practices.
Machine-readable criteria status for open-source projects, including against the OpenSSF Baseline.
Supply-chain Levels for Software Artifacts. Recommended schemas for build-provenance attestations, expressed using in-toto.
A framework for verifiable claims about supply-chain activities, describing where, when and how an artefact was built. Sigstore Cosign signs and verifies these attestations.
The Application Security Verification Standard, which supplies the underlying requirements the machine-readable formats aim to verify. MLSVS extends the same idea to machine learning.
Standardises how transparency information such as SBOMs and attestations is discovered and shared across the supply chain. ENISA names it as the way to serve the restricted overlay.
A structured machine-readable record consolidating the security information about an IoT component for stakeholders along the supply chain.
Definitions and the information-group table from Secure by Design and Default Playbook version 1.0, section 5, by European Union Agency for Cybersecurity (ENISA), ISBN 978-92-9204-802-0, doi 10.2824/4422633, licensed under CC BY 4.0. Section 5 definitions and the information-group table are reproduced unaltered. The surrounding commentary, the framework annotations and the assessment of what this platform emits today are ours.
Start with the layer that already has an output
The control layer is the one you can publish today. Our CRA and EN 40000-1-3 control catalogues are served as OSCAL, and the 22 secure by design playbooks give you the implementation layer in the shape a technical file wants it, even before anyone agrees on a format for it.