Toutes les équipes s'accordent sur l'importance d'un développement sécurisé. Mais lorsqu'il s'agit de la propriété ? Soudain, tout le monde se tourne vers quelqu'un d'autre. Les développeurs pensent que c'est le travail de la sécurité. Les équipes de sécurité attendent des développeurs qu'ils écrivent un code plus sûr. DevOps veut simplement maintenir le pipeline en vie. Et les responsables ? Ils veulent de la sécurité sans ralentir l'expédition.

En réalité, le développement de logiciels sécurisés n'est pas l'affaire d'une seule personne, c'est l'affaire de tous. Cela signifie qu'il faut définir clairement les rôles, les responsabilités et, surtout, les attentes. Si cette partie n'est pas bien définie, tout l'effort de développement de logiciels sécurisés se transforme en un jeu de blâme au ralenti. Voyons qui est dans l'arène, ce qui les empêche de dormir la nuit et ce qu'ils recherchent vraiment à 2 heures du matin.

Image de remplacement : Description de l'image : Diagramme des rôles de l'équipe de développement interfonctionnelle avec des flèches indiquant les responsabilités en matière de codage, de tests, d'outils et de livraison sécurisés.

L'équipe : Qui est qui dans l'arène du développement sécurisé

Développeurs : Dans les tranchées, à l'assaut du code, à l'abri des CVE

Les développeurs sont les plus proches du code et sont souvent les premiers à être blâmés lorsque quelque chose ne fonctionne pas. On attend d'eux qu'ils écrivent du code sécurisé, même si on ne leur a jamais appris à le faire. Ils sont confrontés à une fatigue d'alerte due à des outils bruyants et à des conseils contradictoires. Ce dont ils ont besoin : des conseils de sécurité intégrés dans leur flux de travail, et non pas ajoutés après coup.

Ingénieurs DevOps : Maîtres du pipeline, jonglant avec les outils et les configurations dans le nuage

DevOps assure le fonctionnement du pipeline et la fluidité des déploiements. Ils gèrent les secrets, l'infrastructure en tant que code, les configurations de conteneurs et l'intégration CI/CD. On attend souvent d'eux qu'ils " fassent fonctionner la sécurité " dans l'ensemble de la pile, sans interrompre la construction. Ce dont ils ont besoin : une sécurité qui s'intègre dans l'automatisation existante, et non des étapes manuelles supplémentaires.

Ingénieurs en sécurité (AppSec/Sécurité des produits) : Les guides, les gardiens et parfois les goulots d'étranglement

Les équipes de sécurité rédigent des politiques, choisissent des outils et tentent d'étendre leur influence sur des dizaines (ou des centaines) de développeurs. Elles ont besoin d'outils qui réduisent le bruit, mettent en évidence ce qui est réellement important et aident les développeurs à résoudre les problèmes sans qu'il y ait d'allers-retours entre les tickets.

Directeurs techniques : des chats en liberté, un équilibre entre les fonctionnalités et la santé mentale

Les responsables sont sur la corde raide entre la vitesse et le risque. Ils sont évalués en fonction des fonctionnalités livrées, mais aussi des temps d'arrêt, des incidents et de la conformité. Ils ne sont pas des experts en sécurité, mais on attend d'eux qu'ils prennent des décisions qui mettent l'entreprise à l'abri des problèmes. Ils ont besoin de visibilité, de mesures et de l'adhésion de toutes les équipes.

Ce qui les empêche de dormir

Pour les développeurs : "Sécurité contre rapidité", l'enfer des outils (tant. d'alertes.), le syndrome "ce n'est pas mon travail".

Les développeurs craignent les outils qui bloquent les déploiements et les inondent de problèmes de faible priorité. Ils veulent un retour d'information rapide et exploitable, de préférence dans leur IDE ou leurs PR. Ils détestent tout ce qui ressemble à un blâme sans soutien.

Pour DevOps : goulets d'étranglement dans les pipelines, cauchemars de configuration, secret de fabrication

Les DevOps veulent moins d'étapes manuelles et moins de surprises. Ils craignent de pousser accidentellement des données sensibles ou d'ouvrir un panier S3 au monde entier. Ils ont besoin de politiques et d'outils clairs qui ne font pas dérailler l'automatisation.

Pour les responsables de la sécurité : Trop de bruit, trop peu de ressources, toujours à rattraper

Les équipes de sécurité sont submergées par les alertes, les faux positifs et la prolifération des outils. Elles sont fatiguées d'être réactives. Ce qu'elles recherchent, c'est un contexte, une hiérarchisation des priorités et des moyens d'anticiper les risques, sans avoir à s'occuper de chaque déploiement.

Pour les managers : Justifier les coûts, gérer les risques, trouver des personnes qui maîtrisent le sujet

Les responsables s'inquiètent du retour sur investissement. Cet outil de sécurité en vaut-il la peine ? L'équipe l'utilise-t-elle au moins ? Ils sont également contraints d'essayer d'embaucher des ingénieurs "licornes" qui comprennent à la fois le code et la sécurité. Ils veulent des gains concrets, pas un autre tableau de bord à gérer.

Ce qu'ils recherchent réellement sur Google (et ce à quoi ce forum répondra)

Requêtes des développeurs

• "codage sécurisé [ma langue]"
• "Comment stopper rapidement une injection SQL"
• "Le Top 10 de l'OWASP expliqué aux humains"

Les développeurs veulent des réponses claires et pratiques. Ils ne recherchent pas des PDF de 80 pages - ils veulent des solutions faciles à copier et des conseils de codage sécurisé spécifiques à chaque langue.

Requêtes DevOps

• "Automatiser la sécurité en CI/CD sans tout casser" 
• "Outils d'analyse de sécurité pour Terraform" 
• "Les meilleures pratiques de sécurité Docker qui ne datent pas de 2015"

DevOps cherche des moyens d'intégrer la sécurité dans les outils qu'ils utilisent déjà, sans interrompre les déploiements ou ralentir les constructions.

Questions de sécurité :

• "Guide de mise en œuvre du SSDLC pour l'agile"
• "La modélisation des menaces que les développeurs ne détesteront pas
• "Comparaison des outils SAST"

Les ingénieurs en sécurité veulent évoluer. Ils sont à la recherche d'outils et de playbooks qui s'intègrent à l'approche agile et aident réellement à passer à la gauche, sans être constamment surveillés.

Requêtes du gestionnaire : 

• "Coût d'une violation de données par rapport à l'investissement dans la sécurité
• "Formation à la sécurité des développeurs ROI"
• "comment construire une culture de la sécurité qui n'implique pas de perte de confiance".

Les responsables sont à la recherche de chiffres concrets, d'investissements justifiables et de méthodes légères pour assurer un développement sécurisé, sans nuire à la vélocité ou au moral de l'équipe.

Tout le monde veut des logiciels sûrs. Personne ne veut plus de travail. La clé est de comprendre les points douloureux de chaque rôle et de leur fournir des outils et des processus qui fonctionnent avec leur flux - et non contre lui. 

Il est temps d'analyser ce qui motive réellement les équipes à adopter des pratiques sûres et ce qui les en empêche généralement.