5. Machine-processable attestation

In modern software engineering, the transition from manual, document-heavy compliance to machine-processable attestations marks a critical evolution in how trust can be verified. At its core, a machine-processable attestation is a digital claim, encoded in formats like JSON or YAML, asserting that a specific security control, process or property has been met. Unlike static PDF reports that sit in a folder, these digital artefacts are ‘generatable’ and ‘consumable’ by automated systems, enabling frequent or event-driven updates and automated validation of security claims across the product supply chain.

Machine-processable means that automated systems should be able to validate, interpret and act on it without human interpretation. This requires elements such as defined field types and semantics, controlled values, structured representation of decision-relevant information and schema versioning. Structured fields should be preferred for information used in automated processing, with free text used where additional explanation is helpful.

By embedding these attestations directly into the development pipeline, security becomes an intrinsic part of the product’s DNA, rather than a post-development checkbox.

• During a product’s design and development, machine-processable formats allow architects to define security requirements as code, which can then be automatically mapped to implementation evidence.
• For verification, these attestations enable automated gatekeeping; for instance, a deployment system can be configured to block any container that lacks a valid, machine-signed attestation of a successful vulnerability scan by default.

Furthermore, machine-processable attestations solve the ‘transparency gap’ inherent in complex ecosystems. They provide a verifiable, tamper-evident trail of a product’s security posture from the source code to the final runtime environment. This level of transparency ensures that every stakeholder, from the developer to the end customer, has access to an objective, current view of the risk profile, effectively automating the trust relationship between producers and consumers.

Technical documentation can also benefit from machine-processable attestations. Instead of being created as a static snapshot at a particular point in time, the artefacts can help ensure that documentation stays accurate and current by displaying the security requirements, implementation evidence, and verification results.

This is a significant advantage, particularly in view of the CRA’s requirement that manufacturers maintain technical documentation. Such documentation can be kept up to date and supported by verifiable implementation and test evidence.

A manufacturer-issued attestation by itself is not proof that a product is secure. Attestation, verification and independent assessment are distinct activities. An attestation provides claims and links it to supporting evidence; verification checks the integrity, scope, currency and consistency of those claims and that evidence; and independent assessment can evaluate whether the controls and evidence are sufficient for the product and its risks.

For SME engineering teams, machine-processable attestation can support automation by employing these concepts:

• 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

When security requirements are demonstrable , engineering teams move away from security as an afterthought and instead treat security as a primary functional requirement, because it means that every design decision, from the choice of a library to the architecture of a database, should be accompanied by the creation of a machine-processable artefact. This active generation of evidence allows teams to catch architectural flaws during the design phase, long before code is committed or products are shipped.

Furthermore, while secure by default focuses on delivering products that are secure out of the box, verifiability provides the mechanism to ensure those defaults remain intact and effective. In a verifiable ecosystem, the default state is not just a configuration choice but a protected claim that can be automatically checked at every stage of the life cycle.

Using reusable attestation enables the manufacturer to directly include cybersecurity into the development process and enabling the integration of cybersecurity controls in small use case specific packages leveraging existing agile methods and can also be included in quality gates in agile project management and tooling, e.g. cybersecurity as part of Definition of Ready and Done in Scrum

Relying on machine-processable attestation enables manufacturer to reduce effort for due diligence and supply chain management. A structured attestation enables integrators to simply pinpoint necessary security properties for due diligence and enhances trust with evidences and additional verification.

This creates a fail-safe environment in which a system can refuse to operate if its attestations, such as signed proof that MFA is enforced or that the latest vulnerability scan was passed, are missing or invalid.

For SMEs, this automation eliminates the need for constant manual checks. It ensures that the product’s security baseline is both self-verifying and consistently visible to stakeholders.

Machine-processable attestations can also support procurement and supplier assessment. Customers, integrators and procurers can use such structured claims and evidence to compare products, verify security-relevant properties and identify areas that may require further assessment.

The ecosystem of machine-processable security has been rapidly evolving. Some of the key initiatives

include foundational frameworks like NIST’s Open Security Controls Assessment Language (OSCAL) (compliance as code), OWASP’s CycloneDX Attestations (CDXA) (native security

attestation) and SPDX 3.0 Security Profile , which provide the structural grammar for automating compliance and supply-chain transparency. Presented below are some of these initiatives in this area.

