COMPLIANCE.md: the file your downstream manufacturers need to see

Since 11 September 2026, manufacturers placing products with digital elements on the EU market have had to report actively exploited vulnerabilities under Article 14 of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). The early warning is due within 24 hours, the notification within 72 hours, and the final report within 14 days of a fix becoming available.

Those products are assembled from components, and a large share of those components are open source. A manufacturer with a 24-hour clock needs component facts quickly: affected versions, severity, the fixed release, and where advisories are published. From 11 December 2027 the rest of the Regulation applies, including the full manufacturer obligations in Article 13 and Annex I.

This article introduces COMPLIANCE.md, a repository file that sits next to SECURITY.md and answers those questions in the vocabulary of the CRA. We drafted it first for the Tauri projects, where The Commons Conservancy acts as open-source software steward through the Tauri Programme. The template at the end of this article is generalised so that any open-source project can adopt it.

What SECURITY.md leaves open

SECURITY.md tells a reporter how to disclose a vulnerability privately. That is necessary, and it maps to the coordinated vulnerability disclosure policy in Annex I, Part II, point 5. It says little about the other facts an integrating manufacturer must establish about a component.

Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source ones, so that those components do not compromise the product. Article 13(6) requires them to report any vulnerability they find in a component to whoever maintains it. Annex VII, point 2(b), then asks for technical documentation covering vulnerability handling, the software bill of materials (SBOM) and secure update distribution.

Each of those steps needs evidence from upstream. That evidence usually lives in CI configuration, release notes, advisory databases and the memory of maintainers. A manufacturer assembling a technical file has to reconstruct it per dependency, and the next manufacturer using the same dependency repeats the work.

COMPLIANCE.md gathers that evidence once, in the project's own repository, under the project's own control.

What the file is, and what it is not

COMPLIANCE.md is a transparency document. It records the project's role under the CRA, maps its security practice to the requirements its integrators must meet, and links to evidence. It has two intended readers: a manufacturer doing due diligence, and a market surveillance authority asking a steward about its policy under Article 24(2).

The file is deliberately not a conformity claim. Recital 18 places free and open-source software developed or supplied outside a commercial activity outside the manufacturer obligations. A project that issued a declaration of conformity or implied CE marking would blur its own legal position and could mislead the people relying on it.

COMPLIANCE.md does	COMPLIANCE.md does not
State the project's role and name its steward, if there is one	Declare conformity under Article 28 or authorise CE marking under Article 30
Map project practice to Annex I, Part II, with links to evidence	Replace the manufacturer's risk assessment under Article 13(2) and (3)
Show which Annex I, Part I properties the component supports	Decide whether a downstream product is in scope or how it is classified
Explain how to report under Article 13(6) and how to receive advisories	Act as a security attestation under Article 25
State the version support policy that feeds Article 13(8)	Warrant the absence of vulnerabilities

A manufacturer can cite the file in its technical documentation as evidence of due diligence on a component. It cannot cite the file as proof that its own product conforms.

How the template is structured

The template has a metadata header, twelve core sections and one optional section. Every project-specific value is a {{PLACEHOLDER}}, and the CRA citations are fixed so that files across an ecosystem stay comparable.

Section	Purpose	CRA anchor
Header	Project, licence, steward, policy link, security contact, attestation status, review date	Art. 24(1), 25; Annex I, Part II(6)
1. Purpose	States what the file is and is not	Art. 13(2), 28, 30
2. Regulatory basis	Lists the provisions cited and the application dates	Art. 71
3. Roles	Project, steward, integrators, contributors	Art. 3(13), 3(14), 3(48), 13(5), 13(6), 24; Recital 18
4. Steward policy	Links the Article 24(1) policy and any project deviations	Art. 24(1)
5. Vulnerability handling	Maps practice to the eight Part II requirements, with evidence	Annex I, Part II
6. Product properties	Splits Part I properties between component and manufacturer	Annex I, Part I(2)
7. Reporting and advisories	Private channel, advisory feeds, manufacturer timelines	Art. 13(6), 14, 15
8. Version support	Supported branches and end dates	Art. 13(8)
9. Documentation	Material a manufacturer can reference	Annex VII
10. Security attestation	Records whether an Article 25 attestation exists, and its scope	Art. 13(5), 25
11. Limits	What the file does not do	Art. 32
12. Maintenance	Review triggers	Art. 25, 26, 27
13. Commercial support (optional)	Where to obtain paid support or conformity services	None

