Ce que votre pipeline peut réellement vérifier (au-delà du simple scan de sécurité)

Quand la plupart des équipes commencent à ajouter des contrôles dans leur pipeline de déploiement, la première chose qui leur vient à l'esprit est le scan de sécurité du code applicatif. Lancer un outil SAST, trouver quelques vulnérabilités, et considérer le travail comme terminé. Mais si vous regardez ce qui circule réellement dans votre pipeline, il y a bien d'autres éléments à vérifier – et certains vous éviteront des problèmes que le seul scan de code ne peut pas détecter.

La livraison logicielle moderne ne transporte pas que du code source. Elle transporte aussi des listes de dépendances, des images conteneur, des définitions d'infrastructure, des fichiers de configuration et des identifiants. Chacun de ces artefacts comporte ses propres risques. Un pipeline qui ne scanne que le code applicatif laisse la majeure partie de la surface d'attaque sans surveillance.

Voici les types de vérifications que vous pouvez exécuter dans votre pipeline, ce qu'elles détectent et quand elles sont pertinentes.

Scan des dépendances

Presque aucune application n'est plus écrite entièrement de zéro. Votre projet importe des bibliothèques depuis npm, PyPI, Go modules, NuGet ou Maven. Chacune de ces dépendances est du code écrit par quelqu'un d'autre, et ce code peut contenir des vulnérabilités publiquement connues.

Le scan des dépendances vérifie votre liste de dépendances par rapport aux bases de données de vulnérabilités. Il vous indique si l'une de vos bibliothèques présente des problèmes de sécurité connus dans la version que vous utilisez. Il ne s'agit pas de trouver des failles zero-day, mais de détecter celles qui sont déjà documentées et pour lesquelles des correctifs sont souvent disponibles.

Exécutez ce scan chaque fois que votre fichier de dépendances change – package.json, go.mod, requirements.txt, ou tout autre fichier propre à votre écosystème. Au minimum, lancez-le une fois pendant la phase de build. Si vous ne l'exécutez que sur les pull requests, vous risquez de manquer une vulnérabilité introduite par une mise à jour de dépendance fusionnée directement sur la branche principale.

Voici un extrait YAML minimal pour un job GitHub Actions qui exécute npm audit et fait échouer le pipeline si une vulnérabilité de sévérité élevée est trouvée :

name: dependency-scan
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm audit --audit-level=high

Scan des images conteneur

Si vous empaquetez votre application sous forme d'image conteneur, cette image contient bien plus que votre code. Elle contient une image de base, une couche de système d'exploitation, des bibliothèques système et des binaires que vous n'avez pas écrits. Une vulnérabilité dans l'image de base affecte votre application tout autant qu'une vulnérabilité dans votre propre code.

Le scan des images conteneur examine l'intégralité du contenu de l'image, y compris les paquets système et les bibliothèques installées. Il détecte des choses comme une version vulnérable d'OpenSSL dans l'image de base ou une faille connue dans un utilitaire système que votre application n'appelle jamais directement mais qui est toujours présent dans l'environnement d'exécution.

Le moment idéal pour exécuter ce scan est juste après la construction de l'image, avant qu'elle ne soit poussée vers le registre ou déployée. Une fois l'image en production, la scanner reste utile pour la visibilité, mais les dégâts sont déjà possibles.

Scan de l'infrastructure as code

Quand vous écrivez de l'infrastructure as code avec Terraform, CloudFormation ou Pulumi, vous définissez des ressources cloud dans des fichiers texte. Ces fichiers peuvent contenir des mauvaises configurations qui ouvrent des failles de sécurité : des buckets de stockage accessibles publiquement, des bases de données exposées sur Internet, du chiffrement désactivé, ou des rôles IAM trop permissifs.

Le scan IaC vérifie vos définitions d'infrastructure par rapport aux bonnes pratiques de sécurité avant de les appliquer. Ce n'est pas un remplacement des outils de gestion de la posture de sécurité cloud qui scannent les environnements en cours d'exécution. C'est un contrôle préventif qui détecte les problèmes avant qu'ils ne deviennent des ressources déployées.

