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, une seule compromission peut se propager à travers tout l'écosystème numérique, des fournisseurs et bibliothèques en amont aux éditeurs de logiciels et services 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 quelque chose que les organisations peuvent aborder avec bonne volonté et des bonnes pratiques informelles. 

L'augmentation des violations de la chaîne d'approvisionnement, des composants compromis et des produits insécurisés par défaut a clairement montré que les efforts de sécurité volontaires ne suffisent pas à protéger une économie numérique hautement connectée. Trop de pannes, de violations de données et de défaillances de résilience ont démontré la rapidité avec laquelle un seul maillon faible peut perturber des industries entières.

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

• Vous devez concevoir des logiciels avec la sécurité intégrée dès le départ. 
• Vous devez être transparent quant aux cyber-risques dans votre chaîne d'approvisionnement. 
• Vous devez livrer des produits avec des configurations sécurisées par défaut 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 régulateurs des preuves concrètes que vous respectez ces attentes.

Ce changement met une chose en évidence : 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 une exigence fondamentale, et non une amélioration facultative.

TL;DR

Aikido Security vous fournit les outils nécessaires pour vous conformer au projet de loi britannique sur la cybersécurité et la résilience. Ce projet de loi est exécutoire et exige un développement sécurisé dès la conception, des configurations sécurisées par défaut, une transparence totale des SBOMs, une gestion des vulnérabilités obligatoire, une assurance de la sécurité de la chaîne d'approvisionnement et des rapports fondés sur des preuves aux régulateurs.

Ici, nous expliquons pourquoi le projet de loi a été introduit, en quoi il diffère du Cyber Resilience Act de l'UE, ce qu'il signifie 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 aide à remplir ces obligations grâce à l'analyse continue, la corrélation automatisée des risques, la génération de SBOM, l'analyse de la chaîne d'approvisionnement, des rapports prêts pour l'audit et des workflows de remédiation intégrés sur GitHub, GitLab, Bitbucket, Azure et bien plus encore.

Si vous avez besoin d'une conformité continue qui suit le rythme des attentes de sécurité du Royaume-Uni et de l'UE, Aikido vous offre une voie claire à suivre.

Pourquoi le projet de loi britannique sur la cybersécurité et la résilience a été introduit

Le projet de loi sur la cybersécurité et la résilience est une réforme et une extension des réglementations NIS de 2018. Il a été introduit pour renforcer la cyber-résilience nationale et combler les lacunes émergentes à mesure que les systèmes numériques, les services cloud et les chaînes de dépendances devenaient plus complexes. Le projet de loi vise à opérer 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 augmentent. De nombreuses attaques exploitent les fournisseurs en amont, les dépendances logicielles ou les fournisseurs de services gérés, montrant comment les faiblesses d'une organisation peuvent se propager à travers les secteurs.

Les services publics essentiels tels que l'énergie, l'eau, la santé, les transports et la finance dépendent désormais fortement des systèmes numériques. Un seul incident cybernétique peut affecter des millions de personnes. Le projet de loi vise explicitement à « protéger les services dont le public dépend », de l'allumage des lumières à l'accès au NHS. L'essor du cloud computing, des écosystèmes SaaS et des chaînes d'approvisionnement interconnectées a également révélé des angles morts réglementaires, en particulier concernant les fournisseurs de services gérés.

Des incidents très médiatisés dans les télécommunications, la finance, la santé et les administrations locales ont mis en évidence des faiblesses systémiques, notamment des configurations par défaut non sécurisées, 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 n'étaient plus suffisantes pour faire face à ces menaces évolutives.

En réponse, le projet de loi passe d'une orientation à une obligation exécutoire. Il établit des attentes de sécurité plus claires, augmente la déclaration des incidents, renforce la surveillance réglementaire, consolide l'assurance de la chaîne d'approvisionnement et met à jour les pouvoirs d'exécution. En bref, il fournit des fondations actualisées et exécutoires pour sauvegarder 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 fait plus que fixer de grands objectifs politiques. Il modifie le travail quotidien des personnes qui développent et sécurisent les logiciels. Ci-dessous sont les attentes pour 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 d'approvisionnement logicielle que tout autre groupe, ce qui signifie que le projet de loi affecte directement la manière dont vous écrivez, maintenez et publiez du code.

1. Attentes claires concernant le codage sécurisé : Le projet de loi attend que les principes de sécurité dès la conception se manifestent dans votre base de code. Cela implique des revues de code régulières, la validation des entrées, des configurations par défaut sécurisées et des modèles prévisibles et sécurisés sur tous les services.

