Mise en place d'une stratégie de sécurité pour les développeurs au sein d'une entreprise comptant plus de 5 000 ingénieurs

Les grandes entreprises d'ingénierie aiment à croire que leurs principaux problèmes sont d'ordre technique. Si seulement quelqu'un voulait bien approuver le budget pour le dernier outil à la mode, tout serait réglé. Ces derniers temps, on parie généralement que la solution miracle réside dans le « vibe coding », alimenté par votre modèle de langage de grande capacité (LLM) préféré. Mais les maux dont souffrent les grandes entreprises sont rarement d'ordre technique. 

D'après mon expérience, il s'agit de problèmes liés aux processus qui peuvent se manifester aux deux extrémités d'un spectre. D'un côté, on trouve des équipes enlisées dans une paralysie analytique, qui enchaînent sans fin les réunions, les revues et les phases de conception axées sur le consensus, sans grand résultat. De l'autre côté, on trouve ceux qui « se jettent à l'eau sans réfléchir », dont la tendance à l'action aveugle entraîne de nombreuses erreurs dues à un manque d'introspection.

À partir du moment où une organisation dépasse les 5 000 contributeurs actifs, la nature même de la transformation en matière de sécurité change du tout au tout. Les outils ne constituent plus un frein. Le budget ne constitue plus un frein. Même les compétences ne constituent plus un frein. Ce qui vient à manquer, c'est la coordination.

En réalité, lorsqu’une entreprise atteint cette taille, elle dispose déjà d’un dispositif de sécurité opérationnel, d’une tolérance au risque bien définie et d’une structure de sécurité organisée selon des ratios de personnel assez courants. On observe généralement un ratio d’un professionnel de la sécurité pour 100 ingénieurs, ce qui signifie qu’une entreprise comptant 5 000 développeurs dispose probablement d’une équipe de sécurité de 50 personnes qui tente d’influencer des milliers de décisions logicielles chaque jour. La question n’est pas de savoir si la sécurité existe. La question est de savoir si elle est évolutive.

Cet article présente les enseignements tirés de la mise en place de programmes de sécurité destinés aux développeurs au sein d'organisations de cette envergure, et explique pourquoi la voie vers la réussite s'avère très différente de ce à quoi s'attendent la plupart des RSSI.

Pourquoi les initiatives de sécurité mises en place par les développeurs échouent à l'échelle de l'entreprise

La plupart des déploiements de mesures de sécurité échouent pour une raison étonnamment simple : ils sont conçus comme des déploiements de logiciels plutôt que comme des changements culturels. Les responsables de la sécurité partent souvent du principe que la bonne combinaison d'outils (par exemple, SAST, SCA, analyse des conteneurs, détection de secrets) donneront de meilleurs résultats s’ils sont déployés à une échelle suffisamment large. Mais l’adoption des outils est la partie la plus facile.

Le plus difficile réside dans la hiérarchisation des priorités au sein des équipes d'ingénierie. Les développeurs ont déjà plus de travail qu'ils ne peuvent en accomplir en un sprint. Les échéances des produits dictent la hiérarchisation du backlog. La rapidité de développement des fonctionnalités est visible et récompensée. Les correctifs de sécurité apparaissent souvent comme abstraits et imposés de l'extérieur. Lorsqu'un programme de sécurité est mis en place dans cet environnement, la réaction habituelle est prévisible : des tickets de sécurité sont créés, ils sont ajoutés au backlog et s'accumulent discrètement.

La portée des analyses ne change en rien cette réalité. En fait, plus on met en évidence de problèmes sans qu'aucune responsabilité ne soit clairement attribuée, plus la situation empire. Les équipes de sécurité pensent souvent réduire les risques en améliorant la visibilité, mais dans la pratique, elles amplifient parfois les risques non maîtrisés. Car tout le monde sait que les problèmes existent, mais personne ne s'en charge vraiment.

‍

Les contraintes incontournables auxquelles est confrontée toute entreprise comptant plus de 5 000 ingénieurs

Les grandes entreprises d'ingénierie sont soumises à un ensemble de contraintes structurelles auxquelles les petites entreprises sont rarement confrontées. Tout d'abord, il y a la fragmentation du cycle de vie du développement logiciel (SDLC). Une entreprise comptant des milliers d'ingénieurs gère presque certainement plusieurs cycles de développement en parallèle. Certaines équipes effectuent des déploiements quotidiens. D'autres, trimestriels. Certaines s'appuient sur des systèmes hérités, mis en place il y a une dizaine d'années, que personne n'ose toucher de peur qu'ils ne cessent complètement de fonctionner et ne deviennent leur problème personnel. Ensuite, il y a l'hétérogénéité technologique. Un environnement d'entreprise type peut inclure des dizaines de langages de programmation, plusieurs systèmes CI/CD, diverses plateformes d'infrastructure et un mélange de workflows cloud et hérités.

