DevSecOps - Tout ce que vous devez savoir

Temps de lecture :  5 minutes

DevSecOps est devenu l'un des mots à la mode les plus en vogue dans l'écosystème DevOps au cours des 3 dernières années. Dans l'abstrait, il est facile de comprendre ce que signifie DevSecOps et pourquoi les gens s'en soucient : c'est une stratégie qui étend l'efficacité de DevOps à la sécurité logicielle.

Mais lorsque vous vous asseyez et commencez réellement à implémenter DevSecOps, les choses peuvent devenir plus compliquées. Il n'y a pas de commutateur que vous pouvez basculer pour atteindre DevSecOps - la mise en œuvre nécessite un ensemble d'outils et de pratiques.

Voyons comment procéder en parcourant les principales considérations que l'organisation type doit prendre en compte pour atteindre DevSecOps.

Fondamentalement, DevSecOps est DevOps avec une sécurité intégrée, dès le départ. Cela signifie intégrer la sécurité dans les exigences, dans la conception, le code et les étapes de déploiement - en bref, dans l'ensemble de votre pipeline DevOps.

Les anciennes pratiques de sécurité ont tendance à ralentir les équipes de développement et lorsque le délai de mise sur le marché se raccourcit chaque année, les équipes de développement de logiciels ont dû trouver un moyen d'accélérer leur processus de développement de logiciels sans compromettre la sécurité. C'est ainsi que DevSecOps a commencé.

L'objectif ultime est de faire le pont entre les équipes de sécurité et les développeurs tout en garantissant une livraison rapide et sûre du code. La pensée en silo est remplacée par la communication entre les différentes équipes et la responsabilité partagée de la sécurité des applications.

Comment traduisez-vous ces objectifs en pratique ? Quels processus de sécurité spécifiques pouvez-vous automatiser et intégrer au reste de votre pipeline CI/CD, et comment pouvez-vous le faire ?

Explorons ces questions et cherchons des réponses, basées sur l'état actuel des outils et des pratiques DevSecOps.

1. Analyse des vulnérabilités

L'analyse de votre code à la recherche de vulnérabilités est une première étape de base pour sécuriser vos produits. Et l'intégration de l'analyse des vulnérabilités dans votre processus CI/CD est un point de départ évident pour la mise en œuvre de DevSecOps.

Cela signifie s'assurer que le code est vérifié pour les vulnérabilités à chaque étape majeure du pipeline de livraison - à partir du moment où il est écrit jusqu'à son déploiement en production. Pour atteindre ce niveau d'intégration, vous devrez vous assurer que les parties responsables de ces différentes étapes du pipeline disposent de la formation et des outils nécessaires pour détecter les vulnérabilités dans votre code.

Les technologies pertinentes sont SAST pour détecter les vulnérabilités dans votre code propriétaire et les outils SCA pour détecter les composants open source avec des vulnérabilités connues . De nombreux fournisseurs SAST et SCA proposent une intégration aux serveurs CI, des outils de construction, des référentiels et certains également une intégration aux IDE pour aider les développeurs à trouver les problèmes le plus tôt possible.

2. Protection de l'exécution

La protection à l'exécution est un autre processus de sécurité critique qui doit être intégré dans le pipeline CI/CD dans le cadre d'une stratégie DevSecOps.

La protection à l'exécution signifie sécuriser le logiciel contre les menaces qui peuvent survenir lorsque votre application démarre. Bien que les discussions sur la sécurité d'exécution se soient traditionnellement concentrées sur la sécurisation des logiciels uniquement une fois qu'ils sont en production, des menaces d'exécution peuvent également exister au cours des premières étapes du pipeline - et même si elles ne le font pas, penser à la sécurité d'exécution au début du processus de livraison permet de garantir que lorsque vous déployez, vous avez déjà atténué les menaces d'exécution. Ces deux raisons expliquent pourquoi la sécurité d'exécution doit être intégrée dans le pipeline CI/CD, et non limitée aux environnements de production.

Les outils et stratégies spécifiques que vous utilisez pour la détection d'exécution varieront en fonction de vos besoins spécifiques. Au minimum, cependant, vous voudrez vous assurer que vous surveillez votre application pour détecter tout comportement inhabituel qui pourrait signaler une violation. Tout aussi important, vous devez savoir quelles variables d'environnement ou quels paramètres de configuration peuvent créer des vulnérabilités de sécurité au cours de l'exécution, et disposer d'un processus pour identifier ces risques.

