5.1 Demonstrability, verifiability and assurance

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

1. Overzicht

1.1 Referenties

1.2 Geïdentificeerde eisen

1.3 Gerelateerde regelingen

2. Geïdentificeerde eisen

3. Gerelateerde regelingen

• ENISA -