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.
La sécurité est un dilemme pour de nombreux dirigeants. D’une part, elle est largement reconnue comme une caractéristique essentielle. D’autre part, elle n’est pas au cœur de l’activité. Bien sûr, à mesure que l’entreprise grandit, la sécurité peut devenir un catalyseur d’activité. Mais la feuille de route n’est pas toujours claire. Avec l’essor des pratiques agiles, du DevOps et du cloud, les délais de développement ont été considérablement réduits, mais la sécurité des applications reste essentiellement la même.
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, réduisant 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çue par les managers. L’un des objectifs serait d’inciter à prendre en compte la sécurité dans chaque décision prise 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 consolider 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 prenantes concernées (RSSI, sécurité technique, product owner 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é ouverts 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 coût très faible (faible friction). Mais pour véritablement étendre la sécurité des applications, il serait stupide de ne pas utiliser le meilleur allié de l’ingénieur logiciel : 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 évoluer 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ée 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 évoluer 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 correspondant à la taille de l’organisation.
Les processus de sécurité ne peuvent être automatisés que s’ 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 fournissent l’étincelle pour déclencher un changement culturel au sein de votre organisation. La responsabilité de la sécurité est transférée à chaque ingénieur impliqué dans le processus de livraison, et chacun est en mesure de tirer parti 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é, vulnérabilités évitées, etc.). En termes plus simples, la sécurité peut enfin évoluer à la vitesse du DevOps.
La sécurité ne peut pas évoluer 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 à évoluer. Dans cet article, nous avons décrit un aperçu de haut niveau des étapes à envisager pour faire évoluer 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 concevoir des règles pour rendre la sécurité réellement accessible avec un mélange de contrôles plus ou moins contraignants. En choisissant avec soin la détection et la remédiation automatisées qui offrent visibilité et contrôle, vous jetterez 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 évoluer 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 opportunité énorme 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 prenantes à 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 évoluer grâce à l’amélioration continue.
