Couverture complète des scanners de sécurité en quelques minutes

Dans l'ensemble du secteur, toutes les plateformes CI/CD font face au même défi : à mesure que les organisations grandissent, configurer manuellement des scanners pour qu'ils s'exécutent sur chaque fichier de définition de pipeline n'est plus viable à grande échelle. L'IA accélère la vitesse à laquelle les équipes livrent du code, ce qui entraîne une augmentation du nombre de projets, de pipelines et de surface d'attaque à sécuriser. Ce qui commence comme une décision de sécurité délibérée devient une configuration héritée que personne ne possède, une couverture qui n'a jamais été comblée, et des failles invisibles jusqu'au moment où elles ne le sont plus.

Les équipes de sécurité ont besoin d'appliquer des scanners à grande échelle, et non de suivre la couverture des scanners projet par projet avec des fichiers YAML manuels. Un profil de configuration de sécurité est un paramètre centralisé dans l'interface utilisateur qui permet aux équipes de sécurité de définir comment et quand les scanners de sécurité s'exécutent dans vos projets, sans avoir à configurer manuellement les scanners dans les fichiers de définition de pipeline. Avec GitLab 19.0, les équipes peuvent utiliser des profils de configuration de sécurité pour activer les scanners de test statique de sécurité des applications (SAST), d'analyse des dépendances et de détection des secrets dans chaque projet dès le premier jour.

Consultez cette vidéo de démonstration des profils de configuration de sécurité, puis lisez la suite ci-dessous.

La configuration manuelle ne parvient pas à suivre le rythme effréné du développement de code piloté par l'IA

À petite échelle, activer manuellement la configuration des scanners par projet est gérable. Une équipe, quelques dépôts, un ingénieur sécurité qui sait où tout se trouve. Le modèle devient de plus en plus difficile à maintenir à mesure que les organisations ajoutent des équipes et des projets, et l'IA creuse chaque jour davantage l'écart entre la vitesse de développement du code et la couverture de sécurité.

Ce décalage se manifeste de manière récurrente. Les équipes copient la configuration des scanners depuis n'importe quelle source disponible, si bien que le scanner SAST finit par s'exécuter avec un ensemble de règles dans le service backend et un autre dans le frontend. L'analyse des dépendances est ajoutée aux nouveaux projets, mais n'est jamais rétroactivement appliquée aux anciens. Quelqu'un modifie un fichier .gitlab-ci.yml pour corriger un problème de pipeline, et un scanner est supprimé au passage.

Sans vue centralisée, les décisions individuelles concernant la couverture des scanners aboutissent rarement à une posture de sécurité cohérente à l'échelle de l'organisation.

Que sont les profils de configuration de sécurité ?

Un profil de configuration de sécurité est un ensemble centralisé de paramètres qui définit comment et quand un scanner de sécurité s'exécute dans vos projets. Au lieu de configurer le scanner SAST, la détection des secrets ou l'analyse des dépendances individuellement dans le fichier .gitlab-ci.yml de chaque projet, vous définissez un profil une seule fois au niveau du groupe et vous l'appliquez à autant de projets que nécessaire en une seule action.

GitLab fournit des profils par défaut pour chaque scanner : des paramètres préconfigurés qui reflètent les bonnes pratiques recommandées, afin que vous puissiez lancer le scan dans vos projets en quelques minutes sans écrire une seule ligne de YAML. Pour tous les détails techniques, consultez notre documentation sur les profils de configuration de sécurité.

Fonctionnement des profils : déclencheurs de scan et couverture

Chaque profil par défaut active un ensemble de déclencheurs de scan qui déterminent quand les scans sont exécutés. Pour les scanners SAST et l'analyse des dépendances, deux déclencheurs s'appliquent.

