Pourquoi votre pipeline doit vérifier la sécurité et la conformité

Lorsque votre équipe met en place un pipeline CI/CD pour la première fois, les vérifications ajoutées sont généralement les plus évidentes sur le plan technique : le code compile-t-il, les tests unitaires passent-ils, l'application démarre-t-elle. C'est logique. À ce stade, les problèmes les plus ressentis sont le code qui casse et les fonctionnalités qui ne marchent pas.

Mais dès que de vrais utilisateurs commencent à utiliser votre application, de nouvelles questions apparaissent. Ce code a-t-il une faille de sécurité ? Cette bibliothèque a-t-elle une vulnérabilité connue ? La configuration du serveur respecte-t-elle la politique de l'entreprise ? Quelqu'un a-t-il accidentellement commité un mot de passe ?

La plupart des équipes répondent à ces questions manuellement. Une équipe de sécurité effectue des audits périodiques. Quelqu'un remplit une liste de contrôle de conformité avant chaque mise en production. Cette approche manuelle pose trois problèmes.

Premièrement, les vérifications ont lieu après que le code est terminé, parfois même après qu'il est déjà en production. Lorsque vous trouvez un problème, le corriger implique des allers-retours entre l'équipe de développement et l'équipe de sécurité. C'est coûteux et lent.

Deuxièmement, les vérifications manuelles sont incohérentes. La même personne peut passer à côté de choses différentes selon les jours. Deux personnes peuvent interpréter la même règle différemment.

Troisièmement, les processus manuels ne peuvent pas suivre le rythme lorsque votre équipe déploie plusieurs fois par jour. Le goulot d'étranglement passe de l'écriture du code à l'attente des approbations et des listes de contrôle.

Le pipeline comme gardien automatisé

C'est pourquoi les contrôles de sécurité et de conformité doivent vivre dans votre pipeline. L'idée est simple : à chaque fois que quelqu'un pousse une modification, le pipeline exécute les mêmes vérifications, de la même manière, et donne des résultats cohérents.

S'il y a une vulnérabilité de sécurité, le pipeline vous le dit avant que le code n'atteigne la production. Si une configuration viole la politique de l'entreprise, le pipeline arrête le processus avant que le problème ne se propage.

Il ne s'agit pas de remplacer votre équipe de sécurité. Il s'agit de détecter automatiquement les problèmes évidents afin que l'équipe de sécurité puisse se concentrer sur les questions plus complexes qui nécessitent un jugement humain.

La préoccupation de la vitesse

De nombreuses équipes craignent que l'ajout de contrôles de sécurité ne ralentisse le pipeline. Cette préoccupation est valable, mais le problème ne vient pas des contrôles eux-mêmes. Le problème est d'exécuter tous les contrôles sur chaque commit sans réfléchir à ceux qui sont importants à quel moment.

Exécuter une analyse complète des vulnérabilités des dépendances qui prend quinze minutes sur chaque commit frustrera certainement vos développeurs. Mais exécuter cette même analyse lourde une fois par jour, ou seulement avant de fusionner dans la branche principale, a un impact minimal sur la vélocité des développeurs.

La clé est de séparer les vérifications rapides des vérifications lentes.

Les vérifications rapides s'effectuent en quelques secondes. La recherche de secrets accidentellement commités dans le dépôt ne prend presque pas de temps. Vérifier que les licences des bibliothèques sont acceptables est tout aussi rapide. Ces vérifications doivent être exécutées sur chaque commit. Elles détectent les problèmes tôt, et elles sont suffisamment légères pour que personne ne remarque le délai.

Les vérifications lentes prennent des minutes ou plus. L'analyse des dépendances par rapport à une base de données de vulnérabilités nécessite de télécharger et de comparer des données. L'analyse des images conteneur pour les CVE connus implique d'analyser les couches et les paquets installés. Ces vérifications sont précieuses, mais elles n'ont pas besoin d'être exécutées à chaque push de code. Exécutez-les lorsque quelqu'un ouvre une pull request, ou avant de déployer dans un environnement de staging.

À quoi ressemblent concrètement les contrôles de sécurité dans un pipeline

Rendons cela concret. Voici les catégories courantes de contrôles de sécurité et de conformité qui ont leur place dans un pipeline :

Analyse des secrets. Des outils qui détectent les clés API, mots de passe, jetons et certificats commités dans le dépôt. Ils sont rapides et doivent être exécutés sur chaque commit. Si quelqu'un pousse accidentellement un identifiant, vous devez le savoir immédiatement, pas après que le code soit en production.