Des outils de sécurité qui fonctionnent parfaitement dans un environnement peuvent s'avérer pratiquement impossibles à déployer dans un autre. Troisièmement, les capacités de mise en œuvre centralisée sont limitées et il n'existe aucun système unique capable de couvrir l'ensemble de la surface cloud des applications et cloud d'une organisation. 

Même si, d'un point de vue technique, le RSSI relève du directeur informatique ou du directeur technique, les équipes de sécurité ont rarement la main sur les priorités du carnet de commandes des équipes d'ingénierie produit. Elles peuvent les influencer, mais n'en ont pas la maîtrise. Cela crée une tension fondamentale.

Et les problèmes de sécurité les plus dangereux sont souvent ceux qui nécessitent des modifications architecturales, la mise à jour des dépendances ou une refonte majeure. C'est le genre de tâches que les ingénieurs évitent instinctivement, car elles ne s'inscrivent pas facilement dans le cadre d'un sprint de deux semaines.

Les tâches dont l'estimation dépasse environ 13 points de story sont souvent reportées sine die. Il s'agit de projets déguisés en tickets. Il en résulte un arriéré croissant de tâches liées à la sécurité que tout le monde comprend d'un point de vue théorique, mais que personne ne se sent habilité ou motivé à traiter en priorité.

‍

L'objectif premier est l'appropriation, et non la couverture

L'une des erreurs les plus courantes commises par les responsables de la sécurité est de croire que la couverture des outils est synonyme de progrès. L'exécution de scanners sur chaque référentiel peut générer des tableaux de bord impressionnants, mais sans appropriation, ces tableaux de bord ne sont guère plus que des répertoires de risques. Le véritable progrès commence par une autre question :

Qui est chargé de réparer quoi ?

Les programmes de sécurité évolutifs commencent par identifier les personnes influentes au sein de l'équipe d'ingénierie. Pas les responsables hiérarchiques. Pas les architectes figurant sur l'organigramme. Mais les développeurs dont les opinions façonnent réellement les pratiques d'ingénierie. Toute grande équipe d'ingénierie en compte. Ce sont ces ingénieurs et développeurs, véritables vecteurs de la culture d'entreprise, que les autres consultent avant de prendre des décisions architecturales. Une approche étonnamment efficace consiste à adopter un modèle de formation des formateurs :

1. Identifiez 10 développeurs chevronnés reconnus dans toute l'entreprise
2. Leur dispenser une formation approfondie aux pratiques de développement sécurisé
3. Demandez-leur de former 100 champions de l'ingénierie
4. Ces champions encadrent chacun leur propre équipe de 50 développeurs

En l'espace de quelques semaines, les pratiques de sécurité se diffusent auprès de milliers d'ingénieurs sans que l'équipe de sécurité ait à former chacun d'entre eux directement. À grande échelle, l'influence se propage grâce à la crédibilité des pairs.

Comment les RSSI choisissent leurs équipes pilotes (et pourquoi la plupart des projets pilotes sont trompeurs)

La plupart des programmes de sécurité d'entreprise commencent par un projet pilote. En théorie, cela semble judicieux. Mais la manière dont ces projets pilotes sont choisis conduit souvent à des résultats trompeurs.

Les responsables de la sécurité choisissent souvent l'un des deux types d'équipes suivants :

1. L'équipe d'ingénieurs la plus expérimentée
2. L'équipe la plus impatiente de participer

Ces deux approches aboutissent à des résultats artificiellement positifs. Les équipes hautement performantes veillent déjà à une excellente « hygiène technique ». Leurs dépendances sont à jour. Leurs pipelines CI/CD sont modernes. Leur architecture fait l'objet d'une maintenance active. Le déploiement d'outils de sécurité dans ce contexte génère des indicateurs impressionnants, mais crée aussi l'illusion dangereuse que les déploiements s'effectueront sans heurts. La réalité se révèle plus tard, lorsque le déploiement touche des services hérités, des équipes en sous-effectif ou des systèmes qui n'ont pas fait l'objet de mises à jour significatives depuis des années.

Une meilleure approche de sélection des projets pilotes intègre délibérément une complexité représentative :

• Un service historique
• Une équipe moderne cloud
• Une gamme de produits à rotation rapide
• Une plateforme interne peu réactive

L'objectif d'un projet pilote est d'identifier rapidement les obstacles.

Le modèle de déploiement en quatre phases qui fonctionne à grande échelle

