Comment se conformer à la loi britannique sur la cybersécurité et la résilience : Un guide pratique pour les équipes d'ingénierie modernes

Les cyberattaques ont évolué au-delà des interruptions sporadiques pour devenir un risque systémique.

Aujourd'hui, un seul compromis peut avoir des répercussions sur l'ensemble de l'écosystème numérique, des fournisseurs et bibliothèques en amont aux éditeurs de logiciels et cloud , souvent plus rapidement que la plupart des organisations ne peuvent réagir.

En raison de cette interdépendance croissante, le Royaume-Uni ne considère plus la cybersécurité comme un sujet que les organisations peuvent aborder avec bonne volonté et en appliquant des bonnes pratiques informelles. 

L'augmentation des violations de la chaîne d'approvisionnement, des composants compromis et des produits non sécurisés par défaut a clairement montré que les efforts volontaires en matière de sécurité ne suffisent pas à protéger une économie numérique hautement connectée. Trop de pannes, de violations de données et de défaillances en matière de résilience ont montré à quelle vitesse un seul maillon faible peut perturber des secteurs entiers.

Le projet de loi sur la cybersécurité et la résilience répond à cette réalité par des exigences simples à énoncer, mais difficiles à mettre en œuvre :

• Vous devez concevoir des logiciels intégrant la sécurité dès le départ. 
• Vous devez faire preuve de transparence concernant les cyberrisques présents dans votre chaîne d'approvisionnement. 
• Vous devez expédier des produits avec des paramètres par défaut sécurisés qui ne dépendent pas de la vigilance de l'utilisateur.
• Vous devez disposer d'un processus opérationnel pour identifier, trier et corriger les vulnérabilités. 
• Vous devez être en mesure de fournir aux autorités réglementaires des preuves tangibles que vous répondez à ces attentes.

Ce changement met clairement en évidence une chose : vous ne pouvez plus vous fier aux feuilles de calcul, aux scanners cloisonnés ou aux listes de contrôle réactives. Une visibilité continue, l'automatisation et la rigueur sont désormais des exigences de base, et non plus des améliorations facultatives.

TL;DR

Aikido vous fournit les outils nécessaires pour vous conformer à la loi britannique sur la cybersécurité et la résilience (UK Cybersecurity and Resilience Bill). Cette loi est applicable et exige un développement sécurisé dès la conception, des configurations sécurisées par défaut, une transparence totale des SBOM, gestion des vulnérabilités obligatoire gestion des vulnérabilités, une assurance de la sécurité de la chaîne d'approvisionnement et des rapports fondés sur des preuves à l'intention des régulateurs.

Nous expliquons ici pourquoi ce projet de loi a été présenté, en quoi il diffère de la Cyber Resilience Act européenne Cyber Resilience Act, ce qu'il implique pour les développeurs et les équipes de sécurité, et pourquoi il est difficile de satisfaire à ces exigences sans une visibilité unifiée et une automatisation.

Aikido vous Aikido remplir ces obligations grâce à une analyse continue, une corrélation automatisée des risques, SBOM , l'analyse de la chaîne d'approvisionnement, la création de rapports prêts pour l'audit et des workflows de correction intégrés sur GitHub, GitLab, Bitbucket, Azure et bien d'autres encore.

Si vous avez besoin d'une conformité continue qui réponde aux exigences de sécurité du Royaume-Uni et de l'Union européenne, Aikido vous Aikido une solution claire.

Pourquoi le projet de loi britannique sur la cybersécurité et la résilience a-t-il été présenté ?

Le projet de loi sur la cybersécurité et la résilience est une réforme et une extension du règlement NIS de 2018. Il a été introduit afin de renforcer la résilience nationale en matière de cybersécurité et de combler les lacunes apparues à mesure que les systèmes numériques, cloud et les chaînes de dépendance sont devenus plus complexes. Le projet de loi vise à apporter un « changement fondamental dans la sécurité nationale du Royaume-Uni », en réponse aux cyberattaques dont l'ampleur, la sophistication et l'impact économique ne cessent de croître. De nombreuses attaques exploitent les fournisseurs en amont, les dépendances logicielles ou les fournisseurs de services gérés, montrant ainsi comment les faiblesses d'une organisation peuvent se répercuter sur l'ensemble des secteurs.

