# Référence CRA > Le référentiel public sur le règlement (UE) 2024/2847 : périmètre et obligations, nomenclatures logicielles (SBOM), licences open source, traitement des vulnérabilités et sécurité de la chaîne d'approvisionnement. Un cadre commun, deux parcours — Juridique et Cybersécurité. Available in 2 language(s): Français (fr), English (en). The same content is published in every language under a distinct URL prefix. Pages are grouped by section; the first item of each group is the section landing page. ## Français (fr) - [Accueil](https://cra-reference.eu/fr/) ### Démarrer - [Démarrer](https://cra-reference.eu/fr/demarrer/): Comment ce site est organisé, quel parcours suivre selon votre équipe, et les quinze termes à connaître avant d'ouvrir le règlement. - [Parcours Cyber en 10 étapes](https://cra-reference.eu/fr/demarrer/parcours-cyber/): Un chemin de lecture linéaire d'une trentaine de minutes, de la génération d'un SBOM à la procédure de signalement à 24 heures, pour un ingénieur qui découvre le Cyber Resilience Act. - [Parcours Juridique en 10 étapes](https://cra-reference.eu/fr/demarrer/parcours-legal/): Un chemin de lecture linéaire d'une trentaine de minutes, de la qualification du produit à l'apposition du marquage CE, pour un juriste qui découvre le Cyber Resilience Act. ### Le cadre CRA - [Le cadre CRA](https://cra-reference.eu/fr/cra/): Le règlement (UE) 2024/2847 : identité du texte, périmètre, exclusions, classes de criticité, exigences essentielles, période de support, logiciel libre, signalement, calendrier et sanctions. - [Articulation avec les autres réglementations](https://cra-reference.eu/fr/cra/articulation-autres-textes/): NIS 2, Cybersecurity Act, règlement IA, RED, Machines, GPSR, DORA, RGPD, responsabilité du fait des produits : où le CRA s'arrête, où il recoupe, et comment mutualiser les preuves. - [Le calendrier](https://cra-reference.eu/fr/cra/calendrier/): Les trois dates d'application, le régime transitoire, la dérogation qui soumet le parc historique au signalement, et le rétroplanning interne qui en découle. - [Les classes de criticité](https://cra-reference.eu/fr/cra/classes-de-criticite/): Par défaut, Important classe I, Important classe II, Critique : la classification détermine si un organisme notifié est obligatoire, donc le coût, le délai et le chemin critique du projet. - [Produits critiques](https://cra-reference.eu/fr/cra/classes-de-criticite/critique/): Annexe IV : boîtiers de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés. Régime renforcé et possible obligation de certification EUCC. - [Important — classe I](https://cra-reference.eu/fr/cra/classes-de-criticite/important-classe-1/): Annexe III, partie I : navigateurs, gestionnaires de mots de passe, VPN, antivirus, SIEM, routeurs, gestion d'identités. Trois voies d'évaluation, dont une conditionnée aux normes harmonisées. - [Important — classe II](https://cra-reference.eu/fr/cra/classes-de-criticite/important-classe-2/): Annexe III, partie II : systèmes d'exploitation, hyperviseurs, pare-feu, IDS/IPS, microprocesseurs résistants à l'altération. L'auto-évaluation est exclue, l'organisme notifié est obligatoire. - [Méthode de classification](https://cra-reference.eu/fr/cra/classes-de-criticite/methode/): Le questionnement à suivre pour classer un produit, la fiche de classification à produire, et le registre consolidé du portefeuille. - [Catégorie par défaut](https://cra-reference.eu/fr/cra/classes-de-criticite/par-defaut/): Ce que signifie l'auto-évaluation : le module A, ce qu'il dispense et surtout ce qu'il ne dispense pas, et le risque réel d'un dossier auto-déclaré mais vide. - [Le dossier technique (annexe VII)](https://cra-reference.eu/fr/cra/dossier-technique/): Le plan type du dossier, où s'y place le SBOM, la durée de conservation de dix ans, et la liste de complétude à cocher avant la revue de mise sur le marché. - [L'évaluation de la conformité](https://cra-reference.eu/fr/cra/evaluation-de-conformite/): Présomption de conformité, normes harmonisées et demande M/606, modules A, B+C et H, organismes notifiés, certification EUCC, et mesures de soutien aux PME. - [Les exclusions du champ d'application](https://cra-reference.eu/fr/cra/exclusions/): Dispositifs médicaux, véhicules, aviation, équipements marins, défense, pièces détachées, logiciel libre non commercial : ce que le règlement laisse hors de son champ, et les faux amis. - [Les exigences essentielles](https://cra-reference.eu/fr/cra/exigences-essentielles/): L'annexe I : treize exigences de sécurité du produit en partie I, huit obligations de traitement des vulnérabilités en partie II. Le fond du règlement, identique pour toutes les classes. - [Sécurité du produit (annexe I, partie I)](https://cra-reference.eu/fr/cra/exigences-essentielles/securite-des-produits/): Les treize exigences de conception : configuration sécurisée par défaut, absence de vulnérabilité exploitable connue, chiffrement, intégrité, minimisation des données, journalisation, effacement sécurisé. - [Traitement des vulnérabilités (annexe I, partie II)](https://cra-reference.eu/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/): Les huit obligations de processus : SBOM, correction sans délai, tests réguliers, publication des avis, politique CVD, partage d'informations, diffusion sécurisée et gratuite des correctifs. - [Le marquage CE](https://cra-reference.eu/fr/cra/marquage-ce/): Ce que le marquage signifie juridiquement, les sept conditions cumulatives préalables à son apposition, les règles de pose pour un logiciel, et le point de blocage commercial. - [Le logiciel libre et open source](https://cra-reference.eu/fr/cra/open-source/): Le critère n'est pas la licence mais la nature commerciale de la mise à disposition. Quatre statuts, du contributeur individuel hors périmètre au fabricant pleinement responsable. - [Développeur et contributeur individuels](https://cra-reference.eu/fr/cra/open-source/developpeur-individuel/): Ce qui fait, ou ne fait pas, basculer une activité libre dans le champ commercial : dons, forge, support facturé, financement d'entreprise, et la question de vos propres contributions. - [Intégrer de l'open source](https://cra-reference.eu/fr/cra/open-source/integrer-de-l-oss/): Votre situation la plus fréquente : la responsabilité réglementaire intégrale, l'obligation de diligence documentée, la remontée des correctifs à l'amont et le traitement des composants abandonnés. - [Le sponsor de logiciel libre](https://cra-reference.eu/fr/cra/open-source/sponsor-oss/): L'open-source software steward : définition, obligations effectivement dues, ce à quoi il n'est pas soumis — y compris les amendes — et la grille d'auto-qualification. - [Le périmètre : les produits comportant des éléments numériques](https://cra-reference.eu/fr/cra/perimetre-pde/): Définition du PDE, décomposition matériel / logiciel / traitement de données à distance, critères déclencheurs, notions de mise sur le marché et de modification substantielle. - [Le règlement (UE) 2024/2847](https://cra-reference.eu/fr/cra/reglement-2024-2847/): Identité, nature juridique, objectifs et structure du règlement sur la cyberrésilience, avec les repères de publication et les sources officielles à citer. - [Les acteurs et leurs responsabilités](https://cra-reference.eu/fr/cra/roles-et-responsabilites/): Fabricant, mandataire, importateur, distributeur, et la bascule de responsabilité en marque blanche. Les autorités : Commission, ENISA, CSIRT coordinateurs, surveillance du marché, organismes notifiés. - [Les sanctions](https://cra-reference.eu/fr/cra/sanctions/): Le barème à trois niveaux, les critères de modulation, les sanctions non pécuniaires — souvent plus lourdes que l'amende — et l'articulation avec la responsabilité du fait des produits. - [Le signalement à l'ENISA et aux CSIRT](https://cra-reference.eu/fr/cra/signalement-enisa/): L'obligation la plus proche : 24 heures, 72 heures, 14 jours ou un mois. Déclencheurs, définition de l'exploitation active, plateforme de signalement unique, confidentialité et champ temporel élargi. - [Période de support et cycle de vie](https://cra-reference.eu/fr/cra/support-et-cycle-de-vie/): Cinq ans minimum ou la durée de vie attendue, dix ans de disponibilité des correctifs, obligation d'information de l'acheteur, fin de support et cessation d'activité : l'engagement de long terme du CRA. - [La surveillance du marché](https://cra-reference.eu/fr/cra/surveillance-du-marche/): Pouvoirs des autorités, procédure applicable aux produits présentant un risque significatif, non-conformité formelle, opérations coordonnées, et la fiche réflexe en cas de demande. ### Le SBOM - [Le SBOM](https://cra-reference.eu/fr/sbom/): La nomenclature logicielle : définition, exigence du CRA, formats CycloneDX et SPDX, typologies, qualité, identifiants, VEX, licences SPDX, signature, diffusion et cycle de vie. - [Le cycle de vie du SBOM](https://cra-reference.eu/fr/sbom/cycle-de-vie/): Un SBOM par construction, immuable et versionné ; conservation alignée sur le dossier technique ; archivage, indexation, restitution et comparaison entre versions. - [Qu'est-ce qu'un SBOM](https://cra-reference.eu/fr/sbom/definition/): Définition accessible aux deux équipes, données minimales attendues par composant, usages par public, et ce que le SBOM n'est pas. - [Diffusion et confidentialité](https://cra-reference.eu/fr/sbom/diffusion-et-confidentialite/): Faut-il publier son SBOM ? Niveaux de diffusion, clauses contractuelles, régime de confidentialité des informations transmises aux autorités, et la matrice décisionnelle. - [Ce que le CRA exige du SBOM](https://cra-reference.eu/fr/sbom/exigence-cra/): Le texte exact, le décryptage de ses trois expressions clés, la question de la publication, l'habilitation de la Commission, et la chaîne qui mène au marquage CE. - [Les formats](https://cra-reference.eu/fr/sbom/formats/): CycloneDX et SPDX : origines, normalisation, points forts respectifs, comparatif, et le choix d'un format pivot avec export vers l'autre. - [CycloneDX](https://cra-reference.eu/fr/sbom/formats/cyclonedx/): Le format de l'OWASP normalisé ECMA-424 : structure du document, extensions BOM, prise en charge native du VEX, et exemple commenté. - [SPDX](https://cra-reference.eu/fr/sbom/formats/spdx/): Le format de la Linux Foundation normalisé ISO/IEC 5962 : structure, profils SPDX 3, liste et expressions de licence faisant autorité, et exemple commenté. - [Les identifiants de composants](https://cra-reference.eu/fr/sbom/identifiants/): PURL, CPE, SWID, empreintes : pourquoi l'appariement entre un composant et une vulnérabilité est la cause numéro un des faux positifs, et comment le fiabiliser. - [La licence comme donnée du SBOM](https://cra-reference.eu/fr/sbom/licences-spdx/): Identifiants et expressions SPDX, ce que le SBOM permet de calculer en matière de conformité juridique, et la qualité de donnée sans laquelle rien n'est exploitable. - [Qualité, complétude et profondeur](https://cra-reference.eu/fr/sbom/qualite-et-completude/): Critères de qualité d'un SBOM, notation automatisée, seuils bloquants en CI, profondeur des dépendances transitives, et les sept pièges qui produisent des inventaires faux. - [Signature et intégrité](https://cra-reference.eu/fr/sbom/signature-et-integrite/): Pourquoi un SBOM non signé n'est pas une preuve : signature, attestations de provenance, niveaux SLSA, builds reproductibles et journal de transparence. - [Les six types de SBOM](https://cra-reference.eu/fr/sbom/typologies/): Design, source, build, analyzed, deployed, runtime : ils ne décrivent pas la même chose et ne se valent pas. Lequel verser au dossier technique. - [VEX : l'exploitabilité](https://cra-reference.eu/fr/sbom/vex/): Le mécanisme qui distingue « traité » d'« ignoré » : statuts, justifications normalisées, implémentations CycloneDX, OpenVEX et CSAF, et valeur juridique de la décision de ne pas corriger. ### Licences open source - [Licences open source](https://cra-reference.eu/fr/licences/): Les familles de licences libres, ce qui déclenche réellement leurs obligations, et neuf scénarios de distribution réels — du backend SaaS à l'objet connecté — avec le verdict par famille. - [Les familles de licences](https://cra-reference.eu/fr/licences/familles/): Domaine public, permissives, copyleft faible par fichier ou par bibliothèque, copyleft fort, copyleft réseau, source-available, licences de contenu : ce que chacune impose réellement. - [Ce qui déclenche une obligation](https://cra-reference.eu/fr/licences/mecanismes/): Distribution, interaction réseau, œuvre dérivée, liaison statique ou dynamique, simple agrégation, produit de consommation, brevets : les huit mécanismes qui font qu'une licence mord — ou pas. - [Les pièges qui échappent à la matrice](https://cra-reference.eu/fr/licences/pieges/): Changement de licence en amont, absence de licence, code copié, code généré par IA, assets, CLA, incompatibilités mutuelles : ce que la grille famille × scénario ne montre pas. - [Neuf scénarios de distribution](https://cra-reference.eu/fr/licences/scenarios/): Le même composant, neuf contextes : ce qui change, ce qui se déclenche, et le verdict par famille de licences pour chaque type de produit. - [Application bureau ou ligne de commande](https://cra-reference.eu/fr/licences/scenarios/application-bureau/): La distribution binaire classique — le cas d'école pour lequel la GPL a été écrite. Contraignant mais praticable, à condition de préparer la fourniture du source. - [Application mobile](https://cra-reference.eu/fr/licences/scenarios/application-mobile/): Distribution binaire plus conditions de magasin : le seul scénario où une licence libre peut être purement et simplement incompatible avec le canal de distribution. - [Bibliothèque ou SDK que vous publiez](https://cra-reference.eu/fr/licences/scenarios/bibliotheque-sdk/): Ici vous êtes l'amont : vos dépendances contraignent votre licence, et votre licence contraint vos utilisateurs. La contamination remonte et descend. - [Cas général — hypothèse la plus défavorable](https://cra-reference.eu/fr/licences/scenarios/cas-general/): La posture à adopter quand on ne sait pas encore comment le composant sera distribué : supposer la distribution binaire, l'exposition réseau et le produit de consommation. - [Embarqué et objets connectés](https://cra-reference.eu/fr/licences/scenarios/embarque-iot/): Le scénario le plus contraint, et le seul où une exigence de licence entre en tension directe avec une exigence de sécurité du CRA : l'anti-verrouillage de la GPL-3.0 contre le démarrage vérifié. - [Frontend web](https://cra-reference.eu/fr/licences/scenarios/frontend-web/): Le scénario le plus mal compris : servir du JavaScript à un navigateur est une distribution de code. Le bundler mélange tout, la minification efface les attributions. - [On-premise et auto-hébergé](https://cra-reference.eu/fr/licences/scenarios/on-premise/): Distribution complète chez le client, souvent système d'exploitation compris. Le client obtient le droit de redistribuer ce que vous lui avez livré. - [Outil interne](https://cra-reference.eu/fr/licences/scenarios/outil-interne/): Aucune distribution, donc presque aucune obligation — et le seul vrai risque : la frontière interne/externe qui bouge sans que personne ne rouvre le dossier. - [Backend SaaS](https://cra-reference.eu/fr/licences/scenarios/saas-backend/): Pas de distribution, donc la GPL est sans effet — et l'AGPL devient le risque numéro un. Le scénario où les intuitions sont le plus souvent fausses, dans les deux sens. ### Parcours Juridique - [Parcours Juridique](https://cra-reference.eu/fr/legal/): Les obligations du CRA vues par l'équipe Juridique et Conformité : marquage CE, dossier technique, déclaration UE, signalement, sanctions, contrats, licences, support et conservation des preuves. - [Liste de contrôle avant mise sur le marché](https://cra-reference.eu/fr/legal/checklist-mise-sur-le-marche/): Quinze points, une page, imprimable et signable. Le document qui matérialise le droit de veto du Juridique sur la commercialisation. - [Clauses contractuelles fournisseurs et clients](https://cra-reference.eu/fr/legal/clauses-contractuelles/): Les clauses à exiger en amont pour tenir vos propres délais, celles à négocier en aval, et le cas particulier des composants libres pour lesquels il n'existe aucun contrat. - [Conservation des preuves](https://cra-reference.eu/fr/legal/conservation-des-preuves/): Quels artefacts conserver, combien de temps, sous quelles garanties d'intégrité, et l'exercice annuel de restitution qui seul prouve que le dispositif fonctionne. - [La déclaration UE de conformité](https://cra-reference.eu/fr/legal/declaration-de-conformite/): Contenu obligatoire de l'annexe V, forme simplifiée de l'annexe VI, exigences linguistiques, modèle prêt à l'emploi et règles de mise à jour. - [Informations et instructions à l'utilisateur (annexe II)](https://cra-reference.eu/fr/legal/documentation-utilisateur/): Les dix mentions obligatoires à fournir avec le produit, le modèle de notice de cybersécurité, les exigences linguistiques et la durée de conservation. - [Marquage CE et dossier technique : le processus interne](https://cra-reference.eu/fr/legal/marquage-ce-et-dossier/): Qui constitue, qui relit, qui signe. Le workflow d'approbation, la porte de mise sur le marché et le procès-verbal de revue de conformité. - [Obligations de signalement : la décision juridique](https://cra-reference.eu/fr/legal/obligations-de-signalement/): Quand court le délai de 24 heures, qui décide, comment documenter la décision de signaler ou de ne pas signaler, et comment organiser l'astreinte juridique. - [Propriété intellectuelle et licences](https://cra-reference.eu/fr/legal/propriete-intellectuelle/): La politique de licences appliquée en CI, le processus d'exception, le registre, les livrables d'attribution et la préparation des audits clients. - [Exposition et registre des risques](https://cra-reference.eu/fr/legal/sanctions-et-exposition/): Chiffrer l'exposition administrative, commerciale et contractuelle ; tenir un registre des risques de conformité ; anticiper l'effet sur les diligences d'acquisition. - [Traduire la période de support en engagements](https://cra-reference.eu/fr/legal/support-contractuel/): Du texte du règlement aux conditions générales : mention obligatoire à l'acheteur, désynchronisation avec les fournisseurs, politique de fin de vie et registre. ### Parcours Cyber - [Parcours Cyber](https://cra-reference.eu/fr/cyber/): Les obligations du CRA vues par l'équipe Cybersécurité et DevSecOps : génération de SBOM, CI/CD, sécurité par conception, gestion des vulnérabilités, divulgation coordonnée, signalement, surveillance continue. - [Sécuriser la chaîne de construction](https://cra-reference.eu/fr/cyber/chaine-ci-securisee/): La chaîne qui produit et signe le SBOM est elle-même une surface d'attaque : les six façons d'exécuter du code dans un pipeline, l'attaque par proposition de modification, et les contre-mesures. - [Liste de contrôle technique](https://cra-reference.eu/fr/cyber/checklist-technique/): Quinze points à vérifier par produit avant la revue de conformité, imprimable, à joindre au dossier de la revue de mise sur le marché. - [Évaluer un composant open source](https://cra-reference.eu/fr/cyber/evaluer-un-composant/): Rendre calculable la diligence exigée par l'article 13, paragraphe 5 : les dix-huit contrôles d'OpenSSF Scorecard, ce qu'ils couvrent de la grille, ce qu'ils ne disent pas, et le cadre S2C2F pour l'ingestion. - [Maîtriser les faux positifs](https://cra-reference.eu/fr/cyber/faux-positifs/): Le risque de conformité par excès de bruit : causes racines, remèdes, politique de suppression datée et motivée, et l'indicateur à suivre. - [Générer un SBOM](https://cra-reference.eu/fr/cyber/generer-un-sbom/): Les cinq méthodes de génération selon le contexte, les familles d'outils, la matrice de choix par langage, et pourquoi il faut figer l'outillage par famille de produits. - [Gestion des vulnérabilités](https://cra-reference.eu/fr/cyber/gestion-des-vulnerabilites/): Le cycle complet de la détection à la clôture, les sources à agréger, la priorisation par score composite, les SLA de remédiation et le déclencheur automatisé du signalement. - [Incidents de référence](https://cra-reference.eu/fr/cyber/incidents/): Quatorze compromissions documentées et datées, du canal de mise à jour d'un éditeur au détournement d'une action de CI : ce qui s'est passé, ce qui aurait limité l'impact, et l'exigence du règlement que chacune éclaire. - [Intégration dans la CI/CD](https://cra-reference.eu/fr/cyber/integration-cicd/): Les huit étapes du pipeline cible, les règles de blocage, la gestion des dérogations, les monorepos et le coût en temps de construction. - [Mises à jour sécurisées](https://cra-reference.eu/fr/cyber/mises-a-jour-securisees/): Canal authentifié, signature, protection contre le retour arrière, mises à jour automatiques avec refus possible, séparation des correctifs, gratuité et cas de l'embarqué. - [La politique de divulgation coordonnée](https://cra-reference.eu/fr/cyber/politique-cvd/): Contenu d'une politique CVD, security.txt et RFC 9116, engagement de non-poursuite, normes ISO/IEC 29147 et 30111, article L. 2321-4, et la question de devenir CNA. - [Procédure 24 h / 72 h / 14 jours](https://cra-reference.eu/fr/cyber/procedure-24h/): Le runbook complet du signalement : détection, qualification, cellule, envois, information des utilisateurs, astreinte, exercices et fiche réflexe imprimable. - [Risques de chaîne d'approvisionnement](https://cra-reference.eu/fr/cyber/risques-supply-chain/): Typologie des attaques, ce que le SBOM permet et ne permet pas, les contre-mesures de durcissement de la chaîne de construction, et la cartographie de votre exposition. - [Sécurité par conception](https://cra-reference.eu/fr/cyber/secure-by-design/): Traduire l'annexe I partie I en exigences vérifiables : modélisation des menaces, analyse de risques, plan de tests, et les référentiels mobilisables en attendant les normes harmonisées. - [Surveillance continue](https://cra-reference.eu/fr/cyber/surveillance-continue/): Rejouer le SBOM chaque jour contre des sources qui bougent : architecture, EUVD et plateforme de signalement de l'ENISA, surveillance de l'amont, indicateurs. - [Verrouiller et mettre à jour les dépendances](https://cra-reference.eu/fr/cyber/verrouillage-dependances/): La tension centrale du sujet : figer pour reconstruire à l'identique pendant dix ans, et mettre à jour pour n'avoir aucune vulnérabilité exploitable connue. Fichiers de verrouillage, épinglage par empreinte, mise à jour automatisée et quarantaine. ### Organisation - [Organisation](https://cra-reference.eu/fr/organisation/): Deux niveaux d'outillage, une architecture cible, une matrice RACI, des instances de gouvernance, un contrat d'interface entre Juridique et Cyber, des indicateurs et une feuille de route. - [Architecture cible](https://cra-reference.eu/fr/organisation/architecture-cible/): Les flux de bout en bout, du dépôt de code au coffre de preuves ; les points de contrôle, la souveraineté des données et trois scénarios selon la maturité. - [Générer et piloter : les deux niveaux](https://cra-reference.eu/fr/organisation/deux-niveaux/): La distinction fondatrice entre la génération technique du SBOM au niveau de l'application et la centralisation pour le pilotage au niveau de l'organisation. Le CRA exige les deux. - [Feuille de route](https://cra-reference.eu/fr/organisation/feuille-de-route/): Six vagues de déploiement, du cadrage à l'amélioration continue, avec les jalons, les livrables et les dépendances entre elles. - [Instances de gouvernance](https://cra-reference.eu/fr/organisation/gouvernance/): Comité CRA, cellule PSIRT, revue de mise sur le marché, revue de la politique de licences : composition, fréquence, ordre du jour et décisions relevant de chaque niveau. - [Indicateurs](https://cra-reference.eu/fr/organisation/indicateurs/): Couverture, performance, risque et préparation : les indicateurs à suivre, ceux à ne pas suivre, et la maquette du tableau de bord de direction. - [Interface Juridique ↔ Cyber](https://cra-reference.eu/fr/organisation/interface-legal-cyber/): Le contrat d'interface entre les deux équipes : livrables croisés avec délais et formats, vocabulaire partagé et chemin d'escalade. - [Qui fait quoi — matrice RACI](https://cra-reference.eu/fr/organisation/raci/): La répartition des rôles sur les vingt activités du dispositif, et les trois arbitrages qui doivent être tranchés explicitement par le comité. ### Outils - [Outils](https://cra-reference.eu/fr/outils/): Les deux familles d'outillage : générateurs de SBOM insérés dans la chaîne de construction, et plateformes de pilotage du portefeuille. Fiches, comparatif et critères de choix. - [Critères de choix et protocole d'évaluation](https://cra-reference.eu/fr/outils/criteres-de-choix/): Une grille pondérée, un protocole d'évaluation sur vos propres artefacts, et la recommandation d'architecture outillée. - [Générateurs de SBOM](https://cra-reference.eu/fr/outils/generation/): Les outils du niveau application : Syft, Grype, Trivy, cdxgen, osv-scanner, ScanCode, OSS Review Toolkit et les plugins natifs de chaîne de construction. - [Plateformes de pilotage](https://cra-reference.eu/fr/outils/plateformes/): Les outils du niveau organisation : OWASP Dependency-Track, Snyk, FOSSA, Black Duck, Mend, Sonatype, JFrog Xray, GUAC — et ce qui les distingue vraiment. ### Direction - [Direction](https://cra-reference.eu/fr/direction/): Le CRA en cinq minutes pour un comité exécutif : l'exposition au marché, l'exposition financière, les décisions attendues et l'état d'avancement. - [Budget, ressources et scénarios](https://cra-reference.eu/fr/direction/budget/): Trois scénarios d'investissement avec leur risque résiduel, les postes à provisionner, les profils nécessaires et les arbitrages à trancher. - [Impact sur l'activité](https://cra-reference.eu/fr/direction/impact-business/): Risque d'accès au marché, exposition financière, coût de la conformité, opportunités commerciales et effet d'entraînement sur NIS 2, DORA et les questionnaires clients. ### Ressources - [Ressources](https://cra-reference.eu/fr/ressources/): Les gabarits, modèles, registres, listes de contrôle et fiches réflexes à reprendre : dossier technique, déclaration UE, notice utilisateur, politique CVD, gabarits de signalement, clauses. ### Cas pratiques - [Cas pratiques](https://cra-reference.eu/fr/cas-pratiques/): Dix scénarios déroulés de bout en bout : la question côté Juridique, la question côté Cyber, la décision, la preuve produite et l'enseignement. ### Auto-diagnostic - [Auto-diagnostic](https://cra-reference.eu/fr/diagnostic/): Une grille d'évaluation en cinq modules pour situer votre maturité, identifier les écarts prioritaires et mesurer la progression d'un trimestre à l'autre. ### Glossaire - [Glossaire](https://cra-reference.eu/fr/glossaire/): Les termes du CRA et du SBOM, en français et en anglais, avec le renvoi vers la page de référence. ### Questions fréquentes - [Questions fréquentes](https://cra-reference.eu/fr/faq/): Quarante réponses courtes aux questions les plus posées par les équipes Juridique et Cyber, chacune renvoyant à la page de référence. ### Veille réglementaire - [Veille réglementaire](https://cra-reference.eu/fr/actualites/): Ce qui bouge encore : normes harmonisées, actes délégués et d'exécution, désignation des autorités nationales. Le mécanisme qui empêche ce site de devenir faux. ### Divulgation des vulnérabilités - [Divulgation des vulnérabilités](https://cra-reference.eu/fr/securite/): La politique de divulgation coordonnée de ce site : périmètre, canal de signalement, délais d'engagement, engagement de non-poursuite et reconnaissance des chercheurs. ### À propos de ce site - [À propos de ce site](https://cra-reference.eu/fr/a-propos/): Objet, périmètre, gouvernance éditoriale, avertissement juridique, principes techniques et mentions légales. ### Contact - [Contact](https://cra-reference.eu/fr/contact/): Une seule adresse : signaler une erreur, proposer un contenu, poser une question — et ce que ce site ne fait pas. ## English (en) - [Home](https://cra-reference.eu/en/) ### Start here - [Start here](https://cra-reference.eu/en/start/): How this site is organised, which reading path suits your team, and the fifteen terms to know before opening the Regulation. - [Cyber path in 10 steps](https://cra-reference.eu/en/start/cyber-path/): A linear thirty-minute reading path, from generating an SBOM to the 24-hour reporting procedure, for an engineer new to the Cyber Resilience Act. - [Legal path in 10 steps](https://cra-reference.eu/en/start/legal-path/): A linear thirty-minute reading path, from qualifying the product to affixing the CE marking, for a lawyer new to the Cyber Resilience Act. ### The CRA framework - [The CRA framework](https://cra-reference.eu/en/cra/): Regulation (EU) 2024/2847: identity of the text, scope, exclusions, criticality classes, essential requirements, support period, open source, reporting, timeline and penalties. - [CE marking](https://cra-reference.eu/en/cra/ce-marking/): What the marking means legally, the seven cumulative conditions before affixing it, the rules for software, and the commercial gate it represents. - [Conformity assessment](https://cra-reference.eu/en/cra/conformity-assessment/): Presumption of conformity, harmonised standards and request M/606, modules A, B+C and H, notified bodies, EUCC certification, and support measures for SMEs. - [Criticality classes](https://cra-reference.eu/en/cra/criticality-classes/): Default, Important class I, Important class II, Critical: the classification determines whether a notified body is mandatory, and therefore the cost, the lead time and the critical path. - [Critical products](https://cra-reference.eu/en/cra/criticality-classes/critical/): Annex IV: hardware security boxes, smart meter gateways, smart cards and secure elements. A reinforced regime and a possible EUCC certification requirement. - [Default category](https://cra-reference.eu/en/cra/criticality-classes/default/): What self-assessment means: module A, what it removes and above all what it does not, and the real risk of a self-declared but empty file. - [Important — class I](https://cra-reference.eu/en/cra/criticality-classes/important-class-1/): Annex III, Part I: browsers, password managers, VPNs, antivirus, SIEM, routers, identity management. Three assessment routes, one of them conditional on harmonised standards. - [Important — class II](https://cra-reference.eu/en/cra/criticality-classes/important-class-2/): Annex III, Part II: operating systems, hypervisors, firewalls, IDS/IPS, tamper-resistant microprocessors. Self-assessment is excluded, a notified body is mandatory. - [Classification method](https://cra-reference.eu/en/cra/criticality-classes/method/): The line of questioning to classify a product, the classification sheet to produce, and the consolidated portfolio register. - [Economic operators and their responsibilities](https://cra-reference.eu/en/cra/economic-operators/): Manufacturer, authorised representative, importer, distributor, and the shift of responsibility in white-label arrangements. The authorities: Commission, ENISA, CSIRTs, market surveillance, notified bodies. - [Reporting to ENISA and CSIRTs](https://cra-reference.eu/en/cra/enisa-reporting/): The nearest obligation: 24 hours, 72 hours, 14 days or one month. Triggers, the meaning of active exploitation, the single reporting platform, confidentiality and the extended time scope. - [Essential requirements](https://cra-reference.eu/en/cra/essential-requirements/): Annex I: thirteen product security requirements in Part I, eight vulnerability handling obligations in Part II. The substance of the Regulation, identical for every class. - [Product security (Annex I, Part I)](https://cra-reference.eu/en/cra/essential-requirements/product-security/): The thirteen design requirements: secure default configuration, no known exploitable vulnerabilities, encryption, integrity, data minimisation, logging, secure erasure. - [Vulnerability handling (Annex I, Part II)](https://cra-reference.eu/en/cra/essential-requirements/vulnerability-handling/): The eight process obligations: SBOM, remediation without delay, regular testing, publishing advisories, CVD policy, information sharing, secure and free distribution of fixes. - [Exclusions from scope](https://cra-reference.eu/en/cra/exclusions/): Medical devices, motor vehicles, civil aviation, marine equipment, defence, spare parts, non-commercial open source: what the Regulation leaves out, and the false friends. - [Interplay with other legislation](https://cra-reference.eu/en/cra/interplay/): NIS 2, Cybersecurity Act, AI Act, RED, Machinery, GPSR, DORA, GDPR, product liability: where the CRA stops, where it overlaps, and how to pool evidence. - [Market surveillance](https://cra-reference.eu/en/cra/market-surveillance/): Authorities' powers, the procedure for products presenting a significant risk, formal non-compliance, coordinated sweeps, and the response card for an authority request. - [Free and open-source software](https://cra-reference.eu/en/cra/open-source/): The criterion is not the licence but the commercial nature of the supply. Four statuses, from the out-of-scope individual contributor to the fully responsible manufacturer. - [Individual developers and contributors](https://cra-reference.eu/en/cra/open-source/individual-developer/): What does and does not push free software activity into the commercial sphere: donations, forges, paid support, corporate funding, and the question of your own contributions. - [Integrating open source](https://cra-reference.eu/en/cra/open-source/integrating-oss/): Your most common situation: full regulatory responsibility, documented due diligence, upstream reporting of fixes, and handling abandoned components. - [The open-source software steward](https://cra-reference.eu/en/cra/open-source/steward/): Definition, the obligations actually owed, what stewards are not subject to — including fines — and your self-qualification grid. - [Penalties](https://cra-reference.eu/en/cra/penalties/): The three-tier scale, the modulating criteria, non-financial measures — often heavier than the fine — and the interaction with product liability. - [Regulation (EU) 2024/2847](https://cra-reference.eu/en/cra/regulation-2024-2847/): Identity, legal nature, objectives and structure of the Cyber Resilience Act, with publication milestones and the official sources to cite. - [Scope: products with digital elements](https://cra-reference.eu/en/cra/scope-pde/): Definition of a PDE, breakdown into hardware / software / remote data processing, triggering criteria, and the notions of placing on the market and substantial modification. - [Support period and life cycle](https://cra-reference.eu/en/cra/support-period/): Five years minimum or the expected lifetime, ten years of fix availability, the duty to inform the buyer, end of support and cessation of operations: the CRA's long-term commitment. - [Technical documentation (Annex VII)](https://cra-reference.eu/en/cra/technical-documentation/): The standard file structure, where the SBOM sits, the ten-year retention rule, and the completeness checklist to run before the pre-market review. - [The timeline](https://cra-reference.eu/en/cra/timeline/): The three application dates, the transitional regime, the derogation that subjects the legacy portfolio to reporting, and the internal back-planning that follows. ### SBOM - [SBOM](https://cra-reference.eu/en/sbom/): The software bill of materials: definition, CRA requirement, CycloneDX and SPDX formats, types, quality, identifiers, VEX, SPDX licensing, signing, distribution and life cycle. - [What the CRA requires of the SBOM](https://cra-reference.eu/en/sbom/cra-requirement/): The exact text, a reading of its three key phrases, the publication question, the Commission's empowerment, and the chain that leads to CE marking. - [What an SBOM is](https://cra-reference.eu/en/sbom/definition/): A definition both teams can read, the minimum data expected per component, uses by audience, and what an SBOM is not. - [Distribution and confidentiality](https://cra-reference.eu/en/sbom/distribution/): Should you publish your SBOM? Disclosure levels, contract clauses, the confidentiality regime for information given to authorities, and the decision matrix. - [Formats](https://cra-reference.eu/en/sbom/formats/): CycloneDX and SPDX: origins, standardisation, respective strengths, comparison, and the choice of a pivot format with export to the other. - [CycloneDX](https://cra-reference.eu/en/sbom/formats/cyclonedx/): The OWASP format standardised as ECMA-424: document structure, BOM extensions, native VEX support, and an annotated example. - [SPDX](https://cra-reference.eu/en/sbom/formats/spdx/): The Linux Foundation format standardised as ISO/IEC 5962: structure, SPDX 3 profiles, the authoritative licence list and expressions, and an annotated example. - [Component identifiers](https://cra-reference.eu/en/sbom/identifiers/): PURL, CPE, SWID, hashes: why matching a component to a vulnerability is the number-one cause of false positives, and how to make it reliable. - [SBOM life cycle](https://cra-reference.eu/en/sbom/lifecycle/): One SBOM per build, immutable and versioned; retention aligned with the technical documentation; archiving, indexing, retrieval and version-to-version comparison. - [Quality, completeness and depth](https://cra-reference.eu/en/sbom/quality/): Quality criteria for an SBOM, automated scoring, blocking thresholds in CI, transitive dependency depth, and the seven traps that produce false inventories. - [Signing and integrity](https://cra-reference.eu/en/sbom/signing/): Why an unsigned SBOM is not evidence: signing, provenance attestations, SLSA levels, reproducible builds and the transparency log. - [Licensing as SBOM data](https://cra-reference.eu/en/sbom/spdx-licences/): SPDX identifiers and expressions, what an SBOM lets you compute about legal compliance, and the data quality without which none of it works. - [The six types of SBOM](https://cra-reference.eu/en/sbom/types/): Design, source, build, analysed, deployed, runtime: they do not describe the same thing and are not equivalent. Which one belongs in the technical documentation. - [VEX: exploitability](https://cra-reference.eu/en/sbom/vex/): The mechanism that separates 'handled' from 'ignored': statuses, standardised justifications, CycloneDX, OpenVEX and CSAF implementations, and the legal value of a decision not to fix. ### Open source licensing - [Open source licensing](https://cra-reference.eu/en/licensing/): The families of free software licences, what actually triggers their obligations, and nine real distribution scenarios — from SaaS backend to connected device — with the verdict per family. - [The licence families](https://cra-reference.eu/en/licensing/families/): Public domain, permissive, weak copyleft by file or by library, strong copyleft, network copyleft, source-available, content licences: what each one actually requires. - [Pitfalls the matrix does not show](https://cra-reference.eu/en/licensing/pitfalls/): Upstream licence changes, missing licences, copied code, AI-generated code, assets, CLAs, mutual incompatibilities: what the family × scenario grid cannot capture. - [Nine distribution scenarios](https://cra-reference.eu/en/licensing/scenarios/): The same component, nine contexts: what changes, what gets triggered, and the verdict per licence family for each type of product. - [Desktop or command-line application](https://cra-reference.eu/en/licensing/scenarios/desktop-cli/): Classic binary distribution — the textbook case the GPL was written for. Demanding but workable, provided you prepare to supply the source. - [Embedded and IoT](https://cra-reference.eu/en/licensing/scenarios/embedded-iot/): The most constrained scenario, and the only one where a licensing requirement runs directly against a CRA security requirement: GPL-3.0 anti-lock-down versus verified boot. - [Internal tool](https://cra-reference.eu/en/licensing/scenarios/internal-tool/): No distribution, therefore almost no obligation — and the only real risk: the internal/external boundary moving without anyone reopening the file. - [Library or SDK you publish](https://cra-reference.eu/en/licensing/scenarios/library-sdk/): Here you are upstream: your dependencies constrain your licence, and your licence constrains your users. Contamination runs both ways. - [Mobile app](https://cra-reference.eu/en/licensing/scenarios/mobile-app/): Binary distribution plus store terms: the only scenario where a free licence can be flatly incompatible with the distribution channel itself. - [On-premises and self-hosted](https://cra-reference.eu/en/licensing/scenarios/on-premises/): Full distribution at the customer's site, often operating system included. The customer gains the right to redistribute what you shipped them. - [SaaS backend](https://cra-reference.eu/en/licensing/scenarios/saas-backend/): No distribution, so the GPL has no effect — and the AGPL becomes risk number one. The scenario where intuitions are most often wrong, in both directions. - [Web frontend](https://cra-reference.eu/en/licensing/scenarios/web-frontend/): The most misunderstood scenario: serving JavaScript to a browser is a distribution of code. The bundler mixes everything, minification erases the attributions. - [Worst case — the least favourable assumption](https://cra-reference.eu/en/licensing/scenarios/worst-case/): The posture to adopt when you do not yet know how the component will be distributed: assume binary distribution, network exposure and a consumer product. - [What triggers an obligation](https://cra-reference.eu/en/licensing/triggers/): Distribution, network interaction, derivative works, static or dynamic linking, mere aggregation, consumer products, patents: the eight mechanisms that make a licence bite — or not. ### Legal path - [Legal path](https://cra-reference.eu/en/legal/): CRA obligations seen from Legal and Compliance: CE marking, technical documentation, EU declaration, reporting, penalties, contracts, licensing, support and evidence retention. - [CE marking and technical documentation: the internal process](https://cra-reference.eu/en/legal/ce-and-documentation/): Who compiles, who reviews, who signs. The approval workflow, the market gate and the conformity review record. - [Supplier and customer contract clauses](https://cra-reference.eu/en/legal/contract-clauses/): The clauses to require upstream so you can meet your own deadlines, those to negotiate downstream, and the special case of free components for which no contract exists. - [EU declaration of conformity](https://cra-reference.eu/en/legal/declaration-of-conformity/): Mandatory content under Annex V, the simplified form in Annex VI, language requirements, a ready-to-use template and the update rules. - [Evidence retention](https://cra-reference.eu/en/legal/evidence-retention/): Which artefacts to keep, for how long, under what integrity guarantees, and the annual retrieval exercise that alone proves the arrangement works. - [Exposure and risk register](https://cra-reference.eu/en/legal/exposure/): Quantifying administrative, commercial and contractual exposure; keeping a compliance risk register; anticipating the effect on acquisition due diligence. - [Intellectual property and licensing](https://cra-reference.eu/en/legal/intellectual-property/): The licence policy enforced in CI, the exception process, the register, attribution deliverables and preparing for customer audits. - [Pre-market checklist](https://cra-reference.eu/en/legal/placing-checklist/): Fifteen points, one page, printable and signable. The document that gives Legal's veto over commercialisation its substance. - [Reporting duties: the legal decision](https://cra-reference.eu/en/legal/reporting-duties/): When the 24-hour clock starts, who decides, how to document the decision to report or not, and how to organise legal on-call cover. - [Turning the support period into commitments](https://cra-reference.eu/en/legal/support-commitments/): From the text of the Regulation to the terms and conditions: the mandatory statement to buyers, desynchronisation with suppliers, end-of-life policy and the register. - [Information and instructions to the user (Annex II)](https://cra-reference.eu/en/legal/user-information/): The ten mandatory items to supply with the product, the cybersecurity notice template, language requirements and the retention period. ### Cyber path - [Cyber path](https://cra-reference.eu/en/cyber/): CRA obligations seen from Cybersecurity and DevSecOps: SBOM generation, CI/CD, secure by design, vulnerability management, coordinated disclosure, reporting, continuous monitoring. - [24 h / 72 h / 14 d procedure](https://cra-reference.eu/en/cyber/24h-runbook/): The full reporting runbook: detection, qualification, crisis cell, submissions, informing users, on-call cover, exercises and a printable response card. - [Assessing an open source component](https://cra-reference.eu/en/cyber/assessing-components/): Making the diligence required by Article 13(5) computable: the eighteen OpenSSF Scorecard checks, what they cover of the grid, what they do not tell you, and the S2C2F ingestion framework. - [CI/CD integration](https://cra-reference.eu/en/cyber/ci-cd/): The eight steps of the target pipeline, the blocking rules, waiver handling, monorepos, and the cost in build time. - [Continuous monitoring](https://cra-reference.eu/en/cyber/continuous-monitoring/): Replaying the SBOM daily against sources that move: architecture, EUVD and the ENISA reporting platform, upstream monitoring, metrics. - [Locking and updating dependencies](https://cra-reference.eu/en/cyber/dependency-locking/): The central tension: freeze so you can rebuild identically for ten years, and update so there is no known exploitable vulnerability. Lock files, hash pinning, automated updates and quarantine. - [Coordinated disclosure policy](https://cra-reference.eu/en/cyber/disclosure-policy/): What a CVD policy contains, security.txt and RFC 9116, the safe harbour commitment, ISO/IEC 29147 and 30111, the French legal route, and whether to become a CNA. - [Managing false positives](https://cra-reference.eu/en/cyber/false-positives/): The compliance risk of excess noise: root causes, remedies, a dated and reasoned suppression policy, and the metric to track. - [Generating SBOMs](https://cra-reference.eu/en/cyber/generating-sboms/): The five generation methods by context, the tool families, the choice matrix by language, and why the toolchain must be pinned per product family. - [Reference incidents](https://cra-reference.eu/en/cyber/incidents/): Fourteen documented, dated compromises, from a vendor update channel to a hijacked CI action: what happened, what would have limited the damage, and the requirement each one illuminates. - [Secure by design](https://cra-reference.eu/en/cyber/secure-by-design/): Turning Annex I Part I into verifiable requirements: threat modelling, risk assessment, test plan, and the frameworks to use while harmonised standards are pending. - [Secure updates](https://cra-reference.eu/en/cyber/secure-updates/): Authenticated channel, signing, rollback protection, automatic updates with opt-out, separating fixes, free of charge, and the embedded case. - [Securing the build chain](https://cra-reference.eu/en/cyber/securing-the-build-chain/): The chain that produces and signs the SBOM is itself an attack surface: the six ways code executes in a pipeline, the pull-request attack, and the countermeasures. - [Supply chain risk](https://cra-reference.eu/en/cyber/supply-chain-risk/): Attack typology, what an SBOM does and does not enable, countermeasures for hardening the build chain, and mapping your exposure. - [Technical checklist](https://cra-reference.eu/en/cyber/technical-checklist/): Fifteen points to verify per product before the conformity review, printable, to be attached to the pre-market review file. - [Vulnerability management](https://cra-reference.eu/en/cyber/vulnerability-management/): The full cycle from detection to closure, the sources to aggregate, composite-score prioritisation, remediation SLAs and the automated reporting trigger. ### Organisation - [Organisation](https://cra-reference.eu/en/organisation/): Two tooling levels, a target architecture, a RACI matrix, governance bodies, a Legal-Cyber interface contract, metrics and a roadmap. - [Governance bodies](https://cra-reference.eu/en/organisation/governance/): CRA committee, PSIRT cell, pre-market review, licence policy review: composition, frequency, agenda and the decisions belonging to each level. - [Legal ↔ Cyber interface](https://cra-reference.eu/en/organisation/legal-cyber-interface/): The interface contract between the two teams: cross deliverables with deadlines and formats, a shared vocabulary and an escalation path. - [Metrics](https://cra-reference.eu/en/organisation/metrics/): Coverage, performance, risk and readiness: which metrics to track, which to avoid, and a mock-up of the leadership dashboard. - [Who does what — RACI matrix](https://cra-reference.eu/en/organisation/raci/): The split of roles across the twenty activities of the arrangement, and the three trade-offs the committee must settle explicitly. - [Roadmap](https://cra-reference.eu/en/organisation/roadmap/): Six deployment waves, from scoping to continuous improvement, with milestones, deliverables and the dependencies between them. - [Target architecture](https://cra-reference.eu/en/organisation/target-architecture/): End-to-end flows from code repository to evidence vault; control points, data sovereignty, and three scenarios by maturity. - [Generate and steer: the two levels](https://cra-reference.eu/en/organisation/two-levels/): The founding distinction between technical SBOM generation at application level and centralisation for steering at organisation level. The CRA requires both. ### Tooling - [Tooling](https://cra-reference.eu/en/tooling/): The two tooling families: SBOM generators inside the build chain, and platforms for steering the portfolio. Profiles, comparison and selection criteria. - [SBOM generators](https://cra-reference.eu/en/tooling/generators/): Application-level tools: Syft, Grype, Trivy, cdxgen, osv-scanner, ScanCode, OSS Review Toolkit and native build-chain plugins. - [Steering platforms](https://cra-reference.eu/en/tooling/platforms/): Organisation-level tools: OWASP Dependency-Track, Snyk, FOSSA, Black Duck, Mend, Sonatype, JFrog Xray, GUAC — and what really separates them. - [Selection criteria and evaluation protocol](https://cra-reference.eu/en/tooling/selection/): A weighted grid, an evaluation protocol run against your own artefacts, and the recommended tooling architecture. ### Leadership - [Leadership](https://cra-reference.eu/en/leadership/): The CRA in five minutes for an executive committee: market access exposure, financial exposure, decisions required and current progress. - [Budget, resources and scenarios](https://cra-reference.eu/en/leadership/budget/): Three investment scenarios with their residual risk, the items to provision, the profiles needed and the trade-offs to settle. - [Business impact](https://cra-reference.eu/en/leadership/business-impact/): Market access risk, financial exposure, the cost of compliance, commercial opportunities and the knock-on effect on NIS 2, DORA and customer questionnaires. ### Resources - [Resources](https://cra-reference.eu/en/resources/): The templates, models, registers, checklists and response cards to reuse: technical documentation, EU declaration, user notice, CVD policy, reporting templates, contract clauses. ### Worked scenarios - [Worked scenarios](https://cra-reference.eu/en/scenarios/): Ten end-to-end scenarios: the Legal question, the Cyber question, the decision, the evidence produced and the lesson. ### Self-assessment - [Self-assessment](https://cra-reference.eu/en/self-assessment/): A five-module grid to locate your maturity, identify priority gaps and measure progress from one quarter to the next. ### Glossary - [Glossary](https://cra-reference.eu/en/glossary/): The CRA and SBOM vocabulary, with the French equivalent where it differs, and a pointer to the reference page. ### Frequently asked questions - [Frequently asked questions](https://cra-reference.eu/en/faq/): Forty short answers to the questions Legal and Cyber teams ask most, each pointing to the reference page. ### Regulatory watch - [Regulatory watch](https://cra-reference.eu/en/updates/): What is still moving: harmonised standards, delegated and implementing acts, designation of national authorities. The mechanism that keeps this site from becoming wrong. ### Vulnerability disclosure - [Vulnerability disclosure](https://cra-reference.eu/en/security/): This site's coordinated disclosure policy: scope, reporting channel, response commitments, safe harbour and recognition of researchers. ### About this site - [About this site](https://cra-reference.eu/en/about/): Purpose, scope, editorial governance, legal disclaimer, technical principles and legal notices. ### Contact - [Contact](https://cra-reference.eu/en/contact/): One address: report an error, suggest content, ask a question — and what this site does not do. ## Optional - [llms-full.txt](https://cra-reference.eu/llms-full.txt): the site's full content in a single Markdown file - [sitemap.xml](https://cra-reference.eu/sitemap-index.xml): sitemap index, including cross-language alternates - [security.txt](https://cra-reference.eu/.well-known/security.txt): vulnerability disclosure contact (RFC 9116)