Le DevSecOps est apparu comme une réponse à ce dilemme. Sa promesse consiste littéralement à insérer les principes, pratiques et outils de sécurité dans le flux de travail DevOps, ainsi les risques sans compromettre la productivité.
Dès lors, une question se pose : pourquoi le DevSecOps n’est-il pas déjà la norme ? Dans le dernier rapport DevSecOps : Protecting the Modern Software Factory, la réponse peut être résumée comme suit : ce n’est qu’en activant de nouvelles capacités au sein des équipes Dev, Sec et Ops que la culture peut être changée.
Des exigences aux attentes
Le passage à l’échelle de la sécurité des applications est un projet d’entreprise qui nécessite une réflexion approfondie avant toute prise de décision. Une première exigence est de s’entretenir avec les équipes produits et ingénierie pour comprendre la maturité actuelle de la sécurité des applications.
L’objectif à ce stade est de s’assurer d’avoir une compréhension complète de la façon dont les produits sont fabriqués (les processus, outils, composants et piles impliqués). La cartographie des outils et des pratiques de développement nécessitera du temps pour avoir la meilleure visibilité possible.
Ils devraient inclure les pratiques de développement de produits et la sensibilisation/appétence au risque perçu par les managers. L’un des objectifs serait d’inciter à prendre en compte la sécurité dans chaque prise de décision pour les produits, et peut-être de finir par penser comme des attaquants.
Il est possible de dériver des exigences de sécurité à partir des différents risques perceptuels rencontrés. Le travail consiste à les réaliser en un ensemble commun pour toutes les applications, en fixant des objectifs pour aligner les différentes équipes qui collaborent à la construction des produits.
Il est essentiel de communiquer de manière transparente avec toutes les parties concernées (RSSI, sécurité technique, propriétaire du produit et responsables du développement) sur les objectifs et les attentes afin de créer un terrain d’entente pour l’amélioration. Elle sera également absolument nécessaire pour garantir l’alignement tout au long de la mise en œuvre.
Règles de sécurité ouvertes et accessibles
Les règles sont la pierre angulaire des exigences de sécurité. Leur nature et leur mise en œuvre dépendent entièrement des besoins de votre organisation et peuvent être potentiellement très différentes d’une entreprise à l’autre (si vous partez de zéro, ne cherchez pas plus loin que le Top10 de l’OWASP).
Le plus important, cependant, est que ces règles soient ouvertes à ceux qui en ont besoin. Un bon exemple serait de centraliser une bibliothèque commune de composants open-source, approuvée par la sécurité, dans laquelle n’importe quelle équipe pourrait puiser.
Il faut faire de l’accessibilité et de l’utilisabilité pour les utilisateurs une priorité. Pour concevoir un programme AppSec à grande échelle, il faut se demander « comment renforcer la confiance et la visibilité avec des outils fiables dans notre écosystème ». Par exemple, les contrôles ne devraient jamais être mis en œuvre sans envisager une option de court-circuit (« que se passe-t-il si le contrôle est bloquant dans une situation d’urgence ? »).
L’état de l’art en matière de sécurité consiste à disposer de solutions sécurisées prêtes à l’emploi, choisies par les développeurs, approuvées par la sécurité et maintenues par les opérations.
Ce sera un grand pas en avant pour empêcher les vulnérabilités de se glisser dans le code source. Elle mettra la sécurité à la portée du plus grand nombre à un très faible coût (faible frottement). Mais pour étendre la sécurité des applications, il serait stupide de ne pas utiliser le meilleur allié de l’ingénieur : le pipeline d’intégration continue.
Intégrer les contrôles dans le CI/CD
L’étape de mise en œuvre consiste à intégrer les contrôles de sécurité des applications dans tous les pipelines de développement. Si une organisation compte plusieurs équipes de développement, il est très probable que différentes configurations de pipelines CI/CD existent en parallèle. Elles peuvent utiliser différents outils, ou simplement définir différentes étapes dans le processus de build. Ce n’est pas un problème en soi, mais pour faire évaluer la sécurité des applications, une centralisation et une harmonisation sont nécessaires.
Comme l’illustre l’exemple suivant de pipeline CI/CD, il existe de nombreuses étapes de contrôle de sécurité : détection des secrets, SAST, signature des artefacts, contrôles d’accès, mais aussi analyse des conteneurs ou de l’infrastructure as code (non représenté dans l’exemple).
L’idée est que l’on peut activer progressivement de plus en plus d’étapes de contrôle, affiner les étapes existantes et faire actualiser horizontalement et verticalement l’infrastructure AppSec », à une condition : il faut centraliser les mesures et les contrôles dans une plateforme autonome capable de gérer la charge correspondante à la taille de l’organisation.
Le processus de sécurité ne peut être automatisé qu’il existe des mesures et une visibilité adéquate sur l’ensemble des périmètres de développement, faute de quoi l’équipe AppSec n’aura qu’une charge supplémentaire à supporter.
À leur tour, les mesures et la visibilité contribuent au changement et permettent l’étincelle pour favoriser un changement culturel au sein de votre organisation. La responsabilité de la sécurité est perçue à chaque ingénieur impliqué dans le processus de livraison, et chacun est en mesure de tirer partie de sa propre connaissance approfondie (mais partielle) du système pour soutenir l’effort.
Cela ouvre un monde de possibilités : la plupart des failles de sécurité peuvent être traitées comme des tickets ordinaires, les ensembles de règles peuvent être optimisés pour chaque pipeline en fonction de la criticité, des capacités ou de la conformité réglementaire, et les progrès peuvent être suivis (temps gagnés, vulnérabilités supprimées, etc.). En termes plus simples, la sécurité peut enfin être évaluée à la vitesse du DevOps.
La sécurité ne peut pas évaluer si elle est cloisonnée, et ralentir le processus de développement n’est plus une option dans un monde dirigé par l’innovation DevOps. La conception et la mise en œuvre des contrôles de sécurité sont appelées à évaluées. Dans cet article, nous avons décrit un aperçu du haut niveau des étapes à envisager pour faire évaluer la sécurité applicative.
Cela commence par l’établissement d’un ensemble d’exigences de sécurité qui impliquent tous les départements, en particulier ceux liés aux produits. À partir de là, il devient possible de définir des règles pour rendre la sécurité réellement accessible avec un mélange de contrôles plus ou moins contraignants. En considérant avec soin la détection et la remédiation automatisées qui permettent la visibilité et le contrôle, vous jetez les bases solides d’un véritable modèle de responsabilité partagée en matière de sécurité.
Enfin, l’intégration de contrôles dans le système CI/CD peut être déployée en plusieurs phases afin de faire progresser progressivement les opérations de sécurité. Une fois le feedback automatisé en place, vous pouvez commencer à ajuster progressivement vos politiques. Une plateforme centralisée crée une interface commune pour faciliter les échanges entre les équipes de sécurité applicative et les équipes de développeurs tout en appliquant les processus. C’est une énorme opportunité d’automatiser et de propager les meilleures pratiques à travers les équipes.
Les développeurs sont équipés pour développer plus rapidement avec une plus grande prise de responsabilité.
Lorsque la sécurité est repensée comme un partenariat entre les parties impliquées à la création de logiciels, un effet accélérateur peut se produire : la réduction des frictions entraîne une meilleure communication et une plus grande visibilité, l’automatisation d’un plus grand nombre de meilleures pratiques, la facilitation du travail de chacun tout en améliorant la sécurité avec moins de défauts.
C’est ainsi que la sécurité applicative pourra enfin s’améliorer grâce à l’amélioration continue.
