Actualites

GitLab renforce (lui aussi) ses capacités de détection de vulnérabilités

Après l’annonce de la version 13.0 de sa plateforme CI/CD, GitLab veut encore améliorer ses fonctionnalités de détection de vulnérabilités. Pour cela, il rachète deux sociétés : PeachTech et Fuzzit.

Gaétan Raoul
par
Publié le: 12 juin 2020

Gitlab a annoncé la version 13.0 de sa plateforme de gestion de code. Habitué aux mises à jour mensuelles, l’éditeur a déjà optimisé quelques éléments dans un correctif, mais l’essentiel ne change pas. Il veut renforcer l’empreinte de sa plateforme SCM en améliorant sa disponibilité, la détection des vulnérabilités et la gestion des projets.

Ainsi, à l’instar de son concurrent GitHub, il optimise la fonctionnalité de scans DAST (Dynamic application security testing) pour les API REST, et la détection de secrets se fait maintenant sur l’ensemble de l’historique du dépôt de code. La fonctionnalité SAST est, elle, compatible avec le framework .NET. Par ailleurs, Gitlab apporte des modifications significatives à son modèle objet de vulnérabilité.

Auparavant, un nouveau scan effaçait le rapport concernant les failles. Sans une gestion externe des vulnérabilités, il était difficile de garder la trace de ce qui avait été corrigé ou non. Depuis la version 13.0, chaque vulnérabilité est associée à un lien URL. Sur la page Web correspondante, il est possible d’éditer le statut de cette erreur (détectée, confirmée, rejetée ou résolue). Par ailleurs, l’éditeur a ajouté une fonctionnalité d’export de rapport d’erreurs au format CSV pour les DevSecOps ou les responsables de la sécurité. De même, ceux-ci peuvent observer les apports de chaque développeur avec l’ajout de caractéristiques dans les logs d’audit. L’onglet associé ajoute des filtres pour faciliter la recherche.

GitLab renforce également les intégrations avec les outils de scans tiers en proposant aux utilisateurs et aux éditeurs une guideline pour le faire. Par exemple, l’outil d’analyse de dépendances Whitesource peut être directement embarqué au sein d’un dépôt et de la chaîne CI/CD. Il doit analyser les bibliothèques associées à un grand nombre de langages de programmation.

« Ils [Whitesource] ont une portée plus limitée que ce que nous pouvons offrir, mais ils vont plus loin dans un domaine particulier et c’est en quelque sorte ce sur quoi s’appuie notre stratégie de partenariats. Nous donnons la priorité aux partenaires qui nous aident à combler certaines lacunes [de notre produit] », déclare Cindy Blake, Senior Security Evangelist chez GitLab.

Fuzzing : PeachTech et Fuzzit rejoignent GitLab

Cette volonté d’améliorer les tests contre les vulnérabilités, GitLab la matérialise également par deux rachats dévoilés le 11 juin : PeachTech et Fuzzit. Ces deux acteurs sont spécialisés dans le fuzzing (l’injection de données aléatoires dans un programme pour en détecter les erreurs). Gitlab propose déjà une fonctionnalité similaire, mais souhaite gonfler ses capacités pour apporter le niveau de maturité attendu par les développeurs. Les outils des deux éditeurs vont rejoindre la plateforme CI/CD dès juillet.

« Ces deux rachats nous permettront d’améliorer considérablement nos capacités d’analyse dynamique liées au fuzzing. Nous nous dotons ainsi de capacités d’analyse structurelle et comportementale que nous allons embarquer dans GitLab de manière transparente », explique Cindy Blake.

La chasse aux vulnérabilités n’est pas la seule priorité des développeurs et des entreprises qui utilisent GitLab. Ils veulent simplifier le déploiement, la maintenance et la gestion de leurs dépôts GitLab.

Concernant la haute disponibilité, GitLab veut démocratiser une solution qu’il avait déjà mise en place au sein de GitLab.com, son offre cloud. Gitaly est le projet open source qui permet à l’éditeur de faire de la réplication chaude dans des clusters. Maintenant, GitLab utilise un répartiteur de charge et du clustering actif-actif pour éviter les pannes, mais aussi assurer la montée à l’échelle. « Cela permet d’avoir un système de fichiers natif sans avoir à faire appel à un autre système compliqué à maintenir comme NFS (Network File System) tout en maintenant automatiquement plusieurs destinations de dépôts », assure Brendan O’Leary, Senior Developer Evangelist, chez GitLab.

Cependant, cette architecture n’était pas disponible pour les utilisateurs qui hébergent eux-mêmes GitLab. « Cette fonctionnalité s’adresse aux clients qui veulent gérer leurs propres serveurs, ce qui représente une grande partie de notre base d’utilisateurs », confirme Brendan O’Leary.

Dans la même veine, Auto DevOps, la fonctionnalité de déploiement automatisée de configurations CI/CD a été optimisée pour les déploiements sur Amazon ECS.

Gitlab annonce aussi une intégration « avancée » avec Hashicorp Terraform. Tout simplement, les commandes liées au système IaC sont nativement visibles depuis les requêtes de merge. Il suffit de cliquer sur le lien associé pour voir le code. Habituellement, les changements appliqués à « Terraform plan » sont beaucoup moins accessibles. Par ailleurs, la fonctionnalité « http state backend » doit réduire le temps de configuration en automatisant l’allocation d’emplacement du fichier main.tf à un espace de stockage. Par ailleurs, l’éditeur encourage les utilisateurs à utiliser Hashicorp Vault pour protéger les secrets au sein de leurs Git.

Des projets d’amélioration inspirés par le lean manufacturing

Dans sa volonté de créer une plateforme DevOps, l’éditeur mise sur l’amélioration des fonctionnalités d’A/B testing en s’appuyant sur le feature flagging. Cette fonctionnalité en bêta permet entre autres d’activer ou de désactiver automatiquement des lignes de code suivant des règles préétablies. Par exemple, deux versions d’une même page web pourraient cohabiter et des métriques remontées depuis GitLab pourraient indiquer quelle version est techniquement plus pertinente. L’une des versions serait alors désactivée en conséquence.

GitLab veut également renforcer les fonctionnalités d’analyse de chaîne de valeur, principe dérivé du value stream mapping issu des méthodes de lean manufacturing. Là encore, les administrateurs pourront bénéficier de moyens pour visualiser les tâches accomplies, comptabiliser les erreurs, les commits ou encore le nombre de déploiements.

Les épopées (des corpus de tâches subdivisés en sous-tâches) sont souvent difficiles à retracer. L’outil RoadMap bénéficie désormais d’un système pour voir la filiation entre chaque tâche. Les petites améliorations associées doivent favoriser la collaboration entre les développeurs.

« Nous voulons proposer une seule plateforme DevOps qui rassemble l’ensemble des fonctionnalités, pour gérer le cycle de vie de vos applications » vante Brendan O’Leary. « Ajouter des moyens de visualisation pour identifier le niveau d’efficacité de vos processus nous semble essentiel ».

Pour approfondir sur Open Source