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

L’automatisation est un maillon clé de DevSecOps, car elle permet d’accroître l’efficacité. L’automatisation des tâches dans votre cycle de développement du logiciel vous permet d’intégrer de nombreux outils dans votre workflow. Elle permet aussi aux développeurs, aux chargés de maintenance et aux ambassadeurs de la sécurité d’imaginer des solutions créatives à des problèmes complexes plutôt que de perdre du temps sur des tâches manuelles chronophages.

Deux des présentations de SnykCon 2021 étaient dédiées à l’automatisation : Sam Hodgkinson et Ben Davies de Citrix ont expliqué en détail comment ils recouraient à l’automatisation pour simplifier le processus d’approbation des licences open source. David Wiggs de Bain nous a quant à lui montré comment l’automatisation permettait de proposer des pipelines en tant que service, en expliquant comment son équipe a pu intégrer la sécurité à son pipeline de CI/CD. Les deux sessions ont prouvé que l’automatisation permettait de renforcer le workflow de développement.

Automatisation de l’approbation des licences open source

De nombreuses personnes connaissent les logiciels open source, mais peu connaissent leurs licences. Le code open source est écrit par des développeurs et utilisable par tout à chacun. Les licences open source déterminent comment et dans quels cas vous pouvez utiliser un paquet open source. L’automatisation peut détecter et analyser les licences open source incluses dans votre code. Vous êtes ainsi alerté des restrictions de licence applicables à vos paquets open source et pouvez les comparer à vos politiques juridiques internes pour vous assurer que votre code est conforme.

Le défi

Les ingénieurs de Citrix souhaitaient pouvoir détecter toutes les licences open source contenues dans un projet tout en prenant en charge les nombreux gestionnaires de paquets et langages utilisés en interne. Ils voulaient aussi bloquer les versions non conformes aux licences dans le pipeline de CI/CD et collaborer avec l’équipe juridique afin d’établir des politiques plus claires et applicables à tous.

Sam Hodgkinson et Ben Davies se sont alors intéressés à la plateforme de Snyk. Ils voulaient à tout prix créer un workflow fluide et axé sur l’humain, ne générant aucune difficulté pour les ingénieurs et l’équipe juridique. Ils ont particulièrement apprécié les interactions simplifiées avec les outils de Snyk.

Ensuite, ils ont travaillé sur l’intégration de l’ensemble du processus d’application de leur cadre juridique dans une API automatisée, tout en veillant à ce que leur solution puisse s’adapter à leurs besoins futurs.

Avec les données générées par Snyk, ils ont pu prendre des décisions conformes à leurs politiques en s’appuyant sur leur API et fournir des retours utiles aux développeurs pour les guider face aux approbations et refus.

La solution créée

Ils ont créé un pipeline de CI/CD allant du code source jusqu’à la CLI Snyk. Snyk analyse le code source et renvoie les informations de licence. Ces informations sont transmises à un mécanisme de gating qui détermine s’il faut rejeter ou non une partie de code en raison de la licence utilisée. Le code qui passe par ce mécanisme est envoyé à une API de politique, qui répond par oui ou par non. (Les politiques sont établies par l’équipe juridique de CItrix.) Ce processus est entièrement automatisé dans 90 % des cas. Certains cas peuvent générer un ticket devant être traité manuellement par un membre de l’équipe juridique. Pour autant, cet examen manuel n’est pas perdu : il est transmis à l’API de politique, et le développeur n’est pas bloqué.

« En automatisant totalement ce processus, nous l’avons fait passer de deux semaines à quelques secondes. Nous avons obtenu le même résultat pour 90 % des évaluations de politiques. C’est super. »

Citrix a mis au point un moteur de politiques sur mesure basé sur un cadre juridique complexe. De son côté, Snyk a aidé son équipe à résoudre des difficultés techniques liées à l’automatisation totale du processus, permettant ainsi de sécuriser l’intégralité du pipeline de CI/CD. Le temps nécessaire à la résolution des problèmes a aussi été réduit. De plus, avec un processus automatisé, la plupart des décisions liées aux politiques ne prennent que quelques secondes. Sam Hodgkinson et Ben Davies utilisent désormais leurs outils Snyk dans leur configuration de développement, et la technologie est autonome.

Boucler la boucle de rétroaction