Pipelines de merge request. Un scan s'exécute automatiquement chaque fois que de nouveaux commits sont poussés vers une branche avec une merge request ouverte. Les résultats sont limités aux vulnérabilités introduites par cette merge request, ce qui permet aux équipes de développement d'obtenir un retour ciblé et actionnable, sans être perturbées par des problèmes préexistants.

Pipelines de branche (branche par défaut uniquement). Un scan s'exécute automatiquement lorsque des modifications sont fusionnées ou poussées vers la branche par défaut, offrant à votre équipe de sécurité une vue complète de la posture de sécurité de votre branche par défaut à tout moment.

La détection des secrets inclut ces deux déclencheurs et en ajoute un troisième : la protection des push. Plutôt que d'attendre l'exécution d'un pipeline, la protection des push intercepte les secrets en temps réel lors du processus git push et bloque le push avant que le secret n'entre dans votre code source. Comme elle est basée sur des événements plutôt que sur des pipelines, aucune date de scan ne lui est associée dans l'inventaire de sécurité.

Cas d'usage

Voici quatre scénarios concrets où les profils de configuration de sécurité peuvent avoir un impact significatif.

Standardiser la couverture dans un grand groupe
Une équipe de sécurité de plateforme gère des centaines de projets répartis dans des dizaines de sous-groupes. L'inventaire de sécurité leur offre une vue d'ensemble de la couverture des scanners pour chaque projet, notamment lesquels exécutent le scanner SAST, lesquels ne le font pas, et lesquels ont des scans en échec. Depuis ce tableau de bord, l'équipe sélectionne tous les projets et applique les profils par défaut en une action groupée. Chaque projet exécute désormais le scanner SAST, la détection des secrets et l'analyse des dépendances sur les pipelines de merge request et de branche, sans une seule modification du fichier .gitlab-ci.yml.

Détecter une vulnérabilité au niveau du code avant la mise en production
Un développeur faisant partie d'une équipe au rythme soutenue introduit un modèle de désérialisation non sécurisé lors de la création d'un nouveau point de terminaison d'API. Il ne s'agit pas d'une action malveillante, juste d'une erreur commise sous la pression. Avec le profil SAST appliqué, un scan s'exécute automatiquement lorsque l'équipe effectue un push des commits vers sa branche de merge request. La vulnérabilité est signalée avant l'approbation de la merge request, ce qui permet à un développeur de la corriger en une heure plutôt que de devoir passer plusieurs jours à gérer l'incident après coup.

Détecter une dépendance compromise avant qu'elle n'atteigne la production
Un développeur met à jour une dépendance dans son fichier de verrouillage. La nouvelle version d'un paquet largement utilisé a été compromise et contient une charge utile malveillante. L'analyse des dépendances s'exécute automatiquement sur le pipeline de merge request et signale la version compromise avant que la branche ne soit fusionnée. Le développeur est notifié au moment du changement, et non après que le paquet a été installé sur les serveurs de build et les environnements de production.

Détecter les secrets avant qu'ils ne soient intégrés
Un développeur inclut accidentellement une clé API dans un commit lors du débogage d'un problème de pipeline. C'est une erreur courante qui peut passer inaperçue pendant des jours dans une équipe très occupée. Avec le profil de détection des secrets appliqué, la protection des push intercepte le push en temps réel et le bloque avant que le secret n'atteigne le dépôt. Le développeur reçoit un retour immédiat au moment de l'erreur, sans rapport de sécurité, sans ticket d'incident et sans rotation des identifiants requise.

Premiers pas : de zéro à une couverture complète en quelques minutes

Les profils de configuration de sécurité sont désormais disponibles sur GitLab Ultimate pour les instances GitLab.com, GitLab Self-Managed et GitLab Dedicated. Pour appliquer les profils par défaut à l'ensemble de vos projets :

1. Accédez à Sécurisation > Inventaire de sécurité pour votre groupe.
2. Sélectionnez les projets que vous souhaitez couvrir, ou sélectionnez-les tous.
3. Dans le menu déroulant Action groupée, choisissez Gérer les scanners de sécurité.
4. Sélectionnez Appliquer le profil par défaut à tous.

