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 nous sommes déjà en passe d'établir un triste 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. Aujourd'hui, il est plus pertinent de se demander quelle quantité de données n'a pas encore été volée. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en intensité, ciblant des points de plus en plus vulnérables.

C'est un fait que nous connaissons tous depuis un moment : la sécurité n'est plus optionnelle et nous devons adopter une approche préventive. Pour que cela soit efficace, chaque personne au sein du cycle de vie du développement logiciel (SDLC) doit être sensibilisée à la sécurité, en particulier les développeurs. C'est là tout l'enjeu du « DevSec » dans DevSecOps, une méthodologie de développement idéale pour le climat actuel, mais de nombreuses organisations ne sont pas encore prêtes à l'appliquer efficacement.

En pensant à votre organisation, réfléchissez à ces questions dans le contexte de votre rôle. Comment s'en sortirait-elle face au test DevSec ?

Auto-évaluation DevSec : votre SDLC est-il prêt à faire éclore des ingénieurs sensibilisés à la sécurité ?

1. La sécurité est-elle au cœur du processus de développement interne ?
   De nombreux facteurs de risque en cybersécurité peuvent empêcher un RSSI de dormir, mais la réalité préoccupante est que, bien que beaucoup d'entreprises fassent de la sécurité une priorité, leur approche interne n'est pas toujours assez robuste pour éviter un désastre potentiel (ou, à tout le moins, des maux de tête majeurs pour l'équipe AppSec et des retards dans la livraison des logiciels).
   Le DevSecOps représente peut-être le nirvana de la sécurité, mais peu d'entreprises utilisent cette méthodologie. Si vous utilisez encore Agile, ou même Waterfall, la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus, intervenant tardivement dans le SDLC pour gâcher la journée des développeurs avec des correctifs urgents. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs privilégient la création de fonctionnalités et n'auront pas eu assez d'expérience pratique en sécurité pour y voir une compétence valorisante. En fait, leurs interactions avec ce domaine sont souvent synonymes de frustration. Il faut remédier à cela rapidement pour ancrer une approche proactive chez tous les acteurs du développement logiciel.
   ‍
2. Votre organisation est-elle toujours à la traîne en matière de modélisation des menaces ?
   C'est une statistique qui donne à réfléchir : 60 % des PME font faillite dans les six mois suivant une cyberattaque réussie, et comme pour tout désastre, l'impact est bien plus grave sans une planification adéquate.
   La modélisation des menaces est un élément crucial des bonnes pratiques de sécurité, permettant aux professionnels de l'AppSec d'évaluer l'étendue de la surface d'attaque et de structurer des défenses, des contre-mesures et une planification appropriées. Dans les entreprises ayant pleinement adopté le DevSecOps, la sécurité est intégrée tôt dans le pipeline CI/CD, sans ralentir la production comme par le passé. La sécurité, le codage sécurisé et la livraison continue font partie intégrante du processus, et les équipes de développement disposent des ressources nécessaires pour devenir des acteurs clés de la production de code inviolable.
   ‍
3. Les responsables du développement donnent-ils la priorité aux bonnes pratiques de sécurité ?
   Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et cela ne concerne pas seulement la culture d'entreprise ou la manière de « gérer vers le haut ». Leurs priorités de travail seront inévitablement adoptées par les membres de leur équipe. Si la sécurité ne fait pas partie des objectifs clés ou n'est pas prévue en termes de formation et de soutien, les ingénieurs en pâtiront et l'entreprise sera plus exposée aux risques qu'elle ne devrait l'être.
   ‍
4. Les développeurs ont-ils une raison de se soucier de la sécurité ?
   D'après mon expérience, le moyen le plus rapide de braquer quelqu'un est de lui imposer une tâche étrangère à ses habitudes sans lui en expliquer la raison.
   
   Demander de « changer » implique que l'approche précédente était mauvaise, alors qu'il s'agit souvent d'une amélioration visant à simplifier et optimiser le travail. Pour adopter réellement le mouvement DevSec, les développeurs doivent avoir une raison de s'intéresser à la sécurité. Après tout, dans la plupart des organisations, cela reste « le problème de quelqu'un d'autre » (les experts AppSec isolés dans un autre bureau).
   
   Le DevSecOps ne fonctionne pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin d'outils, de soutien et de formation pour jouer leur rôle... ce qui demande du temps pour être déployé et perfectionné. La pire approche est celle qui submerge et aliène, ce qui arrive quand les développeurs ont trop de priorités concurrentes sans aide pour les gérer. C'est un changement culturel qui ne se fait pas du jour au lendemain.
   ‍
5. Comptez-vous sur une poignée de licornes de la sécurité pour accomplir la tâche de beaucoup ?
   Les professionnels de la sécurité sont très rares, et nous en avons besoin de bien plus. C'est un fait, mais de plus en plus de développeurs s'orientent vers des rôles axés sur la sécurité. Ils portent souvent des titres comme « ingénieur sécurité » ou « ingénieur DevOps » (avec un peu de chance, ce titre évoluera vers ingénieur DevSecOps !). Un excellent ingénieur DevOps peut développer des fonctionnalités pour presque n'importe quelle application tout en utilisant un véritable pipeline CI/CD. Il gère tout de bout en bout, généralement avec une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont rares et précieux.
   
   Cependant, certaines entreprises commettent l'erreur d'embaucher ces spécialistes, de les intégrer à une équipe et d'attendre d'eux qu'ils règlent tous les problèmes de sécurité à chaque étape. Surcharger vos magiciens DevSecOps vous ramènera à la case départ : livrer du code non sécurisé sans les contrôles et la précision qu'ils étaient censés apporter. Il est primordial que l'équipe de développement soit formée et soutenue dans un environnement positif pour partager cette charge de manière significative.

Trouvez le changement que vous souhaitez voir dans votre organisation.

Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez des talents cachés parmi vos développeurs. Ce sont des personnes qui, malgré des expériences parfois négatives, ont une réelle passion pour le codage sécurisé et les bonnes pratiques. Ces profils sont des candidats idéaux 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, maintient la vigilance et aide aux initiatives d'engagement. Leurs compétences relationnelles sont également essentielles pour diffuser la culture de la sécurité et défendre les besoins des développeurs auprès de la direction.

La question « qu'est-ce que j'y gagne ? » est un pas en avant positif.

Même les plus nobles d'entre nous ont besoin d'une « carotte » pour s'aventurer en terrain inconnu ou s'engager dans une activité à la courbe d'apprentissage ardue.
Passer du « dev » au « DevSec » est un formidable tremplin pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre ces enjeux, en assumer la responsabilité là où ils le peuvent, et agir avec la conviction que seul un code sécurisé est un code de qualité. En général, les développeurs veulent progresser, relever de nouveaux défis et créer des fonctionnalités remarquables. Offrez-leur une voie vers un niveau supérieur de développement logiciel, et tout le monde y gagnera.

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

Si vous gérez des développeurs, dirigez une équipe de sensibilisation AppSec ou concevez des stratégies de sécurité, il est temps d'aller plus loin que le simple « shift left ». Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui portera ses fruits pour toutes les parties. Si cette liste a mis en lumière des points à améliorer, vous avez une excellente occasion de préparer votre organisation à un département d'ingénierie axé sur le DevSec, capable de réduire les risques dès le début du SDLC.