Votre organisation est-elle vraiment prête pour le DevSec ? Mettez-la à l'épreuve.

Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.

Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.

En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?

DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?

1. La sécurité est-elle au cœur du processus de développement interne ?
   Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
   DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
   ‍
2. Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
   Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
   La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
   ‍
3. Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
   Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
   ‍
4. Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
   D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
   
   Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
   
   DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
   ‍
5. Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
   Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
   
   Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.

Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.

Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.

La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.

Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.

Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.

Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).