Les services publics essentiels tels que l'énergie, l'eau, les soins de santé, les transports et les finances dépendent désormais fortement des systèmes numériques. Un seul incident cybernétique peut toucher des millions de personnes. Le projet de loi vise explicitement à « protéger les services dont dépend le public », qu'il s'agisse de l'éclairage ou de l'accès au système de santé national (NHS). L'essor du cloud , des écosystèmes SaaS et des chaînes d'approvisionnement interconnectées a également révélé des lacunes réglementaires, en particulier en ce qui concerne les fournisseurs de services gérés.

Des incidents très médiatisés dans les secteurs des télécommunications, de la finance, de la santé et des administrations locales ont mis en évidence des faiblesses systémiques, notamment des paramètres par défaut non sécurisés, des vulnérabilités non corrigées et une visibilité limitée sur les risques liés aux tiers. Les pratiques de sécurité volontaires ne suffisaient plus pour faire face à ces menaces en constante évolution.

En réponse, le projet de loi passe d'une simple recommandation à une obligation exécutoire. Il définit des attentes plus claires en matière de sécurité, renforce la notification des incidents, améliore la surveillance réglementaire, renforce la sécurité de la chaîne d'approvisionnement et actualise les pouvoirs d'exécution. En bref, il fournit des bases actualisées et exécutoires pour protéger les services essentiels du Royaume-Uni et maintenir la stabilité économique dans un paysage numérique plus interconnecté.

Ce que le projet de loi signifie pour les développeurs et les équipes de sécurité

Le projet de loi sur la cybersécurité et la résilience ne se contente pas de fixer des objectifs politiques généraux. Il modifie le quotidien des personnes qui développent et sécurisent des logiciels. Vous trouverez ci-dessous les attentes concernant les développeurs et les équipes de sécurité.

Ce que cela signifie pour les développeurs

Les développeurs sont plus proches de la chaîne logistique logicielle que tout autre groupe, ce qui signifie que le projet de loi a une incidence directe sur la manière dont vous écrivez, maintenez et publiez du code.

1. Attentes claires en matière de codage sécurisé : le projet de loi prévoit que les principes de sécurité dès la conception soient intégrés à votre base de code. Cela implique des révisions régulières du code, la validation des entrées, des configurations par défaut sécurisées et des modèles prévisibles et sécurisés pour tous les services.

2. Délais requis pour la correction des vulnérabilités : l'époque où l'on corrigeait les problèmes de sécurité « quand on avait le temps » est révolue. Vous êtes désormais tenu de corriger les vulnérabilités dans des délais définis et de fournir la preuve que ces délais sont respectés.

3. Responsabilité accrue dans le suivi des risques liés aux dépendances : les applications modernes s'appuient fortement sur des bibliothèques open source. Vous êtes désormais responsable de comprendre la posture de sécurité de ces dépendances, et pas seulement du code que vous écrivez vous-même.

4. Nécessité de SBOM : les nomenclatures logicielles deviennent une exigence de conformité. Vous devez connaître le contenu de votre base de code, y compris les dépendances transitives, et veiller à l'exactitude de cet inventaire. 

5. Codage fondé sur des preuves et hygiène des commits : votre travail doit être traçable. Cela inclut des historiques de commits propres, des modifications documentées et une justification claire des décisions liées à la sécurité. Si un auditeur examine votre référentiel, il doit être en mesure de comprendre comment les vulnérabilités ont été gérées et pourquoi certaines modifications ont été apportées.

Ce que cela signifie pour les équipes de sécurité

Pour les équipes chargées de la sécurité, le projet de loi renforce les attentes en matière de surveillance consultative et de responsabilisation renforcée. La conformité devient un processus continu plutôt qu'un exercice annuel.

1. Attentes en matière de conformité continue : les équipes de sécurité doivent maintenir une visibilité actualisée sur tous les systèmes, référentiels, dépendances et infrastructures. Les contrôles doivent fonctionner en continu et pas seulement pendant les cycles d'audit.

2. Une pression accrue pour l'automatisation des workflows de gestion des vulnérabilités : l'analyse manuelle ne suffit plus. Vous aurez besoin de pipelines automatisés qui détectent les problèmes, les hiérarchisent, informent les personnes concernées et suivent leur résolution jusqu'à leur achèvement.

