DevSecOps : les responsables IT ne veulent plus naviguer à vue
La cybersécurité ne s’améliorera pas si les régulateurs et les experts du secteur ne donnent pas de conseils plus clairs sur la manière de mettre en œuvre l’approche DevSecOps, selon les discussions qui ont eu lieu lors du GitLab Commit 2021.
L’approche DevSecOps ne décollera pas sans une orientation plus spécifique de la part des experts du secteur et des régulateurs, selon les propos des professionnels IT s’étant exprimés lors de l’événement GitLab Commit 2021 la semaine dernière.
Cette pratique, consistant à bâtir des applications sécurisées en faisant contribuer des développeurs, des ingénieurs en cybersécurité et des équipes responsables de l’exploitation, représente un idéal pour la plupart des entreprises. Et pourtant, plus les choses évoluent dans le domaine de la cybersécurité, plus elles restent les mêmes.
Prenons l’exemple des fuites de secrets. Depuis dix ans, les experts de la sécurité prêchent que les développeurs ne doivent pas stocker de secrets – des informations sensibles telles que des mots de passe et autres identifiants – dans le code source. Toutefois, dans le cadre d’une enquête présentée lors de l’événement virtuel, l’éditeur GitGuardian a trouvé 2 millions de secrets stockés dans les dépôts Git publics rien qu’en 2020.
« Une grande partie du problème se résume à des erreurs humaines et à une mauvaise compréhension des dangers de Git. »
Mackenzie JacksonDéfenseur des développeurs, GitGuardian
« Une grande partie du problème se résume à des erreurs humaines et à une mauvaise compréhension des dangers de Git », commente Mackenzie Jackson, défenseur des développeurs chez GitGuardian, lors d’une séance de questions-réponses en ligne après sa conférence.
Le stockage et la gestion de secrets dans Git demeurent des pratiques courantes chez les programmeurs, car leurs dépôts sont privés, sans tenir compte du fait qu’ils peuvent, un jour ou l’autre, être rendus publics, par exemple lors de la donation de code à une instance open source.
Il est également facile de rendre accidentellement public du code qui est censé être privé, note Mackenzie Jackson. Souvent, les développeurs emploient les mêmes noms d’utilisateur Git pour leurs projets personnels et professionnels et peuvent confondre les deux.
Autre problème courant, des versions antérieures du code s’attardent dans les dépôts Git – ce dont beaucoup de développeurs ne sont pas conscients, selon Mackenzie Jackson. Des secrets peuvent également se cacher dans les logs et différents fichiers générés automatiquement.
Enfin, même si les développeurs savent ce qu’il ne faut pas faire, ils ne savent pas toujours ce qu’ils devraient faire à la place, remarque un participant à la présentation de M. Jackson.
« Les articles de blog, les didacticiels, les guides… indiquent tous qu’il ne faut jamais divulguer ses secrets [dans le code] », déclare le participant. « Mais ils ne vous disent presque jamais où mettre réellement ces secrets ».
Mckenzie Jackson a partagé un lien vers un article de blog de GitGuardian sur la façon dont les développeurs peuvent gérer correctement les secrets. Dans une interview, il affirme que le succès de ce document montre à quel point le problème est courant.
« Il a généré plus de trafic en deux jours que pendant tout le reste de l’année, ce qui prouve qu’il n’y a pas assez d’informations à ce sujet », affirme-t-il.
Nous sommes tous dans le même bateau
Selon d’autres intervenants lors de GitLab Commit, la gestion des secrets n’est pas le seul domaine lié à l’approche DevSecOps qui souffre d’un manque de consensus dans l’industrie. Par exemple, la liste des dix principales vulnérabilités des applications Web (OWASP 10) établie par l’Open Web Application Security Project n’a pas changé de façon radicale au cours des 17 dernières années.
« Ce n’est pas un problème de technologie. Il faut des personnes informées, et faire preuve d’innovation en matière de processus. »
Caroline WongStratège en chef de la sécurité, Cobalt.io
Par ailleurs, les erreurs de configuration ont été la principale cause des problèmes de sécurité au cours des quatre dernières années, selon un rapport annuel réalisé par le fournisseur de services Cobalt.io, consacré aux tests de pénétration et présenté lors de l’événement GitLab.
« La sécurité n’est pas quelque chose que nous pouvons penser dans le vide », lance Caroline Wong, stratège en chef de la sécurité chez Cobalt.io, lors sa conférence. « Ce n’est pas un problème de technologie. Il faut des personnes informées et faire preuve d’innovation en matière de processus. »
« Que se passe-t-il lorsque des vaccins efficaces sont créés ? Les questions techniques sont résolues, mais le problème disparaît-il pour autant ? Bien sûr que non », tranche-t-elle. « D’une certaine manière, il pourrait être plus facile de développer un vaccin complètement nouveau que de faire l’approvisionnement, la distribution et la communication et de faire réellement vacciner les gens. »
Tout comme certains législateurs proposent aujourd’hui des moyens pour rendre le vaccin contre la COVID obligatoire, certains leaders du secteur IT affirment que l’approche DevSecOps a besoin d’une mise en application plus stricte.
Bon nombre des principaux cadres et réglementations en matière de cybersécurité, tels que la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS), ne spécifient pas les meilleures pratiques en matière de développement de code sécurisé – ils disent seulement que cela doit être fait, selon Johnathan Hunt, vice-président de la sécurité des informations chez GitLab.
« Nous avons essayé la créativité et la flexibilité pendant des années », constate-t-il lors de son intervention. « Mais si ce n’est qu’une suggestion, alors cela ressemble plus à un passe-temps – cela entre en compétition avec vos autres tâches… et le développement de logiciels sécurisés devient subjectif. »
Des organisations telles que le National Institute for Standards and Technology (NIST), les régulateurs et les experts de l’industrie technologique devraient se réunir pour codifier les meilleures pratiques spécifiques pour l’approche DevSecOps et exiger qu’elles soient suivies, affirme Johnathan Hunt dans une interview séparée auprès de SearchITOperations [propriété de Techtarget, également propriétaire du MagIT].
« Difficulté parmi d’autres, les outils ne sont pas configurés et utilisés correctement », ajoute-t-il. « Donc, avant tout, nous devons nous mettre d’accord sur ce qu’est une configuration appropriée ».
DevSecOps : travaux en cours chez GitLab
Même si GitLab se veut l’éditeur de LA Plateforme DevOps, capable de supporter tous les besoins des DevOps, la gestion des secrets n’est pas de son ressort. Pour le moment, il propose des intégrations avec les outils du marché, principalement Hashicorp Vault. Encore faut-il maîtriser l’implémentation de ces coffres, la rotation des clés ainsi que des protocoles et certificats associés.
Non, GitLab se concentre sur l’analyse des vulnérabilités connues, par le biais de l’intégration du moteur de scans Trivy dans la version 14.0, et inconnues par l’introduction de Package Hunter. Il s’agit d’un outil conçu pour chasser le code malicieux dans les dépendances, généralement des bibliothèques open source externe, utilisées par les développeurs. Il repose sur le moteur de détection de menaces open source Falco, originellement développé par Sysdig et donné à la CNCF, et s’exécute comme un runtime au niveau des pipelines CI.
Selon les ingénieurs de GitLab, Package Hunter se différencie des outils comme Dependabot ou ceux de Snyk. « Les scanners existants ne détectent généralement pas si une dépendance exécute un code malveillant, car ces outils se limitent à identifier les dépendances présentant des vulnérabilités connues », écrit Dennis Appelt, ingénieur et chercheur en sécurité chez GitLab.
Pour cela, il faut installer les dépendances dans un environnement sandbox et superviser les appels système exécutés pendant ce processus. L’outil signale tout appel suspect à l’utilisateur via un objet JSON. GitLab est avare en détail sur les informations remontées par Package Hunter. Si l’on se fie à la documentation de Falco, les règles peuvent être liées à la détection du changement de privilège, l’exécution de binaires Shell et SSH, des mots de passe, des noms de fichiers ou encore de connexion réseau « en mutation ».
Pour l’instant, Package Hunter ne supporte que les paquets Node.js et Ruby Gems. GitLab s’en servirait depuis novembre 2020, mais il ne conseille pas de l’utiliser en production.
Par ailleurs, GitLab invite les organisations à employer une nouvelle règle qui empêche la merge request si la couverture de tests n’est pas suffisante. « Auparavant, le seul moyen de faire respecter cette règle était d’exiger l’approbation des utilisateurs qui vérifiaient la diminution de la couverture de test dans le cadre de leurs révisions », note l’éditeur.
De plus, les administrateurs peuvent gérer les permissions liées au token d’accès à un projet. Seuls les usagers gratuits de GitLab SaaS ne peuvent sélectionner et afficher les rôles de cette manière pour « éviter les abus ».
Équilibrer spécificité et flexibilité
Les clients de GitLab qui ont participé à l’événement sont largement d’accord : des exigences réglementaires plus spécifiques contribueraient à favoriser les pratiques DevSecOps – mais seulement si une certaine flexibilité subsiste.
« L’idéal serait d’avoir de multiples exemples de critères acceptables. »
Timothy St. HilaireResponsable développement applications IT, BAE Systems Inc.
« Tout ce que nous pouvons faire pour nous améliorer dans ce domaine sera formidable », déclare Doug Rickert, responsable principal de la sécurité des produits chez Here Technologies, un éditeur de solutions de localisation et de cartographie hollandaises. « Je m’inquiète cependant de l’équilibre à trouver pour partager toutes ces informations, tout en échangeant nos analyses. Par exemple, si une version spécifique d’une bibliothèque logicielle est censée présenter une vulnérabilité, mais que nous avons effectué des tests et sommes certains de ne pas la retrouver dans nos paquets, quelle sera l’ampleur de la réaction des clients qui verront seulement la bibliothèque et la version vulnérable ? »
Dans les industries hautement réglementées, il y a une tendance à prendre les choses au pied de la lettre, constate Timothy St. Hilaire, responsable du développement des applications IT chez BAE Systems Inc. une entreprise internationale spécialisée dans la défense, la sécurité et l’aérospatiale basée à Arlington, en Virginie.
« Si l’on suggérait simplement que tous les développeurs devaient porter des chemises bleues, les chemises bleues seraient exigées à tout moment », s’amuse-t-il. « Toute prescription serait poussée à l’extrême. (…) L’idéal serait d’avoir de multiples exemples de critères acceptables. »
Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)
