Que signifie « Déplacer la sécurité vers la gauche ? » –

« Shift left security » fait référence à un modèle de développement logiciel qui prend pleinement en compte la sécurité dès le départ. Jusqu’à tout récemment, la sécurité avait tendance à venir à la toute fin du processus sous la forme d’un audit de mise en service. Cela entrave la visibilité de votre posture de sécurité globale, permettant aux menaces de passer inaperçues.

Le concept de déplacement vers la gauche est un élément essentiel de DevSecOps, l’extension DevOps qui considère la sécurité comme un composant de première classe. Il tente de combler le fossé entre les développeurs, les équipes d’exploitation et les experts en sécurité, en encourageant toutes les parties prenantes à réfléchir quotidiennement à la situation globale de la sécurité.

Concevoir pour la sécurité

Compte tenu de la sécurité au début, il est plus probable que vous vous retrouviez avec un système étanche. Le laisser à une équipe dédiée à la fin augmente la probabilité que vous oubliiez des problèmes enfouis profondément dans les chemins de code.

Le déplacement de la sécurité vers la gauche reconnaît correctement son importance et rend plus d’individus responsables de sa mise en œuvre. Les développeurs doivent être conscients des implications globales de sécurité de leur code, sans s’appuyer sur les audits d’une équipe dédiée. Cela ne veut pas dire qu’une équipe distincte est complètement redondante : un examen préalable au lancement est toujours une bonne idée, mais cela devrait prendre moins de temps si la sécurité est déjà intégrée depuis le début.

L’approche modifiée contribue à favoriser une culture DevOps productive. La collaboration entre les équipes est améliorée en discutant du développement et de la sécurité en parallèle, au lieu de suivre un flux linéaire rigide.

Les développeurs doivent être conscients du contexte de sécurité au niveau de l’application et de l’organisation dans lequel leur code fonctionnera. Certaines mesures de sécurité, telles que le cryptage robuste des mots de passe et la vérification des clés, sont déjà des valeurs par défaut de facto ; d’autres, comme l’analyse active des vulnérabilités et l’audit généralisé des événements, varient considérablement d’une organisation à l’autre. Ils pourraient être omis par les nouveaux développeurs peu familiers avec les normes de sécurité du projet.

Les agents de sécurité doivent également comprendre le point de vue de l’équipe de développement. La mise en œuvre des mesures de sécurité les plus strictes peut ajouter de la complexité au code, augmentant ainsi la chronologie du projet. Cela touche les équipes de gestion de projet et les parties prenantes de l’entreprise, qui bénéficient également d’une meilleure visibilité sur la posture de sécurité de l’application.

Au-delà de vos composants logiciels, vous devez également examiner votre pile réseau et tous les périphériques physiques de votre infrastructure. Les produits IoT en particulier peuvent présenter des faiblesses uniques qui permettent aux attaquants de prendre pied dans votre système. Les personnes qui supervisent ces systèmes doivent également être informées de vos bases de référence en matière de sécurité.

Comment passer à gauche ?

Le déplacement à gauche n’est pas quelque chose qui se produit du jour au lendemain. Un changement efficace dépend d’un changement de mentalité dans l’ensemble de l’organisation. Vous pourriez passer un après-midi à discuter de la sécurité dans un stand-up à tous les niveaux, mais à moins que des changements ne soient adoptés, testés et répétés, vous n’êtes pas mieux que ce que vous étiez le matin.

Tout d’abord, il est important de définir les exigences fondamentales de sécurité de votre système. Un ensemble clairement documenté de bases techniques, de routines procédurales et de lignes de base de conformité met tout le monde sur la même longueur d’onde, qu’ils viennent de « dev », « sec » ou « ops ». Vous pouvez utiliser les normes communautaires populaires telles que les directives OWASP comme point de départ.

Ensuite, examinez votre processus existant. Où la sécurité s’intègre-t-elle? S’il s’agit de votre première tentative de déplacer la sécurité vers la gauche, vous constaterez peut-être que la sécurité se situe loin vers la droite. Analysez votre processus pour identifier où la sécurité pouvait dans quelles discussions la sécurité doit-elle apparaître ?

Vous voulez que cela soit le plus tôt possible, mais la position exacte variera selon l’organisation. Dans un monde idéal, la sécurité sera prise en compte une fois que la fonctionnalité du projet aura été entièrement définie, mais avant qu’une architecture technique solide n’ait été sélectionnée. Cela vous donne la possibilité de faire des choix soucieux de la sécurité sans vous soucier de devoir recommencer lorsque la spécification sera décidée.

