Le DevOps a transformé le fonctionnement des entreprises. Les sociétés lancent plus rapidement sur le marché des produits innovants et réalisent au passage des économies plus importantes. Cependant, face à la recrudescence des cyberattaques, les organisations ne peuvent pas se permettre de négliger l’aspect sécurité du modèle DevOps. La violation de données d’Equifax en 2017 est l’un des nombreux exemples qui montrent à quel point il est nécessaire d’introduire des contrôles de sécurité dans le processus de production. Une vulnérabilité non corrigée a coûté à l’entreprise la somme vertigineuse de 700 millions de dollars US dans le cadre d’un règlement lié à une violation de données aux États-Unis.
Une enquête de l’IDC a révélé que plus d’un tiers des entreprises dans le monde avaient subi une violation au cours des 12 derniers mois. Selon un autre rapport, 71 % des RSSI estiment que leur code n’est pas exempt de vulnérabilités avant sa mise en production. Ces chiffres sont préoccupants.
Les équipes doivent adopter le DevSecOps pour disposer d’une infrastructure sécurisée sans compromettre la vitesse ni la productivité. Dans l’univers des workflows DevOps, où les itérations sont rapides, la sécurité ne peut plus être une considération secondaire : elle doit progresser de pair avec le développement des applications. En fait, plus tôt la sécurité est introduite dans le SDLC, mieux c’est pour la santé globale de l’organisation.
« Le DevSecOps ne consiste pas à assurer la sécurité périmétrique des applications et des données, mais à intégrer une sécurité de bout en bout dans vos applications », explique le conseiller cloud Kevin Davis de CloudReach. « Cette approche exploite la chaîne logistique des logiciels et des systèmes afin d’identifier rapidement les vulnérabilités de sécurité, de réduire le risque d’un impact négatif sur les clients et de limiter la possibilité de cyberattaques et d’interruptions de service. Globalement, avec le DevSecOps, les entreprises peuvent fusionner efficacement la collaboration et la communication entre les équipes de développement, d’exploitation et de sécurité. Tout le monde y gagne. »
Qu’est-ce que le DevSecOps ?
Le DevSecOps est une méthodologie logicielle qui intègre la sécurité au cycle DevOps existant. Il bouleverse le SDLC traditionnel en introduisant des protocoles de sécurité à chaque étape du processus SDLC. Ainsi, les équipes traitent les menaces de sécurité lorsqu’elles apparaissent, au lieu d’y répondre plus tard dans le cycle de développement.
Auparavant, les mises à jour logicielles étaient rares et espacées. Le DevOps a ramené la durée du SDLC à quelques jours. Dans ce contexte, faire tester le code en production par une équipe de sécurité entraîne des délais inutiles et va à l’encontre même du concept de DevOps rapide et agile. Un produit sécurisé et une mise en production rapide ne sont possibles qu’avec un SDLC entièrement automatisé. La mise en œuvre du DevSecOps permet aux entreprises d’innover en toute sécurité tout en restant agiles.
À lire aussi : NetOps contre DevOps : l’automatisation au service du réseau
Éléments clés de la mise en œuvre du DevSecOps
Sean Wright, expert principal en sécurité des applications chez Immersive Labs déclare : « Il faut réellement s’engager en faveur du DevSecOps. Cela signifie intégrer la sécurité à toutes les étapes du cycle de vie, disposer des outils appropriés au bon moment et, surtout, donner à vos collaborateurs les connaissances et compétences nécessaires pour utiliser ces outils, prévenir les problèmes de sécurité et y remédier. Cela permet à chacun de jouer un rôle dans la sécurité d’une application ou d’un service. »
Voici quelques bonnes pratiques à garder à l’esprit lors de la mise en œuvre du DevSecOps dans votre organisation.
Analyse des vulnérabilités
Les cybercriminels peuvent exploiter les vulnérabilités de votre code ; il est donc essentiel, pour le DevSecOps, de les détecter à chaque étape du pipeline CD. Mais compte tenu des délais très courts nécessaires à des déploiements plus rapides, examiner manuellement les vulnérabilités est quasiment impossible.
Les scanners automatisés de vulnérabilités renforcent votre niveau de sécurité et empêchent les acteurs de la menace d’exploiter les vulnérabilités de votre système. Les tests statiques de sécurité des applications (SAST) et les tests dynamiques de sécurité des applications (DAST) sont les technologies automatisées les plus connues pour protéger les applications.
Les développeurs utilisent le SAST lors de la phase initiale du SDLC pour examiner leur code source à la recherche d’éventuelles vulnérabilités. Le DAST est une approche de test en boîte noire dans laquelle les outils DAST agissent comme des hackers et attaquent une application dès qu’elle est opérationnelle.
Les outils DAST produisent des résultats bien plus pertinents que les outils SAST, qui signalent souvent de nombreux faux positifs. Ensemble, les outils SAST et DAST protègent vos applications, aussi bien dans les environnements de préproduction que de production.
Les tests interactifs de sécurité des applications (IAST) sont une approche technologique relativement récente qui « instrumente » le code et surveille votre application lorsqu’elle fonctionne. Un agent déployé au sein de l’application la surveille et identifie les failles de sécurité négligées par les outils SAST et DAST.
Asaf Karas, JFrog Security CTO, estime que « l’analyse des vulnérabilités des packages constitue une première étape essentielle pour sécuriser pratiquement n’importe quel pipeline moderne de distribution logicielle. En identifiant automatiquement les vulnérabilités connues de chaque package utilisé pour déployer une application, les scanners de packages peuvent réduire considérablement le risque de mettre en production des logiciels non sécurisés. Il est également judicieux d’investir dans une base de données complète des vulnérabilités, car les bases publiques comme MITRE CVE ou la National Vulnerability Database du NIST n’intègrent pas toujours les informations les plus récentes sur les menaces. »
Adopter une infrastructure immuable
Les infrastructures immuables sont un composant essentiel d’un pipeline DevSecOps sécurisé. Contrairement à une infrastructure mutable, l’infrastructure immuable élimine la dérive de configuration, ce qui facilite le diagnostic des problèmes de vulnérabilité. Si un serveur immuable est compromis, les développeurs n’ont pas à le corriger ; ils le remplacent par un nouveau.
« L’infrastructure immuable est directement liée à l’utilisation de l’infrastructure-as-code, qui formalise l’architecture complète de l’application », explique Aakash Shah, directeur technique et cofondateur d’oak9. « Avec l’infrastructure-as-code, les entreprises peuvent aller encore plus loin dans l’approche shift-left afin de garantir que la sécurité, la stabilité et la qualité sont intégrées dès la conception, en analysant et en corrigeant les lacunes de conception. »
Kate Adam, directrice principale du marketing produit de la sécurité chez Juniper Networks estime que, même si « l’infrastructure immuable est une très bonne idée, il est irréaliste de la mettre en œuvre partout, car les applications d’une organisation sont probablement à des niveaux de maturité différents. En outre, beaucoup ne disposent pas de suffisamment de temps dans leurs cycles de planification pour déterminer toutes les exigences serveur qui pourraient être nécessaires — et chapeau aux organisations qui le font ! »
Adam ajoute : « Toutefois, lorsque les équipes peuvent rendre les applications apatrides, il est beaucoup plus facile de mettre en œuvre une infrastructure immuable, et cela devrait absolument être fait. Lorsque l’infrastructure est verrouillée de cette manière, les attaquants ont encore plus de mal à l’exploiter, ainsi que les services applicatifs qui y fonctionnent. »
À lire aussi : Les meilleurs outils de test réseau pour la vitesse et les performances en 2021
Protection à l’exécution
La protection à l’exécution est essentielle à la réussite de la mise en œuvre du DevSecOps. L’autoprotection des applications à l’exécution (RASP) est une technologie prometteuse qui ne se contente pas d’une détection basée sur les signatures, mais permet aussi de diagnostiquer les vulnérabilités et de contrer les attaques en temps réel.
Le RASP instrumente le code et est déployé avec les vulnérabilités au sein d’une application. La visibilité approfondie des couches applicatives lui permet de fournir des évaluations très précises des attaques malveillantes, en éliminant les faux positifs. Lorsqu’il est correctement mis en œuvre, le RASP permet au code de s’autoprotéger.
Cependant, la vice-présidente produit d’Aqua Security, Story Tweedie-Yates souligne qu’« il existe actuellement une importante lacune en matière de connaissances concernant la sécurité à l’exécution et qu’une étude récente a montré qu’elle n’était pas suffisamment mise en avant dans les initiatives de sécurité cloud native. Les organisations doivent investir dans la protection à l’exécution, car sans elle, d’autres éléments essentiels de leurs stratégies de sécurité du cycle de vie cloud — notamment le shift-left, le renforcement et l’analyse — pourraient être réduits à néant si des attaquants accédaient à l’environnement de production. »
Sécuriser les images de conteneurs
Les conteneurs sont couramment utilisés dans les environnements DevOps car ils assurent le déploiement et la distribution continus. Néanmoins, ils peuvent présenter certains risques de sécurité du point de vue du DevSecOps. Les images de conteneurs peuvent contenir des vulnérabilités, en particulier celles provenant de dépôts publics. Par conséquent, tout processus DevSecOps doit sécuriser les images de conteneurs tout au long de l’étape du pipeline CI/CD.
Voici plusieurs façons de procéder pour adopter une posture de sécurité robuste :
- Utiliser de petites images de base. C’est simple. Plus la taille de l’image est réduite, moins la surface d’attaque est importante.
- Utiliser des scanners d’images à toutes les étapes. Comme de nouvelles vulnérabilités sont découvertes chaque jour, il est plus sûr d’utiliser des scanners d’images à chaque étape du cycle de vie CI/CD.
- Ne jamais exécuter les images en tant que root. Exécuter des images de conteneurs en tant que root peut être une erreur coûteuse pour les développeurs. Les acteurs malveillants disposant d’un accès root peuvent causer des dommages irréversibles à votre organisation.
À lire aussi : Gérer la sécurité dans les environnements multicloud
Un changement de culture d’entreprise
Le DevSecOps introduit des pratiques de sécurité dans le cadre DevOps, ce qui appelle à un partenariat accru entre les équipes de sécurité et d’ingénierie. Mais c’est plus facile à dire qu’à faire. En réalité, les équipes de développement, d’exploitation et de sécurité travaillent en silos. Les réunir sous une même bannière s’avère compliqué.
La culture d’entreprise étant profondément ancrée dans tous les secteurs de l’activité, adopter simplement les pratiques DevSecOps ne suffira pas à entraîner une transformation à l’échelle de l’organisation. Les dirigeants doivent plutôt créer des systèmes adaptés à leurs équipes respectives et favoriser une culture de collaboration entre elles.
Il n’existe pas de solution universelle en matière de DevSecOps.
« Les professionnels du DevSecOps doivent très bien connaître les processus et méthodologies de développement », explique Adam. « Ils doivent parfaitement maîtriser la sécurité et être à la fois diplomates et ambassadeurs de la sécurité pour être efficaces dans leurs fonctions. Le DevSecOps n’est ni un produit ni un ensemble précis de technologies : c’est un rôle qui nécessite une personne, car les processus de développement logiciel diffèrent d’une entreprise à l’autre, tout comme les logiciels. »
Malgré les avantages qu’offre le DevSecOps, de nombreuses organisations restent encore sceptiques quant à l’adoption du DevSecOps. À l’instar du DevOps, le DevSecOps nécessite un changement de paradigme. Les entreprises doivent comprendre que la sécurité relève de la responsabilité de chacun et pas uniquement de l’équipe Infosec. La mise en œuvre du DevSecOps ne sera pas facile, mais ce changement en vaudra largement la peine.
À lire ensuite : Les meilleurs outils et logiciels DevOps de 2021