3. Structures de signalement obligatoire : vous devez mettre en place un processus clair de signalement des vulnérabilités, encourager le partage d'informations entre les équipes et produire des documents pouvant être remis aux autorités de réglementation sur demande.

4. La charge de la preuve des mesures de sécurité raisonnables : il ne suffit plus de dire que vous disposez d'un processus. Vous devez présenter des indicateurs, des calendriers, des historiques de tickets, des journaux, des SBOM et des pistes d'audit qui démontrent une sécurité opérationnelle réelle.

5. Collaboration renforcée avec les équipes d'ingénierie : les contrôles de sécurité influencent désormais les pipelines de livraison et la vitesse d'ingénierie. Le projet de loi encourage un alignement plus étroit entre les fonctions DevOps, d'ingénierie de plate-forme et de sécurité.

6. La posture de sécurité devient une question réglementaire : la sécurité n'est plus une bonne pratique. En vertu du projet de loi, la résilience et le développement sécurisé sont des exigences légales. Les décisions qui étaient autrefois internes ont désormais des conséquences réglementaires.

Projet de loi britannique sur la cybersécurité et la résilience vs Cyber Resilience Act européenne Cyber Resilience Act CRA)

De nombreuses organisations considèrent que le projet de loi britannique sur la cybersécurité et la résilience n'est qu'un équivalent régional de la Cyber Resilience Act européenne Cyber Resilience Act.

Les deux visent à renforcer la sécurité des produits et services numériques, mais ils réglementent des responsabilités différentes. Confondre les deux peut amener les équipes à appliquer les mauvais contrôles, à produire les mauvais rapports ou à s'appuyer sur des preuves qui ne satisfont aucun des deux régimes. 

Ce que Cyber Resilience Act la Cyber Resilience Act européenne Cyber Resilience Act

La directive européenne sur les produits de consommation (EU CRA) concerne les produits comportant des éléments numériques et s'applique à l'ensemble du marché unique européen. Elle vise principalement les fabricants, les importateurs et les distributeurs, et garantit que les produits répondent aux mêmes exigences de sécurité avant et après leur mise sur le marché.

1. Sécurité dès la conception et sécurité par défaut : les fabricants doivent concevoir des produits qui sont sécurisés dès leur sortie de l'emballage, sans nécessiter de connaissances particulières de la part de l'utilisateur.

2. Obligations en matière d'évaluation des risques : les produits doivent faire l'objet d'évaluations structurées des risques avant leur mise sur le marché.

3. Processus obligatoires de gestion des vulnérabilités : la prise en charge des vulnérabilités, l'évaluation des risques et la correction doivent suivre des procédures définies.

4. Obligations de surveillance après la mise sur le marché : les fabricants doivent surveiller la sécurité des produits après leur mise sur le marché et continuer à corriger les vulnérabilités tout au long du cycle de vie du produit.

Où le projet de loi britannique sur la cybersécurité et la résilience et Cyber Resilience Act  européenne Cyber Resilience Act

Les deux cadres partagent des principes similaires, même s'ils les appliquent différemment.

• Exigences en matière de développement sécurisé
• gestion des vulnérabilités obligatoire gestion des vulnérabilités
• Transparence tout au long de la chaîne logistique logicielle
• Surveillance de la sécurité après la mise sur le marché ou après le déploiement
• Documentation et conformité fondée sur des preuves

Par exemple, si une dépendance tierce introduit une vulnérabilité CVE critique, les deux cadres exigent une visibilité rapide, une correction coordonnée et une documentation vérifiable.

Différences clés

Pourquoi il est difficile de respecter la loi britannique sur la cybersécurité et la résilience

Les attentes exprimées dans le projet de loi sur la cybersécurité et la résilience semblent simples sur le papier. Dans la pratique, la plupart des organisations rencontrent des difficultés car leurs environnements d'ingénierie sont complexes, évoluent rapidement et dépendent fortement de composants tiers. Même les équipes expérimentées ont du mal à maintenir une conformité continue lorsque chaque validation, déploiement et mise à jour de dépendance introduit un nouveau risque.

