+5.4 Illustrative example
---+5.4.1 Organisation of the example
---+5.4.2 SafeGate-X1 example
------+5.4.2.1 Threat model
------+5.4.2.2 Controls, defaults and verification
------+5.4.2.3 Applying the three layers
------+5.4.2.4 Illustrative example of third-party verification

5.4 Illustrative example

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.

1. Přehled

5.4.1 Organisation of the example

For the purposes of the example, the information is organised as shown below. This organisation is illustrative and does not define a schema, field names or a required implementation format.

Information groupFunction
Product identity and scopeDefines product identity, versioning, scope to which the information applies and the

manufacturer’s cryptographic signature

Control layerDefines structured security objectives aligned with requirements, security principles

and/or applicable security policies or regulations

Implementation layerMaps identified threats and security objectives to implemented controls, secure-default

settings and supporting implementation information

Assessment andRecords assessment results and links to supporting evidence, such as test results,
verification layerconfiguration checks, SBOMs and build-artefact hashes
5.4.2 SafeGate-X1 example

Scenario. Imagine you are the manufacturer of SafeGate-X1, a specialised hardware controller used to manage security gates and water valves in a factory.

The product:

  • a standalone Linux-based controller –it sits in a physical cabinet, not a cloud;
  • the application – a C++ binary that listens for ‘open/close’ commands and logs telemetry;
  • the user interface – a small local touch-screen and a restricted SSH port for maintenance.

The goal. You want to prove to your industrial clients that SafeGate-X1 is not just a black box and is built following the secure by design principles of least privilege , minimal attack surface, strong

identity and vulnerability and patch management .

Disclaimer: This Machine-processable attestation example and the SafeGate-X1 scenario are provided solely as conceptual models to illustrate the practical integration of secure by design principles into automated verification workflows. They do not constitute formal legal or technical advice and should not be treated as a definitive proof of compliance with specific regulatory frameworks, such as the EU Cyber Resilience Act, or as a substitute for certified audit processes.

1.1 Odkazy

1.2 Identifikované požadavky

1.3 Související regulace

2. Identifikované požadavky

Požadavky

3. Související regulace

Regulace