Sections 5 and 6 do the heaviest work. Section 5 gives a manufacturer component-level evidence for its own Part II obligations. Section 6 sets out which security properties the component provides by default, and which ones the manufacturer must configure or build.

Projects without a steward can use the template too. They remove the steward rows and section 4, and state in section 3 that the project is maintained by its contributors without a supporting legal person.

Attestation under Article 25

Article 25 empowers the Commission to adopt delegated acts establishing voluntary security attestation programmes for free and open-source software. The article ties those programmes to Article 13(5), so their purpose is to make manufacturer due diligence on open-source components easier. Developers, users and other third parties would be able to have a component assessed against all or some of the Regulation's essential requirements.

No such delegated act has been adopted at the time of writing, so no attestation programme exists yet. The template still carries a dedicated section, for three reasons.

It states plainly that the project holds no attestation

It lets a project state plainly that it holds no Article 25 attestation. Audits, badges and self-assessments then cannot be read as one.

It spares projects a restructure later

When a programme is established, projects fill in fields they already have instead of restructuring the file.

It makes the reach of any future attestation explicit

The fields for programme, issuer, scope, versions covered and validity make the reach of any future attestation explicit. An attestation of a component will not transfer to a downstream product or replace that product's conformity assessment.

Work on the shape of these attestations has already started. The Eclipse Foundation's Cyber Resilience Attestations project is developing recommendations, reference templates and tooling for voluntary attestations of open-source projects. We will align section 10 of the template with the delegated act once the Commission adopts one.

The template

The full template is below, ready to copy into a repository root. Placeholders use {{DOUBLE_BRACES}} so that a simple search finds any value left unfilled before publication.

COMPLIANCE.md template, version 1.1.0

# COMPLIANCE.md

<!--
COMPLIANCE.md template, version 1.1.0, published by CrabNebula Ltd.
Copy this file to the repository root next to SECURITY.md.
Replace every {{PLACEHOLDER}}. Keep the CRA citations unchanged unless the
Regulation is amended. If an evidence cell cannot be filled, write
"Not yet in place" rather than describing an intended practice.
Projects without a steward: delete the steward rows and section 4, and
use the alternative text in section 3.2.
-->

| Field | Value |
|---|---|
| Project | {{PROJECT_NAME}} |
| Repository | {{REPOSITORY_URL}} |
| Package identifiers | {{e.g. crates.io: example; npm: @example/api}} |
| Licence | {{SPDX expression, e.g. Apache-2.0 OR MIT}} |
| Steward | {{LEGAL_PERSON, acting through PROGRAMME if applicable}} |
| Steward cybersecurity policy | {{URL}} |
| Security contact | {{security address or private advisory URL}} |
| Security attestation (Art. 25) | {{None: no programme established; see section 10}} |
| Template version | 1.1.0 |
| Last reviewed | {{YYYY-MM-DD}} |
| Reviewed by | {{Name, role}} |

## 1. Purpose

This document describes how {{PROJECT_NAME}} supports the obligations that Regulation (EU) 2024/2847 (the Cyber Resilience Act, "CRA") places on organisations that integrate this software into products with digital elements. It is a transparency document maintained by the project.

It is not an EU declaration of conformity within the meaning of Article 28. It does not authorise or imply CE marking under Article 30. It does not replace the cybersecurity risk assessment that a manufacturer must perform under Article 13(2) and (3).

## 2. Regulatory basis

The provisions cited here are drawn from Regulation (EU) 2024/2847, published in the Official Journal on 20 November 2024.

| Provision | Subject |
|---|---|
| Article 3(13), 3(14), 3(48) | Definitions: manufacturer, open-source software steward, free and open-source software |
| Article 13 | Obligations of manufacturers |
| Article 14 | Reporting obligations of manufacturers |
| Article 15 | Voluntary reporting |
| Article 24 | Obligations of open-source software stewards |
| Article 25 | Security attestation of free and open-source software |
| Article 64(10) | Administrative fines do not apply to open-source software stewards |
| Article 71 | Entry into force and application |
| Annex I, Part I | Cybersecurity requirements relating to the properties of products |
| Annex I, Part II | Vulnerability handling requirements |
| Annex VII | Content of the technical documentation |
| Recitals 18 and 19 | Treatment of free and open-source software and stewards |