Pour vérifier l'état de la couverture après l'application des profils, revenez à l'inventaire de sécurité et consultez la colonne Couverture des outils. Une barre verte pleine indique que le scanner est entièrement actif. Une barre partielle signifie que certains déclencheurs sont actifs mais pas d'autres. Une barre grise signifie que le scanner n'est pas encore configuré.

Pour afficher tous les détails techniques d'un profil, notamment ses déclencheurs de scan et son état actuel, sélectionnez le nom du profil dans l'inventaire de sécurité.

Si vos projets disposent d'une configuration de scanner existante dans le fichier .gitlab-ci.yml, notez que la configuration basée sur les profils et la configuration héritée peuvent coexister, mais l'info-bulle de l'inventaire de sécurité peut ne pas refléter avec précision le statut combiné pendant la transition. Pour obtenir la vue la plus précise de l'état actuel de votre profil, consultez la page Configuration de la sécurité du projet individuel. Pour en savoir plus, consultez notre documentation sur les profils de configuration de sécurité.

Vous souhaitez en savoir plus sur GitLab Ultimate ? Commencez un essai gratuit et lancez votre scanner SAST, la détection des secrets et l'analyse des dépendances dans vos projets en quelques minutes.

FAQ

Qu'est-ce qu'un profil de configuration de sécurité ?
Un profil de configuration de sécurité est un ensemble centralisé de paramètres qui définit comment et quand un scanner de sécurité s'exécute dans vos projets. Au lieu de configurer les scanners manuellement dans le fichier .gitlab-ci.yml de chaque projet, vous appliquez un profil une seule fois et il couvre chaque projet du groupe.

Quels scanners disposent de profils par défaut dans GitLab 19.0 ?
GitLab 19.0 complète le premier ensemble de profils par défaut, en ajoutant l'analyse des dépendances aux côtés du profil de détection des secrets (disponible depuis la version 18.9) et du profil SAST introduit dans la version 18.11. Chaque profil active un ensemble recommandé de déclencheurs de scan sans aucune configuration manuelle requise.

Quels déclencheurs de scan chaque profil active-t-il ?
Le profil de détection des secrets active trois déclencheurs : la protection des push, les pipelines de merge request et les pipelines de branche ciblant la branche par défaut. Les profils SAST et d'analyse des dépendances activent deux déclencheurs : les pipelines de merge request et les pipelines de branche ciblant la branche par défaut.

Les profils remplacent-ils ma configuration de scanner .gitlab-ci.yml existante ?
Pas automatiquement. Les configurations basées sur les profils et les configurations héritées peuvent coexister. Si vous souhaitez vous appuyer uniquement sur la configuration basée sur les profils, supprimez la configuration de scanner correspondante de vos fichiers .gitlab-ci.yml. La page Configuration de la sécurité de chaque projet reflète l'état actuel le plus précis lors de toute transition.

Quelle édition de GitLab est requise ?
Les profils de configuration de sécurité sont disponibles sur GitLab Ultimate, pour les instances GitLab.com, GitLab Self-Managed et GitLab Dedicated.

Puis-je appliquer un profil à des projets individuels plutôt qu'à un groupe entier ?
Oui. Depuis l'inventaire de sécurité, vous pouvez gérer la couverture des scanners pour des projets individuels en sélectionnant les points de suspension verticaux à côté du projet et en choisissant Gérer la couverture des outils.

En savoir plus sur les nouveautés de GitLab 19.0

• Gérez vos identifiants CI/CD avec GitLab Secrets Manager
• Transformez les merge requests de tâches manuelles en workflow automatisé
• Suivez l'utilisation des composants CI dans votre organisation
• Plus de modèles d'IA pour GitLab Duo Agent Platform Self-Hosted