DevSecOps : sécuriser les pipelines CD

Découvrez comment DevSecOps impacte le pipeline CD ainsi que les pratiques de sécurité des équipes de développement Agile.

Juni Mukherjee Juni Mukherjee

Qu'est-ce que l'approche DevSecOps ?

Le terme DevSecOps est utilisé pour décrire un cycle de vie de développement logiciel (SDLC) axé sur la sécurité dans le cadre de la livraison continue. Les principes DevSecOps reposent sur les bonnes pratiques et les enseignements tirés de l'approche DevOps générale. Dans le cadre de l'application des valeurs DevOps à la sécurité logicielle, la vérification de la sécurité est intégrée au processus de développement, auquel elle participe activement. Traditionnellement, et trop souvent malheureusement, la sécurité est reléguée au second plan. Le service de sécurité informatique collabore souvent avec les équipes de développement à la fin du SDLC. Aussi nobles que soient leurs intentions, il peut être frustrant de découvrir des failles de sécurité à la fin du SDLC.

DevSecOps fait de l'engagement traditionnel en matière de sécurité un processus actif du SDLC. L'approche DevOps générale a introduit des processus tels que l'intégration continue (CI) et la livraison continue (CD). Ces processus permettent de tester et de vérifier activement l'exactitude du code pendant le processus de développement Agile. De même, DevSecOps intègre des audits de sécurité actifs et des tests d'intrusion dans le développement Agile. L'approche préconise que la sécurité soit intégrée au produit, plutôt qu'appliquée à un produit fini.

Clé dans un cadenas | CI/CD Atlassian

Pourquoi DevSecOps ?

En bref : pour la sécurité. Il est primordial de disposer de logiciels sûrs et sécurisés, faute de quoi nos moyens de subsistance axés sur la technologie seront menacés. Les violations de sécurité constituent l'une des plus grandes menaces auxquelles les organisations et nos gouvernements sont confrontés aujourd'hui. Les lignes de sécurité de plusieurs grandes organisations ont été récemment percées, ce qui a entraîné d'énormes retombées et des démissions soudaines de dirigeants. Les dirigeants fautifs font la une des journaux alors que les consommateurs continuent de perdre confiance dans les fournisseurs de services compromis.

Les principes DevSecOps favorisent la collaboration et évitent les transferts tardifs aux professionnels de la sécurité. L'intérêt est évident lorsque l'on examine les durées de cycle avant et après l'application de ces principes. Avant l'application des principes DevSecOps, votre produit peut être considéré comme non sécurisé à la dernière minute, entraînant de multiples itérations coûteuses. Après l'application des principes DevSecOps, les règles d'or de la sécurité sont intégrées à votre produit. Il est possible que vous détectiez des problèmes inattendus à la dernière minute, mais la probabilité que cela se produise est beaucoup plus faible.

La question n'est donc pas tant de savoir « pourquoi DevSecOps ? » mais plutôt comment nous pouvons réussir à l'ère DevSecOps. Pour les personnes empêtrées dans des mesures de sécurité traditionnelles, DevSecOps est une bouffée d'air frais. Les solutions peuvent varier en fonction de votre stack technique et de votre architecture. En effet, il ne s'agit pas d'un mandat universel d'une organisation centralisée.

Dans l'ensemble, vos pratiques de sécurité renforcent votre crédibilité sur le marché et renforcent la confiance des consommateurs. Dans cette optique, le moment est parfaitement choisi pour discuter de la façon dont DevSecOps s'inscrit dans le paradigme du « Continuous Everything ».

DevSecOps et le « Continuous Everything »

Les bibliothèques de logiciels open source (OSS) que nous importons peuvent comporter des failles de sécurité, tout comme le code que nous programmons. Des milliers de développeurs effectuent des tâches de programmation chaque jour, et les contrôles manuels du code n'évoluent pas. C'est là que réside le vrai pouvoir des principes DevSecOps.

DevSecOps et le « Continuous Everything » sont comme les deux faces d'une pièce de monnaie. DevSecOps fonctionne de concert avec le paradigme du « Continuous Everything » et pérennise la sécurisation de nos livrables logiciels.

