Sécuriser le code sans YAML : comment GitLab passe l'analyse à l'échelle

À mesure qu'une organisation grandit, configurer à la main les scanners de sécurité de chaque projet devient ingérable. GitLab 19.0 apporte une réponse : les profils de configuration de sécurité. Ils permettent d'activer le SAST, l'analyse des dépendances et la détection de secrets en un clic, sur tous les projets simultanément, sans avoir à modifier de fichiers YAML.

Pourquoi la configuration manuelle ne passe pas à l'échelle

Au départ, la configuration manuelle fonctionne correctement : une équipe, quelques dépôts, un security engineer qui connaît tout par cœur. Mais quand le nombre d'équipes et de projets augmente, le modèle commence à s'effondrer. L'AI accélère le rythme du développement, et la couverture de sécurité décroche encore plus vite.

Les problèmes sont classiques et douloureux. Les équipes copient la configuration d'analyse depuis n'importe où : le SAST d'un service backend tourne avec un jeu de règles, celui du frontend avec un tout autre. On ajoute l'analyse des dépendances aux nouveaux projets, mais on oublie les anciens. Quelqu'un modifie le .gitlab-ci.yml pour corriger une erreur de pipeline et supprime par accident un scanner de sécurité — personne ne s'en aperçoit avant l'incident.

Sans gestion centralisée, impossible de vérifier que tous les projets appliquent la même politique de sécurité. La security team doit contrôler chaque projet à la main et courir après les configurations, au lieu de se concentrer sur l'analyse des vraies vulnérabilités.

Que sont les profils de configuration ?

Un profil de configuration est un ensemble de règles et de déclencheurs qui définissent comment et quand les scanners de sécurité s'exécutent. Plutôt que de configurer à la main le .gitlab-ci.yml de chaque projet, vous créez le profil une seule fois au niveau du groupe et l'appliquez à tous les projets en une seule action.

GitLab fournit des profils prêts à l'emploi pour trois types de scanners :

• SAST (Static Application Security Testing) — recherche de vulnérabilités dans le code source de l'application
• Analyse des dépendances — détection de vulnérabilités dans les bibliothèques et paquets utilisés
• Détection de secrets — interception des clés d'API, mots de passe et tokens avant qu'ils n'atterrissent dans le dépôt

Chaque profil contient des réglages éprouvés et recommandés, conformes aux bonnes pratiques du secteur. Concrètement, on peut activer une analyse de sécurité complète en quelques minutes, sans écrire une seule ligne de YAML et sans connaissance approfondie de chaque scanner.

Comment fonctionnent les déclencheurs d'analyse ?

L'analyse se lance automatiquement dans trois scénarios.

Premier scénario : la création d'une merge request. Le scanner n'affiche que les nouvelles vulnérabilités introduites par ce code. Le développeur se concentre ainsi sur ses propres erreurs, sans être distrait par d'anciens problèmes antérieurs à sa pull request.

Deuxième scénario : le merge des modifications dans la branche principale. La security team obtient alors une vue complète de l'état de sécurité de toute la base de code et peut suivre les progrès réalisés.

Troisième scénario : la détection de secrets fonctionne en temps réel. Si un développeur tente de pousser une clé d'API ou un mot de passe, le push est bloqué directement au niveau de git, avant que le secret n'entre dans le dépôt et l'historique des commits. On évite ainsi que des secrets se retrouvent dans un historique public et imposent une rotation coûteuse.

De zéro à une couverture complète en quelques clics

Pour démarrer, la security team ouvre la section Security inventory de son groupe, sélectionne tous les projets (ou seulement certains) et applique les profils par défaut via le menu Bulk Actions.

GitLab affiche immédiatement l'état de la couverture : une barre verte indique que le scanner est pleinement actif, une barre partielle que tous les déclencheurs ne fonctionnent pas, une barre grise que le scanner n'est pas encore configuré.

Les profils prêts à l'emploi s'activent immédiatement. La première analyse se lancera à la prochaine merge request ou au prochain push sur la branche principale.

Ce que cela signifie

Les organisations n'ont plus à choisir entre vitesse de développement et sécurité. Les profils de configuration permettent de faire passer les deux à l'échelle en même temps : les équipes déploient du nouveau code plus vite, avec la garantie que tous les projets passent le même ensemble de contrôles de sécurité critiques. C'est particulièrement important dans les grandes organisations, où le développement avance en parallèle sur des dizaines, voire des centaines de projets.