Bonnes Pratiques D'adoption Du CRA Pour Les PME Et L'open Source

Explorer les bonnes pratiques

Ces pages traduisent l’approche fondée sur les risques imposée par le CRA en bonnes pratiques concrètes pour la communauté open source, et offrent aux PME une voie claire vers une intégration sécurisée et conforme des FOSS. Elles mettent l’accent sur l’intégration de la sécurité tout au long du cycle de vie, la garantie de la gouvernance et de la transparence, et le renforcement de la résilience de la chaîne d’approvisionnement.

Développement sécurisé de composants FOSS Sécurité tout au long du cycle de vie, gouvernance et transparence, résilience de la chaîne d'approvisionnement et traitement proportionné des vulnérabilités pour les projets open source. Découvrir
Gestionnaires de logiciels open source Qui sont les gestionnaires open source, leurs obligations adaptées, la manière dont ils facilitent la conformité des PME et le rôle des attestations de sécurité volontaires. Découvrir
Guide de conformité au CRA pour les PME Personas, diligence raisonnable fondée sur les risques, signaux d'alerte, le parcours des PME en six étapes et une matrice de décision interactive. Découvrir
Checklists et modèles Checklists de conformité minimale viable, de diligence raisonnable et SBOM, registre et fiche de composant, mini-guide de traitement des vulnérabilités et politique de mise à jour. Découvrir

Checklists et modèles prêts à l'emploi

Des outils légers issus de la boîte à outils pratique de mise en œuvre pour les PME, à cocher en ligne, à imprimer ou à télécharger dans votre propre outil de suivi.

Le risque dépend du contexte, il n'est pas intrinsèque

Dans le cadre du CRA, les obligations de cybersécurité ne sont ni uniformes ni prescriptives. Les fabricants doivent mettre en œuvre des mesures de sécurité « appropriées et proportionnées » fondées sur les risques identifiés, plutôt que de viser une sécurité absolue. Les obligations sont modulées en fonction de :

La destination prévue du produit
L’utilisation et la mauvaise utilisation prévisibles
La gravité et la probabilité des impacts potentiels
Le rôle du composant logiciel au sein du produit

Pour les composants FOSS, cela signifie qu’une même bibliothèque open source peut présenter un risque faible dans un scénario et un risque élevé dans un autre, selon la manière dont elle est déployée et l’endroit où elle l’est. Une approche fondée sur les risques va au-delà du simple fait qu’un composant soit open source et évalue :

Criticité fonctionnelle

Le composant assure-t-il des fonctions vitales comme l’authentification, la cryptographie, les mécanismes de mise à jour ou l’exposition réseau ?

Surface d’attaque

Le composant est-il exposé à des entrées non fiables ou à des interfaces externes ?

Profondeur et transitivité des dépendances

Combien de dépendances indirectes sont introduites, et sont-elles bien comprises ?

Maintenance et réactivité

Le projet est-il activement maintenu ? Les problèmes de sécurité sont-ils rapidement pris en compte et traités ?

Contexte d’intégration

Comment le composant est-il configuré, durci et isolé au sein du produit final ?

Ce sont ces facteurs, et non le modèle de développement lui-même, qui déterminent le niveau requis de diligence raisonnable et de contrôles de sécurité.

Fondé sur des données issues des PME

Ces recommandations s’appuient sur les résultats anonymisés et agrégés d’évaluations volontaires réalisées sur la plateforme d’auto-évaluation CRA d’OCCTET. Aucune donnée personnelle ou propre à une entreprise n’est incluse.

Entreprises inscrites: 48
Pays représentés: 22
Organisations se déclarant soumises au CRA: 20
Score de maturité moyen, tous domaines confondus: 1,66/ 3

Score de maturité moyen par domaine Échelle de 0 (non mis en place) à 3 (pleinement mis en place). Les contrôles techniques sont plus matures que la gouvernance, la documentation et les processus liés au cycle de vie.

Confidentialité 2,16
Résilience 2,06
Sécurité réseau 1,90
Protection contre les accès non autorisés 1,76
Intégrité 1,65
Gestion et divulgation des vulnérabilités 1,63
Cycle de vie du développement logiciel sécurisé 1,54
Exigences relatives aux versions publiées 1,48
Journalisation et détection 1,34
Gestion des risques et gouvernance 1,11

Lacunes structurelles récurrentes

Cadre de gestion des risques peu documenté
Aucune responsabilité clairement attribuée pour la mise à jour des dépendances
Absence de discipline formalisée dans la documentation des versions
Visibilité incomplète sur le SBOM ou les dépendances
Gestion des vulnérabilités réactive plutôt qu’orientée cycle de vie

L’enjeu n’est pas d’ajouter de la complexité, mais d’apporter de la clarté.

Ce que cela implique pour une adoption alignée sur le CRA

Les PME tirent le meilleur parti de recommandations proportionnées, structurées et légères.
Le manque de clarté sur la gouvernance et le cycle de vie est une lacune plus critique que les contrôles purement techniques.
La documentation, la traçabilité et la reproductibilité sont des leviers essentiels de l’alignement sur le CRA.
Attribuer simplement les responsabilités et mettre en place des mécanismes de visibilité peut améliorer sensiblement la maturité.

Quel est le niveau de maturité de votre organisation ?

Mesurez votre niveau de préparation en quelques minutes grâce à l’auto-évaluation CRA gratuite et confidentielle.

Commencer l'auto-évaluation