• OSCAL (21) . Developed by NIST, OSCAL is the premier model for compliance as code. It provides a standardised way to express security control catalogues, system security plans and assessment results. By using OSCAL, organisations can automate the generation of compliance documentation, allowing for continuous authorisation, whereby the status of security controls is updated in real-time as evidence is collected.
• CycloneDX (OWASP ECMA-424) (22) . While originally an SBOM format, CycloneDX has expanded into a full-stack transparency standard. Its attestation capabilities (CDXA) allow organisations to document claims about security requirements alongside generating a bill of materials. It also includes specialised modules like VEX to communicate whether a vulnerability actually affects a product, and it can produce a cryptographic bill of materials (CBOM) to inventory cryptographic assets for quantum readiness. CycloneDX Assessors Studio (23) provides an emerging open-source implementation for conducting structured assessments, collecting evidence, documenting claims and generating CycloneDX attestations.
• SDPX 3.0 Security Profile (24) . The security profile captures security-related information in a SPDX Security Document. Specifically, the properties and relationships specified in the security profile are in support of exchanging information about system vulnerabilities that may exist, the severity of those vulnerabilities, and a mechanism to express how a vulnerability may affect a specific element including if a fix is available.
• The Open Source Security Foundation (OpenSSF). OpenSSF leads several projects, including Security Insights (25), a specification that project teams can use to report security facts (like bug bounty information or security contacts) in a machine-processable YAML format. They also champion the OpenSSF Scorecard (26), which automatically assesses open-source projects against security best practices. OpenSSF Best Practices badge (27) provides machine-readable security criteria status for many OSS projects, including against the OpenSSF Baseline (28). Supply-chain Levels for Software Artifacts, or SLSA (29) (“salsa”) provides recommended machine-readable schemas for SLSA attestations.
• OWASP (Open Web Application Security Project). Beyond CycloneDX, OWASP projects like the ASVS (30) (Application Security Verification Standard) provide the underlying requirements that these machine-readable formats aim to verify. Newer initiatives like the MLSVS (Machine Learning Security Verification Standard) are extending these principles into the AI/ML domain.
• TC54 (Ecma International) (31): This technical committee is the formal standardisation body for CycloneDX. It focuses on the Transparency Exchange API, which aims to standardise how software transparency information (like SBOMs and attestations) is discovered and shared across the global supply chain.
• in-toto (32) . in-toto provides an open framework for expressing verifiable claims about software supply-chain activities. SLSA Provenance uses in-toto to describe where, when and how software artefacts were built and tools such as Sigstore Cosign (33) can sign and verify in-toto attestations.
• Device Security Passport (34) . The Device Security Passport (DSP) is intended to provide a structured, machine-readable record that consolidates relevant security information about an IoT component and makes it accessible to stakeholders across the supply chain.

This section describes an illustrative example of how security claims, supporting evidence and assessment results can be expressed in a structured, machine-processable format to describe aspects of a product’s security posture.

The example does not propose a new schema or prescribe a specific format; rather, it is intended to show the relationship between a security objective, its implementation and the evidence used to assess it. Existing standards and specifications may be used, separately or together, to represent this information.

The example follows a simple cascade pattern, in which each high-level security objective is linked to its implementation actions and the results used to verify it.

• Control layer (security objectives to be addressed)
  • Defines structured security objectives (e.g. ‘protection against unauthorised access’ or ‘secure update delivery’), which may be derived from secure by design and default principles and/or aligned with regulatory or recognised cybersecurity frameworks.
• Implementation layer (how controls are implemented)
  • Provides claims describing the technical controls implemented to satisfy each objective, together with references to supporting evidence (e.g. ‘Implementation of TLS 1.3 with AES-256 encryption’).
  • Details the specific tools (e.g. OpenSSL version, specific compiler flags), versions, configurations (e.g. ‘Strict-Transport-Security’ headers) and parameters used to instantiate the control.
• Assessment and verification layer (how claims and evidence are validated)
  • Links to verifiable outputs of automated validation processes, such as timestamped test results, static analysis (SAST) summaries and cryptographic hashes of build artefacts.

These layers do not need to be contained in a single document. Claims, SBOMs, vulnerability information, build provenance, test results and other evidence may be maintained as separate but linked machine-processable artefacts.

In cases where component identifiers (such as PURL (35), CPE (36) or SWHID (37)) are referenced, security claims and evidence can be linked to specific software libraries, firmware modules or hardware components listed in an SBOM. This allows a recipient to determine not only that a security activity was performed but also which components, product versions or builds were covered by the referenced assessment.

Given that this information may contain sensitive technical details, such as specific compiler flags, internal test logs or cryptographic configurations, it may be impractical or insecure to grant every stakeholder full visibility. Sensitive evidence does not need to be included in a single publicly accessible record. Manufacturers may separate the information into:

• a public attestation layer – cryptographically signed security claims, provenance information and other non-sensitive information that can be independently verified;
• a 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.