Technical documentation

Annex VII of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) gives the minimum content of the technical documentation of a product (Art. 31). This page maps each item of Annex VII to the document in this repository that covers it, or marks it as a gap.

Probably no party is a manufacturer of Fediversity now (Legal roles). Thus no party must keep this documentation now. A party that becomes a manufacturer can use these documents as a part of its technical documentation. That party adds the facts of its product, closes the gaps, signs the EU declaration of conformity, and keeps the documentation for at least 10 years (Art. 13(13)). The documents are public. For open-source software in Annex III, this lets the manufacturer use internal control (module A) for the conformity assessment (Art. 32(5)).

Pending review by a lawyer. This page is not legal advice. See Legal roles.

When you change a document on this page, keep the document in a state that a manufacturer can use. When a pull request closes a gap of this page, change the row of that gap to the document.

Annex VII items

Item	Content	Document	State
1(a)	The intended purpose.	The goals in `README.md`, and the actors in Concepts.	Covered.
1(b)	The versions of the software that affect the compliance with the essential requirements.	The release scheme and the supported versions in `SECURITY.md`: a signed tag `YYYY.MM` identifies each release. The SBOM of each node of `main`, with the commit as its version.	Covered.
1(c)	For a hardware product: photographs or illustrations of the external features, the marking and the internal layout.		Not applicable. Fediversity is software.
1(d)	The information and instructions for the user of Annex II.	The contact for vulnerability reports, the disclosure policy, and the support period with its end date in `SECURITY.md`. The instructions for the use and the updates in the hosting provider guide and the maintainer guide. The personal data and the erasure in Data protection.	Partial. The manufacturer adds its name and contact, the identification of the product and the address of the EU declaration of conformity.
2(a)	The design and development, with the system architecture: how the software components build on or feed into each other.	The specifications, Configuration data flow and Contracts (RFC 189) with their diagrams, the data model and Concepts.	Covered.
2(b)	The vulnerability handling processes: the SBOM, the coordinated vulnerability disclosure policy, the contact address, and the secure distribution of updates.	The policy, the contact address and the signed release tags in `SECURITY.md`. The SBOM. The daily `vulnix` scan in the threat model. The pinned sources and the signed store paths in Upstream and caches to the Nix store, and the CD controls in Forge to CI and CD.	Partial. Known CVEs wait for a fix (#2177, #2208).
2(c)	The production and monitoring processes, and the validation of these processes.	The checks of a change in `CONTRIBUTING.md` and in Check a change without a deploy. The test harness specification. The license report specification. The deploy from CI in Deploy from CI.	Partial. No document tells how these processes are validated.
3	The assessment of the cybersecurity risks (Art. 13), with how the essential requirements of Annex I, Part I apply.	The threat model.	Partial. The threat model does not show how each essential requirement of Annex I, Part I applies.
4	The information that was used to set the support period (Art. 13(8)).	The support period in `SECURITY.md`: 5 years from each release, the minimum of Art. 13(8). A hosting provider runs a deployment for many years, and the monthly releases replace each other, thus a shorter period does not agree with the expected use.	Covered. A manufacturer that sets a different support period adds its reasons.
5	The harmonised standards, common specifications or certification schemes that were applied. If none were applied, the solutions for the essential requirements of Annex I, Parts I and II.		Gap. No document lists the standards, or maps the solutions to the essential requirements.
6	The reports of the tests that verify the conformity of the product and of the vulnerability handling processes with Annex I, Parts I and II.	The checks and the NixOS tests that CI runs on each pull request (Write a NixOS test). The forge shows the result of each run.	Gap. No report maps the tests to the essential requirements.
7	A copy of the EU declaration of conformity (Annex V).		Gap. Only a manufacturer signs it. A steward does not (recital 19).
8	The SBOM, on a reasoned request of a market surveillance authority.	The SBOM of each node of `main`, and the SBOM of each deployment from the API (`GET /sbom/{deployment_id}`).	Covered. The registry keeps each version, see Retention.