L’idée d’introduire la sécurité dans le pipeline de développement logiciel n’a rien d’inédit. Pour autant, nous avons tendance à nous concentrer sur le fonctionnement du pipeline plutôt que l’utilisation qui en est faite. David Wiggs de Bain a posé la question suivante : les développeurs utilisent-ils le pipeline de développement logiciel que vous fournissez et en tirent-ils ce dont ils ont besoin ? Vous devez considérer 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 (développeurs) en sont-ils satisfaits ?

Les trois piliers de l’automatisation

Le modèle de « pipeline en tant que service » commence par un référentiel de travail. Il peut ensuite être complété par un référentiel « d’action personnalisée », qui détermine l’emplacement à partir duquel les pipelines récupèrent les étapes. Enfin, vous pouvez déployer un référentiel dédié aux outils : encapsuleur d’API, outil de référentiel ou encore toute automatisation spécifique à un outil.

Ces trois piliers permettent de limiter le nombre d’emplacements dans lesquels des modifications sont effectuées et doivent donc être suivies. Lorsque des utilisateurs suggèrent des améliorations des processus, vous pouvez les déployer dans un seul endroit, au lieu de les répéter à de multiples emplacements.

Appeler le workflow

Cette organisation vous permet ensuite de procéder comme suit :

1. Le workflow du pipeline est déclenché (« exécution » du pipeline). Le référentiel d’action personnalisée est extrait.

2. Le fichier action.yml extrait un référentiel spécifique à l’outil de sécurité.

3. Les scripts spécifiques à l’outil sont exécutés. Ainsi, les demandes de fonctionnalités et les mises à jour sont réalisées dans un emplacement central et toutes les personnes utilisant une action personnalisée profitent du changement.

Reprenons cette architecture de pipeline de bas en haut, en commençant par le référentiel des outils de sécurité. Ce référentiel peut contenir des scripts qui définissent plusieurs fonctions. Par exemple, vous pourriez appeler un script PowerShell qui utilise l’API Snyk pour déterminer si un référentiel donné utilise la plateforme Snyk, et en cas de réponse négative, importer ce référentiel. À ce stade, divers scripts sont exécutés et le reste de l’architecture autorise l’héritage de ces scripts par un référentiel de travail donné.

Remontons maintenant d’un niveau. Le référentiel d’action personnalisée extrait le référentiel d’outils de sécurité et exécute un script spécifique à la sécurité. À l’aide d’actions composites, vous pouvez exécuter plusieurs commandes en une seule étape. Ce processus génère un niveau d’abstraction qui simplifie l’expérience utilisateur, mais vous permet aussi d’appeler plusieurs scripts et d’introduire des dépendances.

Ceci se déroule dans le fichier action.yml, avec lequel vous pouvez créer des versions sans avoir à déployer des modifications dans plusieurs référentiels de travail.

Au niveau supérieur, vous autorisez un référentiel de travail à voir l’action personnalisée GitHub. Lors de son initialisation, le workflow du référentiel de travail extrait le référentiel des actions personnalisées et en importe le contenu dans l’environnement d’exécution. En procédant à une nouvelle extraction imbriquée, vous pourrez utiliser le fichier action.yml et les scripts du référentiel des outils dans l’environnement d’exécution du référentiel de travail.

Du point de vue de l’utilisateur, vous avez introduit plusieurs scripts personnalisés, mais de manière « native ». Via les outils Snyk, vous avez pu sécuriser votre pipeline à l’aide d’actions GitHub. Si les actions GitHub peuvent intégrer des outils de sécurité dans un pipeline, les développeurs n’ont plus besoin de quitter leur espace de travail habituel (GitHub) pour obtenir les informations de sécurité en lien avec leur processus de développement. Vous avez ainsi créé en coulisses une boucle de rétroaction plus rapide, sans demander aux développeurs de procéder à des modifications à plusieurs endroits.

Tester l’automatisation pour améliorer les workflows

L’automatisation peut améliorer l’efficacité au sein de votre organisation. Ces présentations donnent deux exemples des avantages offerts par l’automatisation, mais il en existe bien d’autres. La plateforme de Snyk réunit de nombreux outils permettant d’automatiser vos workflows, mais aussi d’intégrer de manière fluide des normes de sécurité dans l’ensemble de votre processus de développement.