Les programmes de sécurité destinés aux développeurs qui font leurs preuves suivent généralement un schéma de mise en œuvre cohérent. Cela se produit rarement de manière intentionnelle, mais les RSSI expérimentés finissent par s'accorder sur le même modèle.

Phase 1 : Visibilité sans mesures coercitives

La première phase est axée sur l'observabilité. Les outils de sécurité fonctionnent sur l'ensemble des référentiels et de l'infrastructure, mais ils ne bloquent ni les compilations ni les déploiements. Les résultats sont mis en évidence, classés par catégorie et analysés. Cette étape aide les équipes de sécurité à répondre à des questions essentielles :

• Quelles sont les vulnérabilités les plus fréquentes ?
• Quelles équipes réagissent rapidement ?
• Quels types de corrections posent le plus de problèmes ?

Considérez cela comme un exercice d'apprentissage.

‍

Phase 2 : Boucles de rétroaction avec les développeurs

Vient ensuite l'implication des développeurs. Les résultats sont présentés de manière à ce que les ingénieurs puissent réellement s'en servir pour agir. Les faux positifs sont systématiquement éliminés. La documentation s'améliore. Des exemples de corrections sont partagés. Cette phase favorise également la motivation intrinsèque. Les développeurs réagissent rarement bien à une imposition descendante. En revanche, ils sont réceptifs aux défis liés à la résolution de problèmes. Certaines organisations gamifient avec succès le travail de correction, permettant aux équipes de rivaliser en fonction du nombre de problèmes de sécurité résolus par sprint. Lorsque les ingénieurs commencent à corriger les problèmes de leur propre initiative, vous savez que le programme commence à porter ses fruits.

{{faux positifs}}

Phase 3 : Lignes directrices et politique

Ce n'est qu'une fois que les développeurs ont confiance dans le système que des mécanismes de contrôle apparaissent. Ceux-ci prennent généralement la forme de garde-fous. En voici quelques exemples :

• Correction des failles de sécurité critiques dans les nouvelles dépendances
• Empêcher l'introduction de secrets dans les référentiels
• Imposer des niveaux de correctifs minimaux pour les images de base

L'accent continue d'être mis sur la prévention des nouveaux risques plutôt que sur la sanction des failles passées. Le « pourquoi » doit aller de pair avec le « quoi », afin que nous ne nous contentions pas de jouer à une version perfectionnée ou accélérée du jeu du « tape-taupe » avec les vulnérabilités et les erreurs de configuration.

‍

Phase 4 : Responsabilité des dirigeants

La phase finale met l'accent sur la visibilité du leadership. Des indicateurs apparaissent dans les tableaux de bord destinés aux responsables techniques :

• Délai de correction
• Catégories de vulnérabilités récurrentes
• Évolution du carnet de commandes dans le secteur de la sécurité

À ce stade, la sécurité s'intègre aux discussions sur les performances techniques. C'est alors que le changement de culture devient tangible et durable.

Ce qu'il ne faut pas imposer trop tôt (et pourquoi)

La manière la plus sûre de faire échouer la mise en place d'une politique de sécurité est de l'appliquer trop tôt. Parmi les erreurs courantes commises au début, on peut citer :

• Le blocage s'appuie sur des seuils de vulnérabilité
• Rendre obligatoires les délais de mise à jour pour tous
• Application des politiques de niveau de gravité à l'échelle mondiale

Ces mesures semblent décisives, mais elles provoquent souvent un effet de rebond. Lorsque les ingénieurs voient soudainement leurs déploiements bloqués par des outils qu’ils n’ont pas demandés, ils trouvent rapidement des solutions de contournement. Ils désactivent les scanners et créent des branches parallèles dans les pipelines. Ils ignorent les alertes. Il en résulte une baisse du niveau de sécurité et une détérioration des relations entre les équipes d’ingénierie et de sécurité. L’adhésion doit précéder l’imposition. La confiance doit passer avant le contrôle.

Les indicateurs qui témoignent d'une adoption réelle

tableaux de bord de sécurité se concentrent tableaux de bord de sécurité sur les mauvais indicateurs. Le nombre de vulnérabilités, d'analyses effectuées ou de référentiels analysés offre certes une certaine visibilité, mais ne dit pas grand-chose sur les changements de comportement.

Parmi les indicateurs les plus pertinents, on peut citer :

• Taux de correction: les développeurs corrigent-ils réellement les problèmes identifiés ? Une hausse du taux de correction indique généralement un engagement accru.
• Délai de correction: en combien de temps les problèmes très graves sont-ils résolus ? Dans les entreprises où règne une solide culture de la sécurité chez les développeurs, les correctifs critiques sont souvent mis en place en quelques jours, et non en plusieurs semaines.
• Constatations récurrentes: les mêmes vulnérabilités apparaissent-elles régulièrement ? Si tel est le cas, le problème ne réside pas dans la correction des failles, mais dans la formation des développeurs ou dans les modèles architecturaux.
• Signaux de désengagement: les premiers signes avant-coureurs d'un échec, et les plus importants, sont le fait que les développeurs négligent le système, clôturent les tickets sans apporter de corrections ni fournir de liens vers les modifications apportées au code, se plaignent d'une « fatigue des alertes » et réduisent soudainement leurs efforts de correction.

