Récapitulatif de SnykCon : automatiser pour améliorer la conformité et accélérer les boucles de rétroaction

L’automatisation est un élément clé du DevSecOps, car elle améliore l’efficacité. Automatiser les tâches au cours du cycle de vie de développement logiciel vous aide à intégrer plusieurs outils à votre flux de travail. Cela permet aussi aux développeurs, aux responsables de maintenance et aux référents sécurité de se concentrer sur des solutions créatives à des problèmes complexes, plutôt que de perdre du temps avec des tâches manuelles fastidieuses.

Deux présentations de SnykCon 2021 portaient sur l’automatisation. Sam Hodgkinson et Ben Davies de Citrix ont expliqué comment ils ont utilisé l’automatisation pour simplifier le processus d’approbation des licences open source. David Wiggs, de Bain, nous a proposé une analyse approfondie de l’automatisation au service des pipelines en tant que service, en expliquant comment son équipe a intégré la sécurité à son pipeline CI/CD. Les deux sessions ont mis en évidence le rôle de l’automatisation dans le renforcement des flux de développement.

Automatiser l’approbation des licences open source

Beaucoup de personnes connaissent les logiciels open source, mais moins nombreuses sont celles qui connaissent les licences open source. Le code open source est écrit par des développeurs et librement accessible au public. Les licences open source définissent comment et quand vous pouvez utiliser un package open source. L’automatisation peut détecter et analyser les licences open source dans votre code. Vous êtes ainsi informé des restrictions de licence applicables aux packages open source et pouvez les comparer à vos politiques juridiques internes pour vous assurer que votre code est conforme.

Le défi à relever

Les ingénieurs de Citrix souhaitaient pouvoir repérer toutes les licences open source d’un projet, tout en prenant en charge les nombreux gestionnaires de packages et langages utilisés dans l’organisation. Ils voulaient également bloquer les builds CI/CD en cas de non-conformité des licences et collaborer avec leur équipe juridique pour définir des politiques plus claires pour tous.

Sam et Ben ont commencé à étudier la plateforme Snyk pour trouver une solution. Ils tenaient à créer un flux de travail fluide et centré sur les personnes, sans compliquer la vie des ingénieurs ni de l’équipe juridique. Ils appréciaient également la simplicité des interactions utilisateur qu’ils pouvaient mettre en place avec les outils Snyk.

Ils ont ensuite cherché à intégrer l’ensemble du processus de définition des politiques juridiques dans une API automatisée, en veillant à ce que leur solution puisse évoluer pour répondre à de futurs besoins.

Grâce aux résultats fournis par Snyk, Sam et Ben ont pu prendre des décisions à l’aide de leur API de politiques et fournir aux développeurs des commentaires clairs pour les aider à déterminer si une politique était approuvée ou refusée.

La solution mise au point

Ils ont créé un pipeline CI/CD qui commence par le code source, traité directement par la CLI Snyk. Snyk analyse le code source et renvoie des informations sur les licences. Ces informations passent par un contrôle des licences, qui détermine si une partie du code doit être « bloquée » en fonction de l’utilisation des licences. Le code qui franchit ce contrôle est envoyé à une API de politiques, qui répond par oui ou par non. (Les politiques sont définies par l’équipe juridique de Citrix.) Dans 90 % des cas, ce processus est entièrement automatisé. Dans les autres cas, un ticket peut être créé pour qu’un membre de l’équipe juridique procède à une vérification manuelle. Cette vérification n’est toutefois pas perdue : ses résultats alimentent l’API de politiques pour approbation, et le développeur peut poursuivre son travail.

« En automatisant entièrement ce processus… nous avons réduit un processus de deux semaines à quelques secondes pour la plupart des décisions liées aux politiques — 90 % d’entre elles. C’est formidable. »

Citrix a créé un moteur de politiques personnalisé reposant sur un cadre juridique complexe. Snyk a aidé son équipe à surmonter les obstacles techniques pour automatiser entièrement le processus et assurer la sécurité au sein du pipeline CI/CD. Le délai de résolution a également été réduit. Grâce à l’automatisation, la plupart des décisions relatives aux politiques sont prises en quelques secondes. Sam et Ben activent désormais leurs outils Snyk dans la configuration de leurs builds, et la technologie fait le reste.

Boucler la boucle de rétroaction