Voici les principales raisons pour lesquelles ces exigences sont difficiles à satisfaire dans des environnements réels :

1. Les applications modernes s'appuient sur de vastes réseaux de bibliothèques open source. La plupart des équipes ne peuvent pas suivre la posture de sécurité de chaque dépendance et dépendance transitive sans automatisation.
2. La couverture de sécurité s'arrête souvent à l'analyse du code. Les images de conteneurs, les définitions d'infrastructure et les charges de travail d'exécution ne sont pas surveillées avec la même précision, ce qui crée des angles morts.
3. Les équipes utilisent différents scanners qui produisent des niveaux de gravité contradictoires et des recommandations incohérentes. Cela ralentit la correction et rend la hiérarchisation des priorités peu fiable.
4. Les feuilles de calcul d'audit et les listes de contrôle périodiques ne peuvent pas suivre le rythme des modifications quotidiennes du code, des mises à jour des dépendances et des nouvelles vulnérabilités publiées chaque semaine.
5. Les équipes doivent prouver non seulement que les vulnérabilités ont été corrigées, mais aussi quand elles ont été signalées, qui a répondu, combien de temps la correction a pris et quelles décisions ont été prises. La plupart des organisations ne disposent pas de cette documentation.
6. Les choix architecturaux, les modèles de codage et les décisions de configuration doivent être étayés par des justifications traçables. Sans documentation structurée, cela devient difficile à présenter lors des audits de conformité.
7. Les résultats sont souvent enregistrés dans un outil, tandis que les tickets sont enregistrés dans un autre. Il est donc difficile de vérifier que les problèmes ont été triés, classés par ordre de priorité, attribués et résolus dans les délais impartis.

Ces défis expliquent pourquoi les organisations ont besoin d'une méthode unifiée pour surveiller les risques, coordonner les mesures correctives et produire automatiquement des preuves. C'est également à ce stade que Aikido prend tout son sens en tant que moteur central de visibilité et de conformité.

Comment Aikido vous Aikido de vous conformer aux exigences de la loi britannique sur la cybersécurité et la résilience

Pour répondre aux exigences du projet de loi sur la cybersécurité et la résilience, les organisations ont besoin de plus que des analyses périodiques ou des outils de sécurité isolés. Elles ont besoin d'une plateforme qui leur offre les meilleurs outils de leur catégorie pour une visibilité continue, une évaluation cohérente des risques et des preuves qu'elles peuvent remettre aux régulateurs sans avoir à fouiller dans des feuilles de calcul. Aikido s'inscrit dans cette démarche en fournissant un point de contrôle centralisé aux équipes d'ingénieurs modernes.

Aikido une plateforme de sécurité cloud qui rassemble tous vos signaux de sécurité en un seul endroit. Elle offre une visibilité sur l'ensemble de vos bases de code, dépendances open source, modèles d'infrastructure en tant que code, images de conteneurs, secrets et pipelines d'intégration continue.

Au lieu d'obliger les équipes à gérer des scanners distincts, Aikido les vulnérabilités entre ces couches, met en évidence ce qui est réellement exploitable et élimine les interférences qui ralentissent la correction.

Bien que Aikido aider à satisfaire un grand nombre d'exigences, certaines d'entre elles doivent être remplies par d'autres fournisseurs, telles que la notification des incidents et les attentes en matière de résilience opérationnelle continue. 

Vous trouverez ci-dessous une analyse détaillée de la manière dont Aikido vous Aikido respecter les obligations fondamentales du projet de loi britannique sur la cybersécurité et la résilience.

1. Exigence : pratiques de sécurité dès la conception

Le problème : vous devez concevoir un logiciel sécurisé dès la première ligne de code. Cela implique d'identifier rapidement les configurations non sécurisées, de réduire les risques liés aux dépendances et de veiller à ce que les développeurs ne soient pas submergés par des résultats non pertinents.

Comment Aikido ce problème

• Effectue une analyse continue de vos bases de code, dépendances et configurations d'infrastructure.
• Applique des périmètres d'analyse sécurisés par défaut afin que vous ne manquiez aucun élément critique.
• Corrèle les problèmes provenant de plusieurs sources afin de réduire le bruit des développeurs et de mettre en évidence les risques réels.
• Assure la sécurité des flux de travail dans les pipelines CI et CD afin que les vulnérabilités ne puissent pas passer inaperçues en production.