Exécutez ce scan lorsqu'une pull request modifie du code d'infrastructure. C'est à ce moment-là que vous pouvez encore corriger la configuration sans avoir à nettoyer une ressource mal configurée déjà en cours d'exécution.

Scan des secrets

Les développeurs commitent accidentellement des secrets dans les dépôts plus souvent que les équipes ne veulent l'admettre. Des clés API, des mots de passe de base de données, des clés privées SSH et des jetons de compte de service se retrouvent dans le code, les fichiers de configuration ou les messages de commit. Une fois qu'un secret est dans l'historique du dépôt, le supprimer est difficile car il vit dans l'historique git.

Le scan des secrets détecte les motifs qui ressemblent à des identifiants : des chaînes correspondant au format des clés d'accès AWS, des jetons GitHub, des webhooks Slack ou des mots de passe génériques. Il les signale avant que le commit n'atteigne la branche principale.

Ce scan est le plus efficace lorsqu'il est exécuté sur chaque commit ou au moins sur chaque pull request. Plus tôt vous détectez un secret divulgué, moins l'exposition est grande. Si vous ne scannez qu'après la fusion du code, le secret est déjà dans le dépôt et toute personne ayant accès a pu le récupérer.

Scan des licences

Chaque dépendance que vous utilisez est accompagnée d'une licence. Certaines licences exigent que vous incluiez une attribution. D'autres restreignent l'utilisation commerciale ou exigent que vous open-sourciez votre propre code si vous les utilisez. Le scan des licences vérifie les licences de toutes vos dépendances par rapport à la politique définie par votre équipe ou votre organisation.

Ce n'est pas un contrôle de sécurité, mais c'est un contrôle légal et de conformité qui peut bloquer une version s'il est ignoré. De nombreuses équipes exécutent le scan des licences en parallèle du scan des dépendances, car les deux utilisent la même source de données – votre liste de dépendances.

Policy as Code

La politique en tant que code n'est pas un type de scan unique. C'est une façon d'encoder des règles et de les appliquer de manière programmatique dans votre pipeline. Au lieu de vous appuyer sur un scanner pré-construit, vous définissez vos propres vérifications : "chaque modification de base de données doit être revue par un DBA", "chaque image conteneur doit provenir d'un registre approuvé", "chaque déploiement en production doit avoir un test de charge réussi".

Ces règles sont écrites sous forme de code et exécutées automatiquement dans le pipeline. Le Policy as Code vous offre la flexibilité d'appliquer ce qui est pertinent dans votre contexte, sans attendre qu'un fournisseur ajoute une fonctionnalité.

Choisir quoi exécuter et quand

Tous les contrôles n'ont pas besoin d'être exécutés à chaque étape. Certains sont suffisamment légers pour être exécutés à chaque commit. D'autres sont plus lents et ont plus de sens sur les pull requests ou avant le déploiement. L'essentiel n'est pas de tout exécuter partout, mais de placer chaque contrôle au point où il apporte le plus de valeur avec le moins de friction.

Voici un point de départ pratique :

• Chaque commit : scan des secrets, scan des dépendances (si le fichier de dépendances a changé)
• Pull request : scan IaC, scan des licences, scan des images conteneur (si l'image a été reconstruite)
• Avant le déploiement : scan des images conteneur (si pas déjà fait), contrôles Policy as Code

Une checklist rapide pour votre pipeline

• Le scan des dépendances s'exécute lorsque les fichiers de dépendances changent
• Les images conteneur sont scannées avant d'atteindre le registre
• Le code d'infrastructure est scanné avant d'être appliqué
• Les secrets sont détectés avant d'atteindre la branche principale
• La conformité des licences est vérifiée pour chaque dépendance
• Les politiques personnalisées sont appliquées en tant que code, pas comme des portes manuelles

L'essentiel à retenir

Un pipeline qui ne scanne que le code applicatif ne vérifie qu'une couche d'un processus de livraison multi-couche. Vos dépendances, conteneurs, définitions d'infrastructure et identifiants comportent tous des risques. Ajoutez des contrôles pour chaque type d'artefact au bon moment dans le pipeline. L'objectif n'est pas de bloquer chaque changement, mais de détecter les problèmes suffisamment tôt pour que leur correction reste peu coûteuse.