The Regulation entered into force on 10 December 2024. Chapter IV, on notification of conformity assessment bodies, applies from 11 June 2026. Article 14 reporting obligations apply from 11 September 2026. All remaining provisions apply from 11 December 2027.

## 3. Roles under the CRA

### 3.1 This project

{{PROJECT_NAME}} is free and open-source software within the meaning of Article 3(48). Its source code is openly shared under the licence stated above, which permits use, study, modification and redistribution.

It is developed in the open and published without charge. {{PROJECT_OR_STEWARD}} does not supply it in the course of a commercial activity and does not place it on the market as a manufacturer. Recital 18 confirms that software developed or supplied outside a commercial activity is not covered by the manufacturer obligations. Nothing in this document accepts the role of manufacturer under Article 3(13).

### 3.2 Steward

{{LEGAL_PERSON}} is {{legal form and jurisdiction}}. It provides support on a sustained basis for the development of this project and works to ensure its viability. It therefore acts as the open-source software steward for this project within the meaning of Article 3(14).

<!-- No steward: replace 3.2 with "This project is maintained by its contributors. No legal person provides sustained support for its development, and no open-source software steward within the meaning of Article 3(14) is currently designated." -->

Article 24 sets out the steward's obligations:

1. Article 24(1): put in place and document in a verifiable manner a cybersecurity policy that fosters secure development and effective vulnerability handling, fosters voluntary reporting under Article 15, and addresses documenting, addressing and remediating vulnerabilities and sharing information within the community.
2. Article 24(2): cooperate with market surveillance authorities at their request, and provide the policy documentation on reasoned request.
3. Article 24(3): Article 14(1) applies to the steward to the extent that it is involved in development. Article 14(3) and (8) apply to the extent that severe incidents affect network and information systems the steward provides for development.

Article 64(10) provides that administrative fines do not apply to stewards. That provision does not reduce any commitment made in this document.

### 3.3 Integrators and manufacturers

If you build a product with {{PROJECT_NAME}} and place it on the Union market under your own name or trademark, you are likely to be its manufacturer under Article 3(13). Your obligations are set out in Article 13 and Annex I. The scope test in Article 2 and the classification in Annexes III and IV apply to your product, not to this component.

Two provisions concern this component directly:

- Article 13(5): when integrating third-party components, including free and open-source ones, you must exercise due diligence so that they do not compromise the cybersecurity of your product. Sections 5, 6, 9 and 10 support that due diligence.
- Article 13(6): if you identify a vulnerability in this component, you must report it to the person or entity maintaining it. Section 7 explains how.

### 3.4 Contributors

Contributions of code, review, documentation or triage do not make contributors manufacturers. Recital 18 is explicit on this point. The project does not ask contributors to accept CRA obligations.

## 4. Steward cybersecurity policy

The steward cybersecurity policy required by Article 24(1) is published at {{URL}}. This project applies it in full.

Project-specific deviations or additions: {{NONE, or list them}}.

## 5. Vulnerability handling: mapping to Annex I, Part II

These requirements are addressed to manufacturers. The project maps its practice to them so that manufacturers can rely on component-level evidence.

| Ref | Requirement (summary) | How this project addresses it | Evidence |
|---|---|---|---|
| II(1) | Identify and document vulnerabilities and components, including an SBOM in a commonly used machine-readable format covering at least top-level dependencies | {{e.g. lockfiles committed; CycloneDX or SPDX SBOM generated per release}} | {{link to SBOM artefact or workflow}} |
| II(2) | Address and remediate vulnerabilities without delay, including through security updates; where technically feasible, provide security updates separately from functionality updates | {{e.g. patch releases on supported branches}} | {{release policy link}} |
| II(3) | Apply effective and regular tests and reviews of security | {{e.g. dependency audit in CI, static analysis, fuzzing, external audits}} | {{CI and audit links}} |
| II(4) | Once a security update is available, share and publicly disclose information about fixed vulnerabilities | {{e.g. GitHub Security Advisories with CVE assignment; ecosystem advisory database}} | {{advisory index link}} |
| II(5) | Put in place and enforce a coordinated vulnerability disclosure policy | SECURITY.md in this repository | {{SECURITY.md link}} |
| II(6) | Facilitate sharing of information about potential vulnerabilities, including a contact address | {{e.g. private vulnerability reporting enabled}} | {{link}} |
| II(7) | Provide mechanisms to securely distribute updates | {{e.g. signed release artefacts; registry provenance attestations}} | {{signing key or provenance link}} |
| II(8) | Disseminate security updates without delay and free of charge, with advisory messages | All releases are free of charge. Advisories are published as described at II(4) | {{link}} |