Les pipelines de livraison continue sont des implémentations du paradigme du « Continuous Everything » et permettent de valider chaque commit de votre équipe. Intégrez des contrôles de sécurité automatisés au pipeline pour recevoir des alertes anticipées, et surveillez sans relâche les failles de sécurité qui passent entre les mailles du filet. Les approches intégrées de la sécurité continue évoluent à mesure que votre entreprise se développe.

Les tests unitaires ainsi que les analyses de code statiques fonctionnent au plus près du code source et effectuent des vérifications sans exécuter le code. N'oubliez pas, le coût associé aux défauts est faible dans l'environnement de test, modéré dans l'environnement de staging et élevé en production. Investissez donc dans des tests unitaires de sécurité et des analyseurs statiques, car ils sont peu coûteux et rapides, et peuvent vous éviter d'autres problèmes en aval du pipeline.

Implémentation de la sécurité continue : tests unitaires

Vous devriez commencer par appliquer la sécurité continue aux tests unitaires de sécurité.

Dans les notions fondamentales du pipeline de livraison continue, nous définissons les composants comme les plus petites unités distribuables et testables. Ils peuvent être validés par des tests unitaires. Les tests unitaires de sécurité sont tout aussi importants que les autres tests que nous créons, mais certaines équipes parviennent toujours à négliger totalement cette catégorie.

Méthode SAST

Outre la détection des violations des bonnes pratiques de programmation, les analyseurs de code statique détectent les failles de sécurité dans le code que vous possédez et dans les bibliothèques (probablement non sécurisées) que vous importez. C'est ce qu'on appelle la méthode SAST (test dynamique de la sécurité des applications) et les outils modernes s'intègrent bien au pipeline de livraison continue. Assurez-vous de choisir un analyseur SAST compatible au langage de programmation de votre choix.

Attention : le test SAST peut souvent signaler des faux positifs, et il faut donc prévoir une couche de persistance qui aide les pipelines à « mémoriser » des informations. Ces faux positifs peuvent s'avérer agaçants pour l'équipe au point qu'elle cesse de répondre aux problèmes notifiés dans le pipeline, ce qui est dangereux. Une fois que les équipes ont identifié une erreur comme un faux positif grâce à une justification appropriée, ne laissez pas le pipeline la signaler encore et encore. Cela peut pousser les équipes à désactiver le test SAST ou à faire en sorte que les pipelines ignorent complètement les erreurs SAST.

Méthode DAST

Les composants à couplage lâche constituent un sous-système. Les sous-systèmes peuvent être déployés et testés pour détecter les failles de sécurité à l'aide de la méthode DAST (test de la sécurité par analyse dynamique). Contrairement à la méthode SAST, la méthode DAST étudie une application en fonctionnement depuis l'extérieur, tout comme le ferait un attaquant. Les dispositifs d'analyse DAST ne s'appuient pas nécessairement sur des langages spécifiques, étant donné qu'ils interagissent avec l'application depuis l'extérieur.

L'important est d'inclure à la fois la méthode SAST et la méthode DAST à votre stratégie de sécurité puisque chacune apporte ses propres avantages. Intégrez les deux approches au pipeline CD afin d'obtenir un feedback anticipé.

DevSecOps est l'avenir de la sécurité

Dans le monde actuel, la sécurité, tout comme la qualité, est le travail de tous. Ne laissez pas un silo d'experts autoproclamés limiter votre vision. Les entreprises et les dirigeants réactifs qui ont agi de la sorte sont confrontés à de graves conséquences et dynamisent aujourd'hui leur stratégie de sécurité en injectant de nouveaux fonds.

Les professionnels de la sécurité traditionnels fonctionnent en silo, et leur capacité est limitée par le nombre d'agents disponibles dans ce silo. Adoptez plutôt l'approche Agile et décentralisée de DevSecOps, et formez à nouveau vos équipes à contrôler leur propre destinée. En outre, responsabilisez vos équipes de développement produit, afin d'éviter les conflits entre ces dernières et le service de sécurité informatique.

Grâce au développement de la communauté DevSecOps, la sécurité n'est pas seulement une priorité métier, c'est aussi la toute dernière amélioration à intégrer dans le pipeline de livraison continue ! Combinée à la sécurité, la continuité garantit que l'avenir radieux de la livraison de logiciels.