En tant que professionnel des opérations dans une entreprise de sécurité cloud, j'ai une perspective unique sur la manière dont la sécurité et les opérations peuvent – et devraient, dans un monde idéal – fonctionner ensemble. L'un des problèmes courants que nous constatons aujourd'hui dans le secteur technologique est que la sécurité est presque toujours intégrée trop tard dans le processus de développement.

On peut avoir l'impression que la sécurité est une discipline à part entière, et l'intégrer dans des boucles de rétroaction DevOps étroites peut sembler intimidant. Mais je suis ici pour vous dire que non seulement peut cela peut être fait, mais ce n'est pas aussi difficile qu'il y paraît - et le faire correctement fera une grande différence dans votre posture de sécurité globale tout en éliminant une multitude de points sensibles.

En particulier, le concept de « shifting left » permet aux équipes de prendre les processus de sécurité qu'elles utilisaient auparavant beaucoup plus tard dans le processus de déploiement (voire pas du tout) et de les introduire plus tôt pour garantir que la sécurité est intégrée, plutôt que de manière rétrospective. Dans cet article, je vais vous expliquer comment procéder.

Que signifie « trop tard » ?

Commençons par examiner rapidement la manière dont la sécurité est intégrée aux processus DevOps aujourd'hui. Souvent, ce n'est tout simplement pas le cas. Cela se manifeste par le fait que les ingénieurs déploient du code dès qu'il est prêt et n'intègrent pas du tout la sécurité dans le processus. Bien entendu, les développeurs qui font cela ne font que leur travail. Ils subissent la pression des équipes produit pour publier des fonctionnalités, et ils font simplement ce qu'ils doivent faire pour sortir le code aussi vite que possible.

Dans d’autres cas, les équipes de sécurité seront intégrées à ce flux et deviendront les gardiennes, exigeant une analyse de sécurité avant que le code ne puisse être publié. Il est bon de voir les équipes de sécurité être impliquées et le code examiné pour détecter les failles de sécurité. Mais attendre la dernière minute peut entraver les cycles de livraison continus, et dans le climat actuel qui évolue rapidement, ce n’est souvent pas une option. Sans compter que cela peut conduire à de réelles tensions entre ces équipes en les mettant en opposition les unes avec les autres.

Comment commencer à changer de direction vers la gauche

Ces dernières années, de plus en plus d'entreprises optimisent leurs équipes DevOps pour évoluer plus rapidement et livrer des logiciels en continu. Mais il est temps d'intégrer la sécurité dans le processus. Voici donc mes conseils pour y parvenir.

Utilisez les mêmes outils

Il est important que vos équipes de sécurité se familiarisent avec les mêmes outils d'intégration et de livraison continues que vos équipes DevOps. C'est ainsi que Dev et Ops ont commencé à bien travailler ensemble en premier lieu, en enseignant aux Ops comment coder et aux développeurs comment utiliser des outils de gestion de configuration comme Chef. Il est temps de faire de même avec la sécurité.

Jenkins est un bon exemple. Si vos développeurs utilisent déjà Jenkins pour tester et déployer du code, pourquoi ne pas apprendre à votre équipe de sécurité à l'utiliser également ? S'ils utilisent le même outil pour les tests de sécurité, il est beaucoup plus facile de les intégrer au processus dès le début.

Un autre excellent outil s'appelle Gantelet . Bien que j’aie quelques réserves sur le terme « DevOps robuste », l’idée derrière Gauntlt est bonne. Extrait de leur site :

« Gauntlt fournit des points d'accès à une variété d'outils de sécurité et les met à la portée des équipes de sécurité, de développement et d'exploitation pour collaborer à la création de logiciels robustes. Il est conçu pour faciliter les tests et la communication entre les groupes et créer des tests exploitables qui peuvent être intégrés à vos processus de déploiement et de test. »

Le concept d'intégration de la sécurité au cœur de vos processus opérationnels et de développement est fondamentalement judicieux. De cette façon, la sécurité ne ralentit pas la livraison et vous pouvez resserrer la boucle de rétroaction lorsqu'un problème est découvert. Les équipes de sécurité peuvent écrire du code à l'aide de Gauntlt et le tester avant sa sortie, facilitant ainsi une livraison continue et réussie.