## 6. Product properties: support for Annex I, Part I

A component cannot meet these requirements on a manufacturer's behalf. It can provide capabilities and defaults the manufacturer relies on. Add or remove rows to match the component.

| Ref | Property (summary) | Support provided by this project | Manufacturer responsibility |
|---|---|---|---|
| I(2)(a) | No known exploitable vulnerabilities at release | {{e.g. releases blocked on open advisories}} | Track advisories for the versions you ship |
| I(2)(b) | Secure by default configuration | {{describe defaults}} | Do not weaken defaults without a documented reason |
| I(2)(c) | Vulnerabilities can be addressed through security updates | {{e.g. update mechanism or guidance}} | Operate an update channel for your product |
| I(2)(d) | Protection from unauthorised access | {{e.g. permission model}} | Configure access to the minimum your product needs |
| I(2)(e) | Confidentiality of data | {{describe}} | Application data handling and encryption at rest |
| I(2)(f) | Integrity of data, commands, programs and configuration | {{describe}} | Integrity of your own assets and configuration |
| I(2)(j) | Limited attack surfaces | {{e.g. explicit allowlisting}} | Enable only the features you need |
| I(2)(k) | Exploitation mitigation | {{e.g. memory-safe language, sandboxing}} | Platform hardening of your build and packaging |

## 7. Reporting vulnerabilities and receiving advisories

### 7.1 Reporting to this project

Report suspected vulnerabilities through {{private reporting URL}} or to {{security contact}}. Do not open public issues for security reports. The project acknowledges reports within {{N}} working days and coordinates disclosure as described in SECURITY.md. Manufacturers reporting under Article 13(6) should say so in the report.

### 7.2 Receiving advisories

Advisories are published through {{channels}}. To receive them, {{watch security alerts, subscribe to the mailing list, or configure a dependency audit tool}}.

### 7.3 Timelines relevant to manufacturers

Since 11 September 2026, Article 14 requires a manufacturer that becomes aware of an actively exploited vulnerability in its product to submit an early warning within 24 hours and a notification within 72 hours. A final report follows no later than 14 days after a corrective or mitigating measure is available. Parallel timelines apply to severe incidents. Notifications go through the single reporting platform under Article 16.

Advisories from this project state affected versions, the nature of the vulnerability, severity, and the fixed version or mitigation, so that manufacturers have the component facts those notifications need.

### 7.4 Voluntary reporting

Article 15 allows manufacturers and other natural or legal persons, including stewards, to report vulnerabilities and incidents voluntarily to a CSIRT or to ENISA.

## 8. Version support and the support period

Article 13(8) requires a manufacturer to set a support period for its product, of at least five years unless the product is expected to be in use for less. This project's support policy is an input to that decision, not a substitute for it.

Versions receiving security fixes: {{supported branches and end-of-support dates}}. Manufacturers whose support period outlasts the project's support for a version must plan migration or maintain the component themselves.

## 9. Documentation available to manufacturers

| Material | Location | Annex VII point |
|---|---|---|
| Software bill of materials | {{link}} | 2(b); 8 on reasoned request |
| Security policy and disclosure process | {{SECURITY.md link}} | 2(b) |
| Security contact | {{link}} | 2(b) |
| Release signing and provenance | {{link}} | 2(b), secure distribution of updates |
| Security architecture documentation | {{link}} | 1 and 2(a) |
| Version support policy | {{link}} | 4 |
| External security audit reports | {{links, with dates and scope}} | 6 |

## 10. Security attestation (Article 25)