2. Délais de remédiation des vulnérabilités requis : L'époque où l'on corrigeait les problèmes de sécurité « quand le temps le permettait » est révolue. Vous êtes censé corriger les vulnérabilités dans des délais définis et prouver que ces délais sont respectés.

3. Responsabilité accrue de suivre les risques liés aux dépendances : Les applications modernes dépendent fortement des bibliothèques open source. Vous êtes désormais responsable de la compréhension de la posture de sécurité de ces dépendances, et pas seulement du code que vous écrivez vous-même.

4. Nécessité de connaître les SBOM : Les Software Bills of Materials (SBOM) deviennent une exigence de conformité. Vous devez savoir ce qui se trouve dans votre base de code, y compris les dépendances transitives, et maintenir cet inventaire précis. 

5. Codage basé sur des preuves et hygiène des commits : Votre travail doit être traçable. Cela inclut des historiques de commits clairs, des modifications documentées et une justification claire des décisions liées à la sécurité. Si un auditeur examine votre dépôt, 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 de sécurité, le projet de loi élève les attentes, passant d'une supervision consultative à une responsabilité exécutoire. La conformité devient un workflow continu plutôt qu'un exercice annuel.

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

2. Plus de pression pour les workflows automatisés de gestion des vulnérabilités : Le scan manuel ne suffit plus. Vous aurez besoin de pipelines automatisés qui détectent les problèmes, les priorisent, notifient les bonnes personnes et suivent la remédiation jusqu'à son achèvement.

3. Structures de reporting obligatoires : Il est attendu de vous que vous mainteniez un processus clair de réception des vulnérabilités, favorisiez le partage d'informations entre les équipes et produisiez une documentation qui peut être remise aux régulateurs sur demande.

4. La charge de la preuve des mesures de sécurité raisonnables : Il ne suffit plus de dire que vous avez un processus. Vous devez présenter des métriques, des calendriers, des historiques de tickets, des logs, des SBOMs 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 vélocité d'ingénierie. Le projet de loi encourage un alignement plus étroit entre les fonctions DevOps, d'ingénierie de plateforme et de sécurité.

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

Projet de loi britannique sur la cybersécurité et la résilience vs le Cyber Resilience Act (CRA) de l'UE

De nombreuses organisations supposent que le projet de loi britannique sur la cybersécurité et la résilience n'est qu'un équivalent régional du Cyber Resilience Act de l'UE.

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

Ce que couvre le Cyber Resilience Act de l'UE

Le CRA de l'UE se concentre sur les produits comportant des éléments numériques et s'applique à l'ensemble du marché unique de l'UE. Il cible les fabricants, les importateurs et les distributeurs, en veillant à ce que les produits répondent aux mêmes attentes en matière 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 sécurisés dès leur sortie d'usine, sans nécessiter d'expertise de la part de l'utilisateur.

2. Obligations d'évaluation des risques : Les produits doivent faire l'objet d'évaluations des risques structurées avant d'être mis sur le marché.

3. Processus obligatoires de gestion des vulnérabilités : La réception des vulnérabilités, l'évaluation des risques et la remédiation doivent suivre des procédures définies.

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

Où le projet de loi britannique sur la cybersécurité et la résilience et le Cyber Resilience Act de l'UE se chevauchent

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

• Exigences de développement sécurisé
• Gestion des vulnérabilités obligatoire
• Transparence tout au long de la chaîne d'approvisionnement logicielle
• Surveillance de la sécurité post-commercialisation ou post-déploiement
• Documentation et conformité basée sur des preuves

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

Différences clés

Pourquoi il est difficile de se conformer au projet de loi britannique sur la cybersécurité et la résilience

Les attentes du projet de loi sur la cybersécurité et la résilience semblent simples sur le papier. En 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 matures ont du mal à maintenir une conformité continue lorsque chaque commit, déploiement et mise à jour de dépendance introduit de nouveaux risques.

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 au scan de code. Les images de conteneurs, les définitions d'infrastructure et les charges de travail en temps 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 directives incohérentes. Cela ralentit la remédiation et rend la priorisation peu fiable.
4. Les feuilles de calcul d'audit et les listes de contrôle périodiques ne peuvent pas suivre le rythme des changements de code quotidiens, des mises à jour de 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éagi, combien de temps la remédiation a pris et quelles décisions ont été prises. La plupart des organisations manquent de cette documentation.
6. Les choix architecturaux, les modèles de codage et les décisions de configuration doivent être étayés par une justification traçable. Sans documentation structurée, cela devient difficile à présenter lors des audits de conformité.
7. Les résultats se trouvent souvent dans un outil tandis que les tickets sont gérés dans un autre. Il est donc difficile de vérifier que les problèmes ont été triés, priorisés, attribués et résolus à temps.