‍

Lorsqu'un déploiement de programme de sécurité échoue

Même les déploiements les mieux conçus peuvent rencontrer des difficultés. Les responsables de la sécurité expérimentés savent repérer les signes avant-coureurs dès le début :

• Le retard s'accumule plus vite que les solutions
• Des ingénieurs contournent les outils de scan
• Les champions de la sécurité perdent de leur influence

Dans ce genre de situation, on a souvent tendance à vouloir durcir les mesures de contrôle, mais c'est presque toujours une mauvaise décision. Au contraire, les RSSI qui réussissent prennent le temps de réfléchir et se posent trois questions :

1. Est-ce qu'on soulève trop de questions à la fois ?
2. Les développeurs reçoivent-ils des instructions claires sur les mesures correctives à prendre ?
3. Accordons-nous la priorité aux vulnérabilités qui comptent vraiment ?

Cette dernière question nous amène à l'un des principes fondamentaux des programmes de sécurité à grande échelle :

Le principe de Pareto s'applique ici : . Dans la plupart des environnements, environ 20 % des vulnérabilités représentent 80 % du risque réel pour l'organisation. Les programmes de sécurité qui se concentrent sur ces problèmes à fort impact réduisent considérablement le risque tout en minimisant les obstacles pour les développeurs. Les programmes qui tentent de tout corriger simultanément s'effondrent sous leur propre poids.

Intégrer la sécurité dès le début du cycle de développement logiciel (SDLC)

Un programme de sécurité à long terme destiné aux développeurs s'inscrit en amont du processus. Plutôt que de réagir aux rapports de vulnérabilité, les entreprises commencent à les prévenir dès la phase de conception et de développement.

L'un des outils les plus efficaces pour mener à bien cette transformation est la modélisation des menaces. De nombreux développeurs ne se préoccupent de la sécurité que lorsqu'un scanner signale un problème. Ils apprennent la règle, mais pas le raisonnement qui la sous-tend. La modélisation des menaces change la donne.

Cela aide les développeurs à comprendre :

• Pourquoi les choix en matière de stockage de session sont importants
• Comment les modèles d'authentification créent des surfaces d'attaque
• Pourquoi Top 10 OWASP reviennent sans cesse

Lorsque les ingénieurs comprennent le « pourquoi », ils cessent de considérer les correctifs de sécurité comme des exigences imposées de l'extérieur et commencent à concevoir des systèmes qui évitent complètement ces problèmes. Le fait de jumeler des développeurs débutants avec des ingénieurs expérimentés accélère encore davantage cet apprentissage. Les développeurs chevronnés transmettent naturellement des habitudes telles que la rigueur en matière de documentation, les tests automatisés et la configuration sécurisée des infrastructures. La sécurité ne consiste plus tant à analyser le code qu'à adopter une certaine façon de penser lors de son écriture.

La seule règle qui détermine le succès à grande échelle

Après avoir observé la réussite ou l'échec de dizaines de programmes de sécurité destinés aux développeurs, un principe revient systématiquement pour déterminer l'issue : la sécurité doit alléger la charge cognitive des développeurs, et non l'alourdir.

Si les outils génèrent un bruit de fond insupportable, les ingénieurs se désengagent. Si les consignes de correction ne sont pas claires, les ingénieurs reportent les corrections. Si les mesures coercitives sont mises en place avant que la confiance ne soit établie, les ingénieurs contournent les contrôles. Mais lorsque les outils de sécurité :

• conclusions exploitables
• donner la priorité aux risques significatifs
• s'intégrer aux processus existants

Les développeurs réagissent comme à leur habitude et règlent le problème.

Et quand un nombre suffisant d'entre eux commence à y trouver une solution, il se passe quelque chose d'extraordinaire. La sécurité devient une habitude.

Et dans une organisation comptant 5 000 contributeurs, ce sont les habitudes qui, en fin de compte, déterminent le niveau de sécurité de l'ensemble de l'entreprise.

‍

Ces enseignements ont fortement influencé la philosophie de conception qui sous-tend les plateformes modernes de sécurité pour développeurs telles que Aikido. Un système conçu pour mettre en évidence les risques significatifs tout en minimisant la charge cognitive pesant sur les développeurs.

{{walkthrough}}