2. Exigence : SBOM et inventaire précis des logiciels

Le problème : vous devez tenir à jour une liste de matériaux logiciels précise et actualisée liste de matériaux logiciels. Le suivi manuel devient immédiatement impossible lorsque de nouvelles dépendances sont ajoutées ou que des bibliothèques transitives changent.

Comment Aikido ce problème

• Générer une SBOM un seul clic
• Crée une SBOM complète SBOM chaque référentiel grâce SBOM Aikido, pour une visibilité claire des dépendances.
• Offre une visibilité complète sur les bibliothèques directes et transitives.
• Vous alerte lorsque SBOM reçoivent de nouveaux CVE.
• Vous permet d'exporter des SBOM pour les auditeurs ou les examens internes en une seule action.

3. Exigence : processus obligatoire de gestion des vulnérabilités

Le problème : le projet de loi vous oblige à détecter les vulnérabilités, à les classer par ordre de priorité, à attribuer leur responsabilité et à prouver que vous avez respecté les délais de correction. Sans automatisation, cela est pratiquement impossible avec des outils fragmentés.

Comment Aikido ce problème

• Détecte les vulnérabilités dans les référentiels, les images de conteneurs et les registres.
• Hiérarchise les résultats à l'aide de données d'exploitabilité, du CVSS et renseignement sur les menaces les équipes se concentrent sur ce qui importe.
• Automatise les workflows de remédiation grâce à l'intégration de Jira ou Slack.
• Enregistre chaque action avec horodatage et journalisation, créant ainsi une piste d'audit claire pour les auditeurs.
• Calcule automatiquement les délais de correction des documents, conformément aux attentes des autorités réglementaires.

4. Exigence : garantie de la sécurité de la chaîne d'approvisionnement

Le problème : la plupart des organisations dépendent fortement des paquets en amont et des dépendances tierces. Vous restez responsable des risques introduits par ces composants, même si vous ne les avez pas créés.

Comment Aikido ce problème

• Identifie et analyse rapidement les compromissions par des logiciels malveillants, souvent avant même qu'elles ne se propagent. Aikido le premier à détecter les comportements malveillants des paquets, les versions compromises ou les modifications suspectes des dépendances qui pourraient avoir un impact dévastateur sur votre chaîne d'approvisionnement.
• Évalue le risque de dépendance en fonction de l'historique de sécurité, des modèles de maintenance et de la réputation de l'écosystème.
• Détecte les paquets potentiellement malveillants ou les tentatives de typosquatting avant qu'ils n'entrent dans votre base de code.
• Signalez les bibliothèques abandonnées, obsolètes ou compromises afin que les équipes puissent les remplacer avant qu'elles n'exposent les charges de travail de production.
• Offre une traçabilité de bout en bout, vous permettant d'indiquer précisément l'origine d'une dépendance, les services concernés et la manière dont elle a été corrigée lors des contrôles de conformité.

5. Exigence : assurance fondée sur des preuves pour les autorités réglementaires britanniques

Le problème : il ne suffit pas de prétendre que vous avez de bonnes pratiques en matière de sécurité. Vous devez le prouver à l'aide de preuves structurées, d'archives historiques et de rapports transparents sur les risques.

Comment Aikido ce problème

• Produit des rapports automatisés et conformes qui mettent en correspondance les résultats avec les exigences réglementaires.
• Affiche les chronologies historiques de vulnérabilité qui illustrent la gestion des risques à long terme.
• Documente les activités de correction afin que les auditeurs puissent comprendre ce qui a changé et pourquoi.
• Fournit une vue claire des mesures de sécurité raisonnables prises au sein de votre organisation.
• Regroupe les informations sur les risques dans des vues adaptées aux dirigeants qui aident les équipes de direction à remplir leurs obligations en matière de responsabilité.

Au-delà des normes ISO 27001, SOC 2, NIS 2 et CIS : ce qu'apporte le projet de loi britannique sur la cybersécurité et la résilience