Intégrer la sécurité à un pipeline de développement logiciel n’est pas une idée nouvelle. Pourtant, on s’intéresse souvent davantage à la mécanique du pipeline qu’à la façon dont il est utilisé. David Wiggs, de Bain, pose la question : les développeurs utilisent-ils le pipeline de développement logiciel que vous mettez à leur disposition, et y trouvent-ils ce dont ils ont besoin ? Considérez les outils de sécurité et de test comme des produits utilisés par les développeurs. Si votre pipeline est un produit, vos utilisateurs (les développeurs) en tirent-ils le meilleur parti ?

Trois piliers de l’automatisation

Le modèle du « pipeline en tant que service » commence par un dépôt de travail. Vous pouvez ensuite ajouter un dépôt d’« actions personnalisées », qui définit les sources des étapes des pipelines. Enfin, vous pouvez disposer d’un dépôt d’outils : une enveloppe d’API, un outil de gestion de dépôts ou tout autre outil d’automatisation spécifique.

Ces trois premiers piliers réduisent le nombre d’endroits où les modifications sont effectuées et suivies. Lorsque les utilisateurs proposent des améliorations à votre processus, vous pouvez les apporter à un seul endroit au lieu de les répéter dans plusieurs emplacements.

Lancer le flux de travail

Cette structure vous prépare aux étapes suivantes :

1. Le flux de travail du pipeline est déclenché (autrement dit, le pipeline s’« exécute »). Le dépôt d’actions personnalisées est récupéré.

2. Le fichier action.yml récupère un dépôt spécifique à un outil de sécurité.

3. Les scripts propres à l’outil sont exécutés. Ainsi, les demandes de fonctionnalités ou les mises à jour sont effectuées à un seul endroit central, et toutes les personnes qui utilisent une action personnalisée bénéficient des modifications.

Examinons cette même architecture de pipeline en partant de la base, avec le dépôt de l’outil de sécurité. Ce dépôt peut contenir des scripts définissant plusieurs fonctions. Par exemple, vous pouvez appeler un script PowerShell qui utilise l’API Snyk pour vérifier si un dépôt donné se trouve sur la plateforme Snyk et, dans le cas contraire, l’y importer. À ce stade, quelques scripts sont exécutés et le reste de l’architecture permet de les réutiliser dans un dépôt de travail donné.

Passons maintenant à la couche supérieure. Le dépôt d’actions personnalisées récupère le dépôt des outils de sécurité et exécute un script spécifique à la sécurité. Les actions composites vous permettent d’orchestrer plusieurs commandes en une seule étape. Cette couche d’abstraction simplifie l’expérience utilisateur, tout en vous permettant d’appeler plusieurs scripts et d’introduire des dépendances.

Tout cela se passe dans le fichier action.yml, qui vous permet de définir des versions sans devoir nécessairement apporter des modifications à plusieurs dépôts de travail.

Au niveau supérieur, vous permettez à un dépôt de travail d’accéder à l’action personnalisée GitHub. Lorsque le flux de travail du dépôt de travail s’initialise, il récupère le dépôt des actions personnalisées et intègre son contenu à l’environnement d’exécution. Vous effectuez ensuite une nouvelle récupération imbriquée, ce qui vous permet d’utiliser le fichier action.yml et les scripts du dépôt d’outils, le tout dans l’environnement d’exécution du dépôt de travail.

Du point de vue de l’utilisateur, vous avez introduit plusieurs scripts personnalisés, mais de façon « native ». Vous avez intégré la sécurité au pipeline à l’aide des outils Snyk et des actions GitHub. Si les actions GitHub peuvent intégrer des outils de sécurité à un pipeline, les développeurs n’ont pas besoin de quitter leur environnement de travail habituel (GitHub) pour accéder aux informations de sécurité liées à leur processus de développement. En arrière-plan, vous avez accéléré la boucle de rétroaction sans demander aux développeurs de modifier plusieurs emplacements.

Explorer l’automatisation pour améliorer les flux de travail

L’automatisation peut améliorer l’efficacité dans toute votre organisation. Ces présentations décrivent deux façons de tirer parti de l’automatisation, mais il en existe bien d’autres. La plateforme Snyk met à votre disposition de nombreux outils pour intégrer l’automatisation à vos flux de travail et appliquer facilement des normes de sécurité tout au long de votre processus de développement.