Le cycle de vie sécurisé
Le SSDLC : la sécurité à chaque étape du développement.
Pendant longtemps, la sécurité fut la dernière étape du développement : on construisait, puis on faisait tester par une équipe extérieure, juste avant la mise en production. Ce qu'elle trouvait arrivait trop tard. Une faille de conception découverte à ce moment ne se corrige pas par une rustine : il faut revenir au tableau blanc, refaire, retester. Le cycle de vie sécurisé --- Secure Software Development Lifecycle --- part d'un constat simple : il coûte moins cher de ne pas introduire un défaut que de le retirer.
En bref
Le SSDLC ne consiste pas à ajouter une étape de sécurité, mais à en placer une activité dans chaque étape existante. Ce n'est pas un outil, c'est une répartition.
Une activité par phase, et pas une de plus
L'erreur d'interprétation la plus fréquente consiste à croire que sécuriser le cycle revient à tout faire partout. C'est le contraire : à chaque phase correspond une activité, et une seule, parce que c'est à ce moment-là qu'elle coûte le moins et rapporte le plus.
Quatre phases, quatre activités, et un ordre de grandeur qui justifie tout le reste --- avec la prudence qui s'impose sur les chiffres exacts, voir l'encadré ci-dessous.
Un chiffre que tout le monde cite, et que personne n'a vérifié
Vous rencontrerez partout la même série : corriger un défaut coûterait six fois plus à l'implémentation qu'à la conception, quinze fois aux tests, cent fois en exploitation, le tout attribué à un « Systems Sciences Institute d'IBM ».
Cette étude n'a jamais été retrouvée. La piste remonte à une note de bas de page du manuel de Roger Pressman, qui renvoie à des supports de formation internes à IBM datés de 1981 aucun jeu de données n'a jamais été publié. Laurent Bossavit en a fait l'un des cas les mieux documentés de The Leprechauns of Software Engineering.
Ce qui existe, en revanche, est une publication à comité de lecture : Boehm et Basili, Software Defect Reduction Top 10 List, IEEE Computer, janvier 2001. Elle soutient bien un rapport de l'ordre de 100 pour 1 entre une correction après livraison et une correction en phase d'exigences --- mais assortie d'une réserve que presque personne ne reprend : sur les projets petits et non critiques, le rapport tombe à environ 5 pour 1.
Retenez donc la direction, qui est solide, et méfiez-vous du chiffre précis. C'est aussi, en soi, une leçon de méthode pour un module qui parle de confiance : une donnée répétée mille fois ne devient pas vraie pour autant.
Ce que chaque phase apporte
À la planification, l'évaluation du risque. Avant d'écrire une ligne, on décide ce qu'on accepte de perdre. C'est là qu'on établit qu'un service de paiement et un outil de rétrospective d'équipe ne méritent pas le même effort. Le chapitre détaille comment on s'y prend.
À la conception, le threat modeling. Une fois l'architecture posée mais avant le code, on cherche ce qui ne doit pas arriver. C'est le moment le moins cher pour découvrir qu'un composant fait confiance à un autre sans raison. Le chapitre en donne la méthode.
Au développement, la revue et l'analyse. Relecture humaine et outils automatiques, pendant que le code s'écrit --- pas trois mois après. Le chapitre distingue ce que chaque famille d'outils sait voir.
À l'exploitation, l'évaluation de sécurité. Test d'intrusion et recherche de vulnérabilités, sur un système qui tourne. Ils trouvent ce que les trois phases précédentes ont laissé passer --- et si elles ont bien travaillé, ils trouvent peu.
La différence entre un scan et un pentest
Une recherche de vulnérabilités signale : elle compare un système à une base de failles connues et produit une liste. Un test d'intrusion démontre : il tente l'exploitation et prouve qu'un chemin existe réellement. Le premier répond « voici ce qui pourrait poser problème », le second « voici ce que j'ai obtenu ». Confondre les deux conduit à surestimer la valeur d'un rapport automatique.
Trois cadres, trois questions différentes
Il existe plusieurs cadres pour organiser tout cela. Ils ne se concurrencent pas : ils ne répondent pas à la même question, et c'est ce qui doit guider le choix.
| Cadre | Question à laquelle il répond | Ce qu'il vous donne |
|---|---|---|
| Microsoft SDL | Que dois-je faire ? | une liste d'activités obligatoires, rangées par phase : former, définir les exigences, modéliser les menaces, fixer des standards de cryptographie, tenir l'inventaire des composants tiers, tester, préparer la réponse à incident |
| OWASP SAMM | Où en suis-je, et où veux-je aller ? | un modèle de maturité : on s'évalue par domaine, on constate l'écart, on se fixe un palier suivant |
| BSIMM | Que font réellement les autres ? | une observation de centaines d'organisations. Descriptif, pas prescriptif : il ne dit pas quoi faire, il dit ce qui se fait |
SDL prescrit, SAMM mesure, BSIMM compare. Une organisation qui débute gagne à commencer par SAMM : on ne peut pas améliorer ce qu'on n'a pas mesuré.
Un niveau de maturité n'est pas un niveau de sécurité
C'est le piège de ces modèles, et il est constant. Ils mesurent des activités --- « faites-vous du threat modeling ? », « avez-vous un standard de revue ? » --- et non des résultats. Une organisation peut cocher toutes les cases et rester vulnérable, parce que les activités sont menées pour la case et non pour ce qu'elles trouvent. À l'inverse, une petite équipe sans aucun modèle formel peut produire du logiciel très sûr.
Le modèle sert à repérer ce qui manque, pas à se noter. Le jour où le score devient un objectif, il cesse d'être une mesure --- c'est la loi de Goodhart, et on la retrouvera au chapitre appliquée aux pipelines.
L'introduire dans une organisation
Poser un cadre sur une équipe qui n'en a jamais eu échoue à peu près toujours. La séquence qui fonctionne tient en quatre temps, et elle est délibérément lente.
Quatre temps, dans cet ordre
- Mesurer l'existant. Une analyse d'écart : quelles politiques existent, et sont-elles suivies ? Une politique sans procédure qui l'applique n'existe que sur le papier.
- Fixer des objectifs atteignables, avec une mesure de succès. « Améliorer la sécurité » n'en est pas un « toute dépendance nouvelle passe par une revue » en est un.
- Formaliser après une période d'essai. On laisse les équipes s'approprier la pratique et remonter ce qui ne marche pas, puis on l'impose. L'ordre inverse produit du contournement.
- Former avant d'outiller. Un outil déployé auprès de gens qui n'en comprennent pas la sortie produit du bruit, puis de l'indifférence au bruit --- ce qui est pire que rien.
Ce dernier point mérite qu'on s'y arrête, parce qu'il explique la plupart des échecs observés en entreprise. Un scanner branché sur une chaîne sans préparation produit des centaines d'alertes dès le premier jour. L'équipe n'a ni le temps de les traiter ni les moyens de distinguer les vraies des fausses. En trois semaines, tout le monde a appris à ignorer la couleur rouge --- et cette habitude, une fois prise, coûte bien plus cher à défaire qu'à éviter. Le chapitre y revient sous l'angle de la politique graduée,.
À retenir
Le cycle de vie sécurisé se juge à une chose : est-ce que quelqu'un agit différemment à cause de lui ? Si les activités sont menées et que rien ne change dans les décisions, le cadre est décoratif.
Réponse unique
À quoi reconnaît-on qu'un SSDLC est purement décoratif ?
Indice · Un cadre existe pour changer quelque chose. Quoi, exactement ?
[ METTRE EN PRATIQUE ]
Associer une activité à chaque phase
3 étapes · 30 min · 110 XP
[ CETTE LEÇON DANS LES PARCOURS ]