Aller au contenu principal

Le problème que le DevSecOps résout

Résumé : dans le modèle classique, la sécurité intervient à la fin, sous forme d'audit, quelques jours avant la mise en production. Ce modèle échoue pour des raisons structurelles, pas par manque de compétence. Cette leçon détaille ces raisons, chiffre le coût exponentiel d'une correction tardive, et explique le vrai prix d'une fuite de données.

1. Le scénario classique​

Le point crucial de ce scénario, celui qu'il faut vraiment saisir : personne n'a mal travaillé. Les développeurs ont livré ce qu'on leur demandait. L'auditeur a fait un travail correct. La direction a pris une décision rationnelle compte tenu des contraintes.

C'est le processus qui est défaillant, pas les personnes. Placer la sécurité après le développement garantit mathématiquement que ses conclusions arriveront trop tard pour être appliquées.

2. Le coût exponentiel de la correction tardive​

Les ordres de grandeur communément cités : une vulnérabilité corrigée à la conception coûte 1. Corrigée en développement, environ 5. En recette, environ 15. En production, 30 à 100. Après exploitation, l'échelle change complètement de nature.

La conclusion pratique : chaque jour gagné dans la détection réduit le coût de façon non linéaire. C'est tout le fondement économique du shift left, et c'est l'argument à présenter à une direction.

3. Les six problèmes structurels du modèle classique​

Le problème 5 est le plus sous-estimé, et de loin. Votre code peut ne pas changer pendant deux ans, mais votre exposition change tous les jours, parce que de nouvelles vulnérabilités sont publiées en permanence sur les bibliothèques que vous utilisez. Un audit annuel est une photographie ; ce dont vous avez besoin, c'est d'une surveillance continue.

Le problème 6 explique pourquoi le DevSecOps est né maintenant et pas il y a vingt ans. Quand on livrait deux fois par an, un audit de trois semaines était absorbable. Avec vingt déploiements par jour, il devient mathématiquement impossible. C'est le CI/CD qui a rendu le DevSecOps nécessaire.

4. Le vrai coût d'une fuite de données​

Le coût 5 est celui qui frappe le plus longtemps dans le monde professionnel. Dès que vous vendez à des entreprises, chaque appel d'offres comporte un questionnaire de sécurité avec la question « avez-vous subi un incident de sécurité au cours des trois dernières années ? ». Une réponse positive vous élimine de certains marchés, indépendamment de la qualité de votre produit.

Ordre de grandeur souvent cité : le coût moyen mondial d'une fuite de données se situe autour de 4 à 5 millions de dollars selon les études annuelles du secteur — avec des écarts considérables selon la taille de l'organisation et le secteur, la santé et la finance étant les plus coûteux.

5. Pourquoi c'est plus difficile qu'avant​

Le point 1 est celui qui change tout, et il est régulièrement ignoré. Vous pouvez écrire un code parfaitement propre et rester massivement vulnérable, parce que 80 % de ce qui s'exécute vient de bibliothèques que vous n'avez jamais examinées. C'est précisément pourquoi l'analyse des dépendances (le SCA) apporte souvent plus de valeur immédiate que l'analyse de votre propre code.

C'est aussi ce qui explique Log4Shell : une seule bibliothèque de journalisation, utilisée par des millions d'applications, et une faille critique. Le sujet est traité en leçon 7.

6. Ce que le DevSecOps change​

Le point 4 est le plus puissant, et le moins pratiqué. Il y a une différence énorme entre « signaler qu'un stockage est public » et « rendre techniquement impossible de créer un stockage public ». La première approche produit un rapport que quelqu'un devra lire ; la seconde élimine la classe entière de problèmes.

C'est le principe du garde-fou (guardrail) plutôt que du gendarme (gatekeeper) : au lieu de contrôler après coup, on rend l'erreur impossible.

7. Les résistances habituelles, et comment y répondre​

L'objection 3 mérite d'être démontée soigneusement, car elle est la plus répandue. La grande majorité des attaques ne visent personne en particulier : des robots parcourent l'internet en continu à la recherche de versions vulnérables connues, et exploitent tout ce qu'ils trouvent. Une petite application inconnue avec une faille publique sera trouvée, souvent en quelques heures après sa mise en ligne.

Retenir en 30 secondes​

  • La sécurité en fin de chaîne échoue structurellement : ses conclusions arrivent trop tard pour être appliquées.
  • Le coût de correction est exponentiel : environ 1 à la conception, 5 en développement, 15 en recette, 30 à 100 en production.
  • Six problèmes structurels : information tardive, goulot d'étranglement, sécurité adversaire, aucun apprentissage, dépendances non suivies, incompatible avec la livraison continue.
  • Une fuite de données coûte bien au-delà de la technique : réglementaire (jusqu'à 4 % du chiffre d'affaires sous RGPD), réputation, et surtout affaires perdues via les questionnaires de sécurité.
  • Plus de 80 % du code exécuté vient de dépendances que vous n'avez jamais lues. C'est le changement majeur.
  • C'est le CI/CD qui a rendu le DevSecOps nécessaire — un audit de trois semaines est impossible avec vingt déploiements par jour.
  • Préférez le garde-fou au gendarme : rendre l'erreur impossible plutôt que la signaler après coup.
  • « Personne ne s'intéresse à nous » est faux : les attaques sont automatisées et non ciblées.
  • Action la plus rentable : activer la détection de dépendances vulnérables. Quinze minutes.

Suivant : Qu'est-ce que le DevSecOps ? Shift left et définitions →