Article 25 empowers the Commission to adopt delegated acts establishing voluntary security attestation programmes for free and open-source software. Their purpose is to facilitate the due diligence obligation in Article 13(5). Developers, users and other third parties may use such a programme to have this component assessed against all or certain essential cybersecurity requirements or other obligations of the Regulation.

<!-- Keep the next paragraph until a delegated act under Article 25 is adopted. Then replace it with the programme reference and fill the table. -->

At the date in "Last reviewed", no delegated act under Article 25 has been adopted and no attestation programme has been established. This project therefore holds no security attestation under Article 25.

| Field | Value |
|---|---|
| Programme | {{None established, or delegated act reference}} |
| Status | {{None / Requested / Issued / Withdrawn / Expired}} |
| Requested by | {{developer, user or other third party}} |
| Issued by | {{body}} |
| Scope | {{requirements covered, e.g. Annex I, Part II in full}} |
| Versions covered | {{version range}} |
| Issued and valid until | {{YYYY-MM-DD to YYYY-MM-DD}} |
| Attestation document | {{link}} |

An attestation, once one exists, covers this component only. It does not transfer to a downstream product, and it does not replace the manufacturer's conformity assessment under Article 32. Manufacturers should check that the versions they ship fall within the versions covered.

Audits, certifications, badges or self-assessments obtained outside an Article 25 programme are listed in section 9. They are not described as an Article 25 attestation.

## 11. What this document does not do

This document is not an EU declaration of conformity or a CE marking. It is not itself a security attestation under Article 25; section 10 records whether one exists. It does not warrant the absence of vulnerabilities. It does not decide whether any downstream product is in scope of Article 2 or how it is classified under Annex III or IV. It is not legal advice. Manufacturers remain responsible for their own conformity assessment under Article 32.

## 12. Maintenance

This document is reviewed at least once per release cycle. It is also reviewed on any change to the steward policy, to supported versions or to attestation status. Further triggers are the adoption of a delegated act under Article 25, and publication of relevant harmonised standards or common specifications under Article 27, or Commission guidance under Article 26. Changes are recorded in the repository history.

## 13. Commercial support (optional)

Commercial support and conformity services for {{PROJECT_NAME}} are available from {{PROVIDER}} ({{contact}}). The provider is independent of the project and of its steward. Its services do not change the roles described in section 3.

Adopting it in your project

Adoption is mostly a matter of writing down what the project already does. Where the project does not yet do something, the file says so, which is more useful to a manufacturer than an optimistic description.

1. Copy the template and fill in the header

Copy the template to the repository root next to SECURITY.md, and fill in the header.

2. Settle the steward question

If a foundation or other legal person supports the project on a sustained basis, name it and link its Article 24(1) policy. If no such legal person exists, use the alternative text in section 3.2.

3. Fill section 5 from real tooling only

Link the CI workflow that produces the SBOM, the advisory index and the signing or provenance setup. Write "Not yet in place" where a practice does not exist.

4. Tailor section 6 to the component

A GUI framework, a cryptographic library and a CLI tool expose different properties, so remove rows that do not apply.

5. State version support and attestation status

State the version support policy in section 8 with concrete dates or rules, and record the attestation status in section 10.

6. Link the file from README and SECURITY.md

Link the file from the README and from SECURITY.md, so that people reading either document can find it.

7. Add a release checklist item

Add a release checklist item to review the "Last reviewed" field and the evidence links.

Stewards supporting several repositories should keep one canonical template and pin its version in each file's header. When the template changes, for example after harmonised standards are cited in the Official Journal, the version number shows which repositories still need updating.

Where CrabNebula fits

CrabNebula is the Tauri Programme's partner for commercial support and CE-marked versions of Tauri, as described in the partnership announcement. The optional section 13 of the template exists for this kind of arrangement. It lets a project point to a commercial provider without changing its own non-commercial role or its steward's position.

We publish the template under an open licence, and it is free to use in any project, Tauri-based or not. Feedback from maintainers and stewards is welcome, particularly on how sections 5 and 6 fit components outside the desktop application space. As harmonised standards under mandate M/606 are finalised and cited, we will revise the template and increment its version.

For commercial support, CE-marked Tauri builds, or help preparing a COMPLIANCE.md for your own project, contact us at contact@crabnebula.dev.