Ces défis expliquent pourquoi les organisations ont besoin d'un moyen unifié de surveiller les risques, de coordonner la remédiation et de produire des preuves automatiquement. C'est aussi le point naturel où Aikido Security devient pertinent en tant que moteur central de visibilité et de conformité.

Comment Aikido vous permet de vous conformer aux exigences du projet de 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 de simples analyses périodiques ou d'outils de sécurité isolés. Elles ont besoin d'une plateforme leur offrant des outils de pointe pour une visibilité continue, une évaluation cohérente des risques et des preuves qu'elles peuvent fournir aux régulateurs sans avoir à fouiller dans des feuilles de calcul. Aikido Security s'inscrit dans ce cadre en offrant un point de contrôle centralisé pour les équipes d'ingénierie modernes.

Aikido est une plateforme de sécurité cloud-native qui centralise tous vos signaux de sécurité. Elle offre une visibilité sur vos bases de code, vos dépendances open source, vos modèles d'infrastructure as code, vos images de conteneurs, vos secrets et vos pipelines d'intégration continue.

Au lieu de forcer les équipes à gérer des scanners distincts, Aikido corrèle les vulnérabilités à travers ces couches, met en évidence ce qui est réellement exploitable et élimine le bruit qui ralentit la remédiation.

Bien qu'Aikido puisse aider à satisfaire un grand nombre d'exigences, certaines devraient être satisfaites par d'autres fournisseurs, telles que le signalement d'incidents et les attentes en matière de résilience opérationnelle continue. 

Vous trouverez ci-dessous une explication de la manière dont Aikido vous aide à respecter les obligations fondamentales de la loi britannique sur la cybersécurité et la résilience.

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

Le problème : Il est attendu de vous que vous conceviez des logiciels sécurisés dès la première ligne de code. Cela implique d'identifier les configurations non sécurisées tôt, de réduire les risques liés aux dépendances et de s'assurer que les développeurs ne sont pas submergés par des résultats non pertinents.

Comment Aikido y répond

• 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 aucune zone critique.
• Corréle les problèmes provenant de multiples sources afin de réduire le bruit pour les développeurs et de mettre en évidence les risques réels.
• Applique des workflows sécurisés dans les pipelines CI et CD afin que les vulnérabilités ne puissent pas passer silencieusement en production.

2. Exigence : Transparence des SBOM et inventaire logiciel précis

Le problème : Vous devez maintenir un Software Bill of Materials précis et à jour. Le suivi manuel devient obsolète instantanément lorsque de nouvelles dépendances sont ajoutées ou que des bibliothèques transitives changent.

Comment Aikido y répond

• Générez un SBOM en un clic
• Construit un SBOM complet pour chaque dépôt grâce au Générateur de SBOM d'Aikido pour une visibilité claire des dépendances.
• Offre une visibilité complète sur les bibliothèques directes et transitives.
• Vous alerte lorsque les composants SBOM reçoivent de nouvelles CVE.
• Permet d'exporter les SBOMs pour les auditeurs ou les revues internes en une seule action.

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

Le problème : La loi vous demande de détecter les vulnérabilités, de les prioriser, d'attribuer la responsabilité et de prouver que vous avez respecté les délais de remédiation. Des outils fragmentés rendent cela presque impossible sans automatisation.

Comment Aikido y répond

• Détecte les vulnérabilités dans les dépôts, les images de conteneurs et les registres.
• Priorise les résultats en utilisant les données d'exploitabilité, le CVSS et le renseignement sur les menaces afin que les équipes se concentrent sur ce qui est important.
• Automatise les workflows de remédiation grâce à l'intégration Jira ou Slack.
• Horodate et enregistre chaque action, créant une piste d'audit claire pour les auditeurs.
• Documente automatiquement les délais de remédiation, répondant aux attentes des régulateurs.

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

Le problème : La plupart des organisations dépendent fortement des packages 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 y répond

• Identifie et analyse les compromissions par logiciels malveillants tôt, souvent avant qu'elles ne se propagent. Aikido est le premier à détecter les comportements de packages malveillants, les versions compromises ou les changements de dépendances suspects qui pourraient avoir un impact dévastateur sur votre chaîne d'approvisionnement.
• Évalue le risque lié aux dépendances 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 packages potentiellement malveillants ou les tentatives de typosquatting avant qu'ils n'entrent dans votre codebase.
• Signale 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 de montrer exactement d'où provient une dépendance, quels services elle impacte et comment elle a été corrigée lors des contrôles de conformité.

