Dependency Firewall : bloquez les paquets à risque avant le build

Des paquets malveillants peuvent apparaître dans les registres publics dont dépendent vos builds. De plus en plus souvent, ce ne sont plus les développeurs qui choisissent ce qui est intégré, car les agents de codage alimentés par l'IA ajoutent désormais des dépendances open source de manière autonome, souvent sans que personne ne vérifie ni même ne voie ce qui a été intégré au build.

Cette situation signifie qu'un paquet malveillant ou vulnérable peut s'introduire dans votre build sans que personne n'ait décidé de l'autoriser. Une fois en place, son code peut s'exécuter au sein de votre build avec les mêmes accès que votre pipeline, et peut ainsi atteindre n'importe quel système auquel vos pipelines de développement ont accès.

GitLab Dependency Firewall, présenté aujourd'hui lors de notre événement GitLab Transcend et disponible en accès anticipé, permet de bloquer les paquets qui ne respectent pas votre politique, notamment les paquets malveillants, vulnérables et non conformes, avant qu'ils n'atteignent votre build. Grâce à la gouvernance intégrée, le temps nécessaire à l'identification et à la correction des vulnérabilités passe de plusieurs semaines à quelques minutes. Les équipes de développement et leurs agents peuvent continuer à récupérer les dépendances dont ils ont besoin sans attendre une revue de sécurité manuelle, et les paquets satisfaisant vos exigences de politique sont intégrés à votre build officiel.

Regardez le replay de GitLab Transcend dès maintenant ! Découvrez les démonstrations des nouvelles fonctionnalités de la plateforme et comment tirer parti de la rapidité de l'IA agentique tout au long du cycle de vie logiciel.

Bloquez les paquets malveillants sans interrompre votre build

En l'absence de politique au moment de l'installation, un paquet malveillant est d'abord intégré au build et n'est détecté qu'ultérieurement. L'analyse de la composition logicielle (SCA) examine les éléments que vous avez déjà récupérés. Ainsi, lorsqu'elle signale un paquet malveillant, une vulnérabilité de gravité élevée ou une licence que votre équipe juridique ne peut accepter, la dépendance est déjà installée et peut avoir été intégrée dans un artefact. Retracer son parcours, la supprimer et reconstruire transforme une exécution de pipeline ordinaire en une tâche non planifiée pour votre équipe d'ingénierie.

Avec Dependency Firewall, vous décidez ce qui est autorisé dans vos builds avant même l'installation, en définissant des politiques pour :

1. Statut malveillant — les paquets signalés dans la base de données d'alertes sur les logiciels malveillants de GitLab
2. Gravité des vulnérabilités — le niveau de gravité que vous définissez (critique, élevé, moyen ou faible) et le nombre de résultats que vous autorisez à ce niveau, y compris zéro
3. Type de licence — les licences que vous autorisez ou refusez, répertoriées par nom complet, et la manière de traiter les paquets dont la licence ne peut pas être déterminée
4. Ancienneté du paquet — l'ancienneté minimum qu'un paquet doit atteindre avant de pouvoir être intégré à un build, afin qu'une version publiée il y a quelques minutes ne puisse pas être intégrée directement avant vérification

La mise en place progressive de l'application des règles ne doit pas nécessairement compromettre la livraison. Commencez en mode avertissement, dans lequel le pare-feu enregistre ce qu'une politique détecterait, mais laisse le build se poursuivre. Il génère un événement d'audit, une entrée dans le tableau de bord et une ligne dans le résumé CI, afin que vous puissiez analyser s'il convient ou non de bloquer le build.

Une fois que vous avez confiance dans les politiques, passez en mode blocage, qui interrompt le pipeline en cas de correspondance et en indique la raison. Lorsqu'un utilisateur a réellement besoin de faire passer un paquet approuvé, un contournement journalisé permet à un utilisateur ou à un token désigné de procéder, avec traçabilité.

Définissez une politique unique ou adaptez-la par équipe

Un pare-feu qui s'applique uniquement au niveau du registre impose la même politique à tous, mais cela correspond rarement à la manière dont les équipes travaillent réellement. Un service de paiement et un prototype interne présentent des profils de risque très différents, et un ensemble de règles unique à l'échelle du registre ne peut pas imposer des exigences plus strictes à l'un qu'à l'autre.

Avec Dependency Firewall, vous définissez une politique au niveau du groupe principal et tous les projets qui lui sont subordonnés héritent des mêmes règles. Lorsqu'une équipe a besoin d'une configuration différente, vous pouvez définir une politique spécifique pour ce groupe ou ce projet. Vous pouvez l'appliquer au niveau du registre et gérer l'ensemble de l'organisation depuis une seule plateforme, sans renoncer à la possibilité de renforcer les règles là où le risque est plus élevé.

Les règles sont stockées sous forme de code dans un projet de politique de sécurité, et sont donc examinées et modifiées via une merge request comme le reste de votre configuration. Elles héritent du groupe principal jusqu'à chaque projet, et en cas de chevauchement entre plusieurs règles, c'est la plus stricte qui s'applique. Un service critique peut être soumis à des exigences supérieures au niveau de référence de l'organisation, et aucun projet ne peut descendre en dessous de ce niveau.

Vérifiez un paquet avant de l'intégrer

En général, un développeur ou un agent agissant en son nom ne découvre qu'un paquet n'est pas autorisé qu'au moment où le pipeline échoue. Cela coûte un cycle de build et interrompt la concentration des équipes, précisément au moment où le travail avance.

Avec GitLab Dependency Firewall, vous obtenez une réponse avant même d'ajouter une dépendance, directement dans l'environnement où vous travaillez déjà, ce qui vous permet de choisir d'emblée un paquet conforme.

En utilisant GitLab CLI dans le terminal ou dans un script, une vérification en ligne de commande permet de déterminer si un paquet sera accepté ou bloqué par votre politique, sans que les équipes de développement aient à ouvrir une console distincte. Cette fonctionnalité prend en charge les gestionnaires de paquets courants tels que npm, pip, Poetry, Maven, Gradle et Bundler, et d'autres seront ajoutés prochainement.

Visualisez et justifiez chaque décision

Un responsable sécurité doit être en mesure de prouver ce qu'un contrôle accomplit lors d'un audit. Un contrôle qui bloque silencieusement, sans laisser de trace, ne répond pas à la question de l'auditeur et ne renforce pas la confiance des équipes qu'il gouverne.

Vous disposez d'une vue d'ensemble de ce que le pare-feu a autorisé, signalé et bloqué, avec un historique de chaque décision que vous pouvez remettre à un auditeur.

Un tableau de bord Dependency Firewall affiche l'activité et les résultats pour les projets concernés. Chaque avertissement, blocage et contournement génère un événement d'audit qui consigne la règle correspondante, la politique sous-jacente et le paquet concerné.

Demandez un accès anticipé à GitLab Dependency Firewall

Vous pouvez bloquer les paquets malveillants, vulnérables et non conformes avant qu'ils n'atteignent le build. GitLab Dependency Firewall est compatible avec GitLab Artifact Central et les registres externes de Sonatype Nexus Repository et JFrog Artifactory, et ne nécessite pas la mise en place d'un outil distinct en plus de votre installation GitLab. Dependency Firewall est désormais disponible en accès anticipé pour les clients GitLab.com et GitLab Self-Managed des niveaux GitLab Premium ou GitLab Ultimate. Demandez l'accès anticipé dès aujourd'hui !