La plupart des organisations se conforment déjà à des référentiels établis tels que ISO 27001, SOC2, benchmarks CIS, NIS2 ou PCI. Ces référentiels sont axés sur la gestion de la sécurité organisationnelle. Ils définissent la manière dont vous devez gérer les risques, documenter les politiques, contrôler les accès, surveiller les événements et réagir aux incidents. 

Aikido prend Aikido en charge ces normes :

• Conformité à la norme ISO 27001:2022 
• Conformité SOC2 
• Top 10 OWASP
• Conformité CIS 
• conformité NIS2
• Conformité à la norme NIST 800-53 
• Conformité PCI 
• Conformité HIPAA 
• Conformité DORA 
• HITRUST 
• Conformité LVL3 
• Conformité ENS 
• RGPD

Le projet de loi britannique sur la cybersécurité et la résilience introduit un autre type d'exigence. Il va au-delà des contrôles organisationnels et impose des attentes strictes en matière de sécurité des logiciels et des services que vous développez et exploitez. Il exige un développement sécurisé dès la conception, des configurations par défaut sécurisées, SBOM vérifiable SBOM , une gestion continue des vulnérabilités, une assurance de la chaîne d'approvisionnement et la preuve des délais de correction. Ces obligations s'appliquent directement à vos pratiques d'ingénierie, à vos pipelines CI, à vos bases de code, à vos dépendances, à vos conteneurs, à cloud et à vos flux de travail opérationnels.

Cela crée un nouveau fossé : vous pouvez être conforme à la norme ISO 27001 ou SOC2 et ne pas satisfaire aux exigences de la loi britannique si votre produit présente des vulnérabilités exploitables, des bibliothèques obsolètes, des contrôles de chaîne d'approvisionnement insuffisants ou des processus de correction non documentés. Les cadres traditionnels ne couvrent pas ces domaines de manière suffisamment approfondie.

Aikido combler cette lacune en fournissant les contrôles techniques, l'automatisation et la visibilité en temps réel nécessaires pour satisfaire aux obligations de la loi en matière de produits et de services.

Aikido : votre chemin vers une conformité continue et en toute confiance

Le projet de loi britannique sur la cybersécurité et la résilience marque un changement radical dans la manière dont les organisations sont censées aborder la sécurité. Il s'agit d'une loi contraignante, et non d'une simple recommandation, qui exige des équipes qu'elles démontrent leur résilience par des preuves, et non par de simples intentions. Cyber Resilience Act européenne Cyber Resilience Act s'y Cyber Resilience Act , avec des champs d'application et des responsabilités différents, ce qui signifie que les organisations opérant dans plusieurs régions doivent adopter une approche nuancée qui respecte les deux cadres plutôt que de les traiter comme interchangeables.

Aikido vous Aikido les bases opérationnelles nécessaires pour répondre à ces attentes. Vous bénéficiez d'une visibilité continue sur votre code, vos dépendances, votre infrastructure et vos pipelines. Vous obtenez une évaluation cohérente des risques, remédiation automatique et des pistes d'audit auxquelles les régulateurs peuvent se fier. La conformité devient alors une pratique quotidienne, plutôt qu'un contrôle annuel stressant.

Avec le bon niveau d'automatisation et le bon niveau d'observabilité, vous réduisez les risques, améliorez la rapidité de livraison et éliminez l'incertitude qui entoure généralement la préparation réglementaire. Aikido vous Aikido transformer des exigences complexes en processus gérables et reproductibles qui s'adaptent à vos équipes d'ingénieurs.

Si vous souhaitez vous conformer à la législation britannique, répondre aux attentes de l'Autorité européenne des marchés financiers (AEMF) et intégrer naturellement cette conformité à votre processus de développement, commencez dès aujourd'hui à utiliser Aikido .

Vous aimerez peut-être aussi :

• Pourquoi les entreprises européennes choisissent Aikido partenaire en matière de cybersécurité Les entreprises de l'UE et leurs choix en matière de cybersécurité

• Comment Aikido Deloitte sécurité axée sur les développeurs l'entreprise — Aikido Deloitte pour améliorer l'expérience et la sécurité des développeurs en entreprise
• Conformité à la Cyber Resilience Act CRA) grâce à Aikido — Respectez la CRA de l'UE avec Aikido