La loi européenne sur la cyber résilience (CRA) a fait un pas de plus vers la réalité

Temps de lecture : 5 minutes

La récente adoption du Cyber Resilience Act (CRA) de l'UE pousse les entreprises fortement axées sur les logiciels et ciblant le marché européen à repenser leurs stratégies de conformité. Conçu pour renforcer la sécurité des logiciels et du matériel, le CRA est en développement depuis 2020. Bien que son adoption par le Conseil de l’UE la semaine dernière ne soit pas une surprise, de nombreuses organisations se retrouvent désormais dans une course pour aligner leurs processus aux exigences de cette nouvelle réglementation.

La bonne nouvelle, c’est que les entreprises disposent de temps pour se préparer. Le CRA est désormais adopté, mais son application ne débutera qu’en 2027. Cette période de transition offre aux organisations l’opportunité d’adapter leurs protocoles internes en conséquence.

L’objectif principal du CRA est de remédier aux vulnérabilités en cybersécurité présentes dans de nombreux produits et au manque de clarté pour les consommateurs quant à la sécurité des produits.
Pour y parvenir, le CRA vise à harmoniser les règles régissant la mise sur le marché des produits ou logiciels contenant des composants numériques, en établissant un cadre d’exigences en cybersécurité et un contrôle du "devoir de diligence" tout au long du cycle de vie des produits.

Un élément clé du CRA est le Software Bill of Materials (SBOM, ou nomenclature logicielle). L’Acte précise que les SBOM doivent être fournis conformément à la directive technique allemande TR03183, qui définit les exigences en matière de cyber-résilience pour les fabricants et leurs produits.

Points essentiels concernant les SBOM :

• Compilation obligatoire : Les fabricants doivent établir des SBOM, bien que leur distribution publique ne soit pas requise.
• Nature statique : Un SBOM est considéré comme statique et ne doit pas contenir d’informations sur les vulnérabilités susceptibles d’évoluer dans le temps. Toutefois, un nouveau SBOM est requis à chaque mise à jour logicielle.
• Formats autorisés : Les fabricants peuvent utiliser CycloneDX 1.4 ou une version ultérieure, ou encore SPDX version 2.3 ou plus récente pour structurer leurs SBOM.

La directive introduit également le concept de dépendances récursives, ce qui signifie que si une application inclut des composants tels que des bases de données, les fabricants doivent lister les sous-composants qui les constituent.

Bien que le CRA n’impose pas la divulgation publique des SBOM, il insiste sur le fait que les utilisateurs — y compris les hôpitaux, les constructeurs automobiles et les consommateurs individuels — doivent avoir accès à ces informations pour évaluer leurs risques en cybersécurité. Ainsi, les fabricants doivent être prêts à fournir les SBOM sur demande des utilisateurs ou des organismes de régulation.

Ne pas fournir de SBOM pourrait entraîner des sanctions importantes, des poursuites judiciaires ou même une exclusion du marché européen.

Autres exigences

Au-delà des SBOM, le CRA impose d’autres obligations aux fabricants, notamment :

• Signaler toute vulnérabilité exploitée activement à l’Agence de l’Union européenne pour la cybersécurité (ENISA) dans un délai de 24 heures.
• Corriger les vulnérabilités pendant au moins cinq ans, sauf si la durée de vie du produit est plus courte.

Pour toute entreprise développant des produits logiciels destinés au marché européen, la mise en place d’un programme solide de création de SBOM est essentielle. Cela peut être réalisé en intégrant la génération de SBOM dans le processus de compilation ou en effectuant une analyse sur les binaires finaux.

Deux approches possibles :

• Intégration au processus de compilation : Permet une identification précoce des vulnérabilités mais nécessite des investissements en outils et en temps de développement.
• Analyse de composition binaire (BCA) : Solution souvent plus pratique pour les entreprises avec des produits existants, permettant une génération plus rapide et plus simple des SBOM à partir de binaires existants.

Des outils comme CodeSentry de CodeSecure  peuvent aider à générer des SBOM à partir de binaires, permettant aux développeurs d’évaluer la sécurité des composants tiers avant leur intégration et de faciliter la conformité, notamment dans des secteurs sensibles comme la santé et l’automobile.