Avant le début du développement, donnez à chacun un aperçu du modèle de sécurité du système. Faites en sorte que le développement soit responsable de la mise en œuvre des normes techniques tandis que les équipes d’exploitation s’assurent que les environnements de production respectent les lignes de base convenues.

Pendant et après le développement, le code doit être audité, interrogé et analysé pour s’assurer qu’il fonctionne réellement comme prévu. Vous avez besoin d’un moyen de vérifier que le code et les composants d’infrastructure possèdent les qualités que vous avez spécifiées.

Heureusement, les outils de sécurité évoluent au même rythme que les méthodologies qu’ils facilitent. L’analyse automatisée des vulnérabilités permet aux développeurs de vérifier que le code est sûr sans augmenter le temps qu’ils passent à l’écrire. De même, l’analyse des dépendances tierces utilisées dans les projets permet de se défendre contre la marée montante d’attaques de la chaîne d’approvisionnement.

Vous pouvez utiliser la nouvelle génération d’outils de test API fuzz pour effectuer des analyses de sécurité de vos points de terminaison actifs. Ceux-ci peuvent aider à découvrir des problèmes qui ne s’affichent que dans des scénarios spécifiques, améliorant ainsi la couverture de vos tests de sécurité.

Un autre aspect de l’outillage concerne l’expérience quotidienne des développeurs. L’utilisation de linters et de plug-ins intégrés à l’éditeur fournit un retour immédiat ligne par ligne, signalant les problèmes au moment où ils entrent le code. Une stratégie de révision et de fusion efficace garantit qu’il y a plusieurs yeux sur chaque changement.

Automatisez autant de vos contrôles que possible. Cela atténue les pertes de temps et aidera à garder les membres de l’équipe à bord. L’ajout de complexité au processus pourrait entraîner de la frustration, incitant éventuellement les développeurs à rechercher des moyens de contourner les contrôles de sécurité.

Les avantages de passer à gauche

Les organisations qui réussissent à passer à gauche bénéficient d’une posture de sécurité améliorée qui est plus facile à maintenir au fil du temps. Il en résulte une culture soucieuse de la sécurité où tout le monde comprend les contrôles du système et pourquoi ils sont présents.

Déplacer la sécurité vers la gauche peut également améliorer la qualité du code et conduire à des conceptions architecturales plus avancées. Intégrer la sécurité dès le départ peut découvrir des stratégies alternatives qui résolvent des problèmes plus larges que la seule sécurité. Il promeut également les pratiques de développement modernes en encourageant l’utilisation d’outils automatisés.

Le modèle peut également atténuer les pressions du jour de la libération. Il n’y a pas de bousculade folle pour auditer les solutions avant leur mise en ligne, car elles auront été continuellement évaluées tout au long du processus de développement. Trouver les problèmes plus tôt a tendance à les rendre plus faciles et moins coûteux à résoudre. Si un problème de sécurité est détecté en cours de développement, il peut être résolu en toute sécurité sans aucun impact sur les données client.

Résumé

« Déplacer vers la gauche » fait référence à l’élévation de la position de la sécurité dans le cycle de vie du développement logiciel à une position de priorité et de référence continue. Cela remet en question la perception selon laquelle la sécurité est souvent une réflexion après coup, évaluée à la hâte juste avant le lancement d’un nouveau système.

S’attaquer à la sécurité dès le premier jour vous offre une plus grande tranquillité d’esprit, une plus grande collaboration entre les membres de l’équipe et une détection plus précoce des problèmes. Vous ne serez pas à la recherche de problèmes de sécurité tard dans la journée, car ils apparaîtront lors de la planification, du développement ou de la révision du code. Cela permet aux rejets de s’écouler en douceur et en toute sécurité.

Le déplacement de la sécurité à gauche s’harmonise bien avec d’autres concepts modernes tels que les méthodologies natives du cloud et les procédures DevOps. Ils vous aident tous à créer des logiciels plus résilients dans un délai plus court sans compromettre l’expérience du développeur. Face à la multiplication des cyberattaques, prendre le temps de mieux intégrer la sécurité dans votre processus de développement vous aidera à défendre vos données et vos clients contre les menaces émergentes.