Essayez l'analyse statique

Une autre option consiste à essayer l’analyse statique à l’aide d’un outil tel que Veracode . Vos équipes de sécurité peuvent ensuite analyser le code avant le déploiement et tenter de détecter d'éventuels problèmes. L'analyse statique consiste essentiellement à analyser le logiciel sans exécuter le code. Les équipes de sécurité peuvent l'utiliser pour vérifier les vulnérabilités potentielles de manière automatisée, sans interrompre le cycle de livraison du logiciel.

Aligner les incitations

Historiquement, l'un des défis de la collaboration entre DevOps et sécurité est que ces deux acteurs ont des motivations contradictoires. DevOps gagne lorsqu'il publie rapidement du code. La sécurité ne gagne que lorsque du code sécurisé est publié.

Les équipes DevOps et les équipes de sécurité travaillent mieux ensemble lorsqu’elles utilisent les mêmes outils ou des outils compatibles, comme expliqué ci-dessus. Mais pour aller plus loin, vous devez également vous assurer d’aligner les incitations entre ces équipes. Cela signifie récompenser DevOps pour la publication de code sécurisé et récompenser la sécurité pour sa rapidité d’exécution.

Fournir la propriété

L'une des erreurs les plus courantes que nous observons est celle des équipes où la sécurité n'a même pas accès à la production. Si la sécurité n'a pas de propriété directe sur le code, vous pouvez parier qu'elle ne sera pas étroitement intégrée aux cycles DevOps.

En revanche, lorsque vous donnez aux responsables de la sécurité la responsabilité de résoudre les problèmes dans le code par eux-mêmes et que vous leur apprenez à le faire, ils peuvent faire partie d'une machine bien huilée plutôt que d'un silo. Par exemple, Pile de menaces peut alerter votre équipe sur les problèmes de sécurité. Si vous apprenez aux équipes de sécurité comment résoudre ces problèmes et leur donnez accès au code de gestion de la configuration, elles peuvent y accéder et apporter directement des modifications au système.

De la même manière, Chef a ouvert le code source d'un outil appelé InSpec , qui est un framework d'audit et de test. Avec InSpec, les équipes de sécurité peuvent écrire du code pour auditer les serveurs et garantir la conformité. Cela leur donne, encore une fois, une appropriation beaucoup plus directe du processus. Donnez aux équipes de sécurité les moyens d'améliorer leurs compétences DevOps et vous en verrez la preuve.

Une autre façon d'aborder ce problème (surtout si vous n'avez pas d'équipe de sécurité dédiée) est de confier aux ingénieurs back-end la responsabilité de corriger le code lorsque des vulnérabilités de sécurité apparaissent. Lorsque les ingénieurs sont directement responsables de la santé de leur code, ils sont beaucoup plus susceptibles de se concentrer sur sa construction en toute sécurité en premier lieu. Chez Threat Stack, nous avons 2 personnes chargées des opérations et 10 ingénieurs back-end sur appel. Ainsi, lorsqu'un problème survient avec le produit, ce sont généralement les équipes d'ingénierie back-end qui ont écrit le code qui sont appelées à le résoudre. Ce niveau de propriété du code les incite à bien construire dès le départ.

La voie à suivre est latérale

Le transfert de la sécurité vers la gauche est meilleur pour la santé globale de votre entreprise. Plutôt que de devoir détecter les problèmes, d'ouvrir des tickets et d'attendre que les développeurs ou les professionnels des opérations résolvent les problèmes, les équipes de sécurité sont habilitées à le faire elles-mêmes. Cela permet non seulement d'économiser du temps et de la main-d'œuvre, mais garantit également que le code peut être publié de manière continue et sécurisée. Il appartient à tous les acteurs de cette équation de devenir plus proactifs pour apprendre comment les autres équipes travaillent et comment elles peuvent être plus étroitement intégrées dans ces flux de travail.

Les conseils ci-dessus devraient vous donner un point de départ pour faire du « déplacement de la sécurité vers la gauche » une réalité dans votre organisation. N’oubliez pas que, comme pour de nombreux aspects de la sécurité, cela nécessite une changement culturel (pas seulement en apportant de nouveaux outils.) Mais cela peut être fait avec le bon état d'esprit, des incitations et des boucles de rétroaction en place.