3. Votre fournisseur de services cloud

Une autre stratégie importante pour intégrer la sécurité dans votre processus de livraison d'applications consiste à tirer parti des fonctionnalités de sécurité offertes par votre fournisseur de services cloud. Beaucoup de ces outils sont positionnés à la fin du déploiement et du post-déploiement de votre chaîne DevOps, et ressemblent donc à des services de sécurité après coup plus traditionnels. Mais ils remplissent toujours une fonction importante dans le cadre des défenses externes de votre application - et comme ils font partie de l'infrastructure cloud, ils sont généralement faciles à automatiser et à systématiser.

Notez que les fonctionnalités de sécurité de votre CSP peuvent ne pas être activées par défaut et qu'elles peuvent nécessiter une certaine configuration, vous devrez donc peut-être prendre des mesures actives afin d'en tirer le meilleur parti.

4. Normes et politiques

L'établissement de normes et de politiques de sécurité est en grande partie un travail pratique. Vous pouvez analyser votre code source et votre infrastructure à la recherche de vulnérabilités, mais le processus consistant à décider quelles devraient être vos priorités de sécurité et comment elles devraient être mises en œuvre nécessite toujours une réflexion approfondie de la part des êtres humains. Il en va de même pour l'intégration de normes de sécurité aux niveaux de la conception et du code.

La mise en œuvre du règlement général sur la protection des données (RGPD) de la part de l'UE rend encore plus important que les normes de sécurité soient clairement formulées et mises en place au niveau de la conception.

D'un autre côté, la création de telles normes au niveau opérationnel peut être automatisée dans une large mesure, en utilisant des outils d'orchestration/des fonctionnalités de maillage de services telles que RBAC pour appliquer des politiques avec un degré élevé de granularité. La conception de stratégies d'accès basées sur les rôles doit recevoir autant d'attention que la conception de normes de sécurité dans le code source de votre application, et elles doivent toutes deux être considérées comme des tâches hautement prioritaires.

5. Gestion des conteneurs et des services

Les outils d'orchestration de conteneurs tels que Kubernetes sont devenus une quasi-nécessité lorsqu'il s'agit de déployer de grandes applications basées sur des conteneurs. Les services mesh , qui peuvent fonctionner avec des outils d'orchestration et gérer des éléments tels que la découverte et l'accès aux services, ainsi que la relation entre les utilisateurs, les applications basées sur des conteneurs et les services externes, deviennent de plus en plus importants en eux-mêmes.

De tels outils sont un élément clé de DevSecOps au niveau du déploiement. Ils agissent comme des couches d'isolation hautement évolutives entre les conteneurs et le monde extérieur (de sorte que les utilisateurs et les attaquants potentiels ne peuvent accéder qu'aux services cachés derrière des proxy, par exemple, plutôt qu'à des conteneurs individuels), et ils peuvent prendre en charge des tâches telles que l'authentification , l'autorisation et le cryptage. Et ils sont conçus pour l'automatisation à partir de zéro.

Cependant, encore plus qu'avec les outils de sécurité CSP, vous devez connaître les fonctionnalités de sécurité fournies par les outils d'orchestration et les maillages de services, et vous devez les activer (si nécessaire) et les configurer. La configuration d'accès basée sur les rôles (RBAC) de Kubernetes, par exemple, devrait être un élément clé de DevSecOps dans la plupart des circonstances, mais elle n'est pas activée par défaut.

La mise en œuvre de DevSecOps vous oblige à effectuer une évaluation globale de vos ressources informatiques et processus DevOps existants, puis de créer une stratégie holistique qui intègre une sécurité renforcée dans chacun d'eux. 

Il existe d'autres aspects importants de DevSecOps qui doivent être pris en compte dans votre stratégie de mise en œuvre, tels que la surveillance, l'analyse des journaux et les alertes. Cependant, bon nombre d'entre eux sont des éléments standard des logiciels et de la sécurité Internet en général, je ne me suis donc pas concentré sur eux dans cet article. Au lieu de cela, j'ai centré la discussion sur la façon dont DevSecOps peut pleinement intégrer le développement d'applications, la gestion de l'infrastructure et d'autres activités DevOps qui n'ont pas été traditionnellement associées à la sécurité.

Et c'est peut-être le résultat final : lorsque la sécurité devient pleinement intégrée au pipeline CI/CD, DevOps et DevSecOps deviennent la même chose, et cela devient à son tour simplement « la façon dont nous faisons des logiciels ».