Analyse des dépendances. Des vérifications qui comparent les dépendances de votre projet avec des bases de données de vulnérabilités connues. Elles vous indiquent si une bibliothèque que vous utilisez a un CVE publié. Exécutez-les sur les pull requests et avant les déploiements en production.

Tests statiques de sécurité des applications (SAST). Des outils qui analysent votre code source à la recherche de motifs de sécurité sans exécuter le code. Ils recherchent les risques d'injection SQL, les vulnérabilités de cross-site scripting, les fonctions cryptographiques non sécurisées, et autres problèmes similaires. Les outils SAST varient en vitesse, mais beaucoup peuvent s'exécuter en une minute ou deux sur des bases de code de taille raisonnable.

Analyse des images conteneur. Si vous construisez des images conteneur, analysez-les pour détecter les vulnérabilités dans l'image de base et les paquets installés. Cela détecte les problèmes dans la couche du système d'exploitation et les dépendances d'exécution que votre code applicatif ne gère pas directement.

Voici à quoi ressemble une étape d'analyse d'image conteneur dans un workflow GitHub Actions :

- name: Analyser l'image conteneur pour les vulnérabilités
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'my-app:${{ github.sha }}'
    format: 'table'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

Cette étape exécute Trivy sur l'image construite, affiche un tableau des résultats, et fait échouer le job si des vulnérabilités de sévérité critique ou élevée sont trouvées. Le paramètre exit-code: '1' garantit que le pipeline s'arrête, agissant comme un gardien automatisé.

Analyse de l'infrastructure en tant que code. Si vous définissez l'infrastructure avec Terraform, CloudFormation ou des outils similaires, analysez ces définitions pour détecter les mauvaises configurations. Par exemple, des groupes de sécurité ouverts, du stockage non chiffré, ou des politiques IAM trop permissives.

Conformité des licences. Vérifier que les licences de vos dépendances sont compatibles avec la licence de votre projet et la politique de l'entreprise. C'est particulièrement important pour les produits commerciaux ou les projets qui peuvent être distribués en externe.

Une approche pratique pour commencer

Vous n'avez pas besoin d'implémenter tous ces contrôles en même temps. Commencez par ceux qui répondent à vos risques les plus immédiats.

Si votre équipe a déjà accidentellement commité des secrets, commencez par l'analyse des secrets. Si vous avez déjà été victime d'une bibliothèque vulnérable, commencez par l'analyse des dépendances. Si votre équipe infrastructure a trouvé des mauvaises configurations en production, commencez par l'analyse IaC.

Ajoutez les contrôles de manière incrémentale. Exécutez les vérifications rapides sur chaque commit. Planifiez les vérifications lentes au moment des pull requests ou avant les déploiements en staging. Laissez le pipeline vous dire quand une vérification échoue, et assurez-vous que le message d'échec est suffisamment clair pour que le développeur sache quoi corriger.

Une liste de contrôle rapide pour votre pipeline

• L'analyse des secrets s'exécute sur chaque commit
• L'analyse des dépendances s'exécute sur les pull requests et avant le déploiement en production
• Le SAST s'exécute sur les pull requests
• L'analyse des images conteneur s'exécute avant le déploiement en staging
• L'analyse de l'infrastructure en tant que code s'exécute sur les modifications d'infrastructure
• La conformité des licences s'exécute sur les pull requests
• Les vérifications rapides (secondes) s'exécutent sur chaque commit
• Les vérifications lentes (minutes) s'exécutent au moment des pull requests ou avant le staging

La vraie valeur

Les contrôles de sécurité et de conformité dans votre pipeline ne sont pas une bureaucratie supplémentaire qui vous ralentit. Ce sont des garde-fous qui permettent à votre équipe d'aller plus vite en toute confiance. Lorsque chaque modification passe les mêmes vérifications automatisées, vous n'avez pas besoin de vous demander si cette version a une vulnérabilité connue ou viole la politique de l'entreprise. Le pipeline a déjà répondu à ces questions.

Votre équipe peut se concentrer sur le développement de fonctionnalités et la correction de bugs, sachant que les filtres de base de sécurité et de conformité s'exécutent automatiquement, de manière cohérente et immédiate. C'est la différence entre espérer que rien ne se passe mal et savoir que rien d'évident ne s'est produit.