5. Exigence : Assurance basée sur des preuves pour les régulateurs britanniques

Le problème : Il ne suffit pas de prétendre que vous avez de bonnes pratiques de sécurité. Vous devez le prouver par des preuves structurées, des registres historiques et des rapports de risques transparents.

Comment Aikido y répond

• Produit des rapports automatisés, prêts pour la conformité qui associent les constatations aux attentes réglementaires.
• Affiche les chronologies historiques des vulnérabilités qui démontrent une gestion des risques à long terme.
• Documente l'activité de remédiation afin que les auditeurs puissent comprendre ce qui a changé et pourquoi.
• Offre une vue claire des mesures de sécurité raisonnables prises au sein de votre organisation.
• Agrège les informations sur les risques dans des vues adaptées aux dirigeants qui aident les équipes de direction à remplir leurs obligations de reddition de comptes.

Au-delà d'ISO27001, SOC2, NIS2 et CIS : Ce qu'ajoute le projet de loi britannique sur la cybersécurité et la résilience

La plupart des organisations maintiennent déjà leur conformité avec des cadres établis tels qu'ISO 27001, SOC2, les benchmarks CIS, NIS2 ou PCI. Ces cadres se concentrent sur la gestion de la sécurité organisationnelle. Ils définissent comment gérer les risques, documenter les politiques, contrôler l'accès, surveiller les événements et répondre aux incidents. 

Aikido prend déjà en charge ces standards :

• Conformité ISO 27001:2022 
• Conformité SOC2 
• Conformité au Top 10 OWASP
• Conformité CIS 
• conformité NIS2
• Conformité 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 nouveau type d'exigence. Il va au-delà des contrôles organisationnels et impose des attentes strictes concernant la 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, une transparence vérifiable des SBOM, une gestion continue des vulnérabilités, une assurance de la chaîne d'approvisionnement et des preuves des délais de remédiation. Ces obligations s'appliquent directement à vos pratiques d'ingénierie, à vos pipelines CI, à vos bases de code, à vos dépendances, à vos conteneurs, à vos actifs cloud et à vos flux de travail opérationnels.

Cela crée une nouvelle lacune : vous pouvez être conforme aux normes ISO 27001 ou SOC2 et ne pas satisfaire aux exigences du projet de loi britannique si votre produit est livré avec des vulnérabilités exploitables, des bibliothèques obsolètes, des contrôles de chaîne d'approvisionnement faibles ou des flux de remédiation non documentés. Les cadres traditionnels ne couvrent pas ces domaines de manière suffisamment approfondie.

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

Aikido Security : 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 clair dans la manière dont les organisations sont censées aborder la sécurité. Il est contraignant, et non consultatif, et il exige des équipes qu'elles démontrent leur résilience par des preuves, et non par de simples intentions. Le Cyber Resilience Act de l'UE s'y ajoute avec des portées et des responsabilités différentes, ce qui signifie que les organisations opérant dans plusieurs régions ont besoin d'une approche nuancée qui respecte les deux cadres plutôt que de les traiter comme interchangeables.

Aikido vous offre la base opérationnelle 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 recevez une évaluation des risques cohérente, des flux de travail de remédiation automatique et des pistes d'audit auxquels les régulateurs peuvent faire confiance. La conformité devient quelque chose que vous maintenez au quotidien, plutôt qu'un point de contrôle annuel stressant.

Avec le bon niveau d'automatisation et le bon niveau d'observabilité, vous réduisez les risques, améliorez la vitesse de livraison et éliminez l'incertitude qui entoure la préparation réglementaire typique. Aikido vous aide à transformer des exigences complexes en processus gérables et reproductibles qui évoluent avec vos équipes d'ingénierie.

Si vous souhaitez une conformité qui suit le rythme du projet de loi britannique, s'aligne sur les attentes du Cyber Resilience Act de l'UE et s'intègre naturellement à votre flux de travail de développement, commencez dès aujourd'hui avec Aikido Security.

Vous pourriez aussi aimer :

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

• Comment Aikido et Deloitte apportent la sécurité axée sur les développeurs aux entreprises — Aikido et Deloitte s'associent pour une meilleure expérience et sécurité des développeurs en entreprise
• Se conformer au Cyber Resilience Act (CRA) avec Aikido Security — Se conformer au CRA de l'UE avec Aikido Security