Comment configurer un pipeline CI/CD securise pour un projet open source en 6 etapes

La securite d un projet open source ne se joue pas seulement dans le code : elle se joue dans le pipeline qui le construit, le teste et le deploie. En 2026, les attaques de supply chain logicielle representent 62% des incidents de securite dans l ecosysteme open source (source : rapport OSSRA 2026). Un pipeline CI/CD non securise est une porte grande ouverte : injection de code malveillant dans les artefacts de build, exfiltration de secrets, deploiement de dependances compromises. Ce guide vous montre comment fermer ces portes en 6 etapes, avec des outils 100% open source et des exemples de configuration prets a l emploi.

Ce guide s appuie sur les bonnes pratiques de l OWASP Top 10 et les retours d experience de projets open source majeurs. Chaque etape inclut l outil recommande, la configuration minimale, et les seuils de blocage adaptes a un projet open source. L objectif : un pipeline qui bloque les vulnerabilites avant qu elles n atteignent la branche principale, sans ralentir votre equipe de developpement.

Etape 1 : Integrer l analyse statique SAST avec Semgrep

L analyse statique du code source (SAST, Static Application Security Testing) est la premiere couche de defense de votre pipeline. Elle scanne le code sans l executer pour identifier les patterns de vulnerabilites : injections SQL, XSS, deserialization non securisee, utilisation de fonctions cryptographiques deprecies, et des centaines d autres regles. Pour les projets open source, Semgrep est l outil de reference. Developpe par Semgrep Inc. (anciennement r2c) et distribue sous licence LGPL-2.1, Semgrep offre un moteur de patterns rapide, des regles communautaires couvrant plus de 30 langages, et une integration native avec GitHub Actions, GitLab CI et Jenkins.

L avantage de Semgrep par rapport a CodeQL ou SonarQube est sa simplicite de configuration et la facilite d ecriture de regles personnalisees. Une regle Semgrep s ecrit en YAML avec une syntaxe proche du code source cible, ce qui permet a n importe quel developpeur de l equipe de creer une regle en quelques minutes. Pour un projet Next.js, par exemple, vous pouvez ecrire une regle qui detecte l utilisation de dangerouslySetInnerHTML avec des entrees utilisateur non sanitisees. Semgrep supporte egalement le scan incremental (uniquement les fichiers modifies dans la PR), ce qui maintient des temps d execution inferieurs a 60 secondes meme sur les gros projets.

Configuration recommandee : creez un fichier .github/workflows/security-sast.yml dans votre repository. Utilisez les rulesets p/security-audit et p/owasp-top-ten comme base. Configurez le mode --error pour que le job echoue en cas de finding de severite ERROR (vulnerabilites critiques), et --severity WARNING en mode alerte sans blocage. Ajoutez un fichier .semgrepignore pour exclure les dossiers de tests et les fixtures si les faux positifs sont trop nombreux.

Etape 2 : Scanner les dependances et conteneurs avec Trivy

Le scan de composition logicielle (SCA, Software Composition Analysis) est la deuxieme couche de securite. Il analyse les dependances de votre projet (npm, pip, Maven, Cargo, Go modules) pour identifier les bibliotheques avec des CVE connues. En 2026, 87% des codebases open source contiennent au moins une dependance avec une vulnerabilite connue (source : rapport OSSRA 2026). Trivy, developpe par Aqua Security et distribue sous licence Apache-2.0, est l outil SCA le plus polyvalent : il scanne les fichiers de lockfile, les images Docker, les manifestes Kubernetes, les fichiers IaC (Terraform, CloudFormation) et les fichiers SBOM.

Le principal avantage de Trivy sur Snyk (qui a une version open source limitee) est son exhaustivite et sa rapidite. Trivy maintient une base de donnees de vulnerabilites mise a jour toutes les 6 heures, couvrant les bases NVD, GitHub Advisory Database, Alpine SecDB, Red Hat OVAL, et bien d autres. Un scan complet d un projet Node.js avec 500 dependances prend moins de 30 secondes. Trivy genere egalement des rapports au format SARIF, directement integrable dans l onglet Security de GitHub pour une visibilite centralisee des vulnerabilites.

Configuration recommandee : ajoutez un job Trivy dans votre workflow GitHub Actions qui s execute sur chaque PR et sur les pushes vers main. Utilisez trivy fs --severity CRITICAL,HIGH --exit-code 1 pour bloquer le merge en cas de vulnerabilite critique ou haute. Pour les images Docker, ajoutez trivy image --severity CRITICAL --exit-code 1 apres le build. Activez le mode --ignore-unfixed pour ignorer les CVE sans correctif disponible (inutile de bloquer sur un probleme que vous ne pouvez pas resoudre). Completez avec Dependabot ou Renovate pour la mise a jour automatique des dependances vulnerables.

Etape 3 : Detecter les secrets exposes avec Gitleaks

Les secrets commites dans un repository — cles API, tokens d acces, mots de passe de bases de donnees, certificats prives — sont la cause numero un des breches de securite dans les projets open source. Un secret commite une seule fois reste dans l historique git pour toujours, meme apres suppression du fichier. Gitleaks, distribue sous licence MIT, scanne tout l historique du repository pour identifier les secrets exposes. Il utilise des regles basees sur des expressions regulieres et de l entropie pour detecter les cles AWS, les tokens GitHub, les mots de passe de bases de donnees, les cles privees SSH, et des dizaines d autres types de secrets.

L integration de Gitleaks dans votre pipeline se fait a deux niveaux. Niveau 1 : pre-commit hook local, qui empeche le developpeur de commiter un secret avant meme qu il n atteigne le repository distant. Installez Gitleaks en hook pre-commit via le framework pre-commit de Python avec la configuration gitleaks-pre-commit. Niveau 2 : job CI qui scanne chaque PR avec gitleaks detect --source . --verbose. Ce double filet garantit qu aucun secret ne passe, meme si un contributeur n a pas installe le hook local.

Configuration recommandee : creez un fichier .gitleaks.toml a la racine du repository pour personnaliser les regles. Ajoutez des allowlist pour les faux positifs frequents (tokens de test, exemples de documentation). Configurez le mode --exit-code 1 pour bloquer systematiquement le merge si un secret est detecte. Pas d exception : un secret commite est toujours une urgence, quelle que soit sa severite apparente. Pour aller plus loin sur la protection de vos secrets, consultez notre guide sur la securisation des applications web avec l OWASP Top 10.

Etape 4 : Executer des tests dynamiques DAST avec OWASP ZAP

Les etapes 1 a 3 analysent le code et les dependances sans executer l application. L etape 4 ajoute une couche cruciale : le DAST (Dynamic Application Security Testing), qui teste l application en cours d execution en simulant des attaques reelles. OWASP ZAP (Zed Attack Proxy), distribue sous licence Apache-2.0 par l OWASP Foundation, est le scanner DAST open source le plus utilise au monde. Il intercepte le trafic HTTP, explore automatiquement l application, et lance des centaines de tests d attaque : injections SQL, XSS reflechis et stockes, CSRF, directory traversal, SSRF, et bien d autres.

L integration de ZAP dans un pipeline CI/CD se fait via l image Docker officielle et les scripts d automatisation fournis par le projet. Le mode baseline scan est le plus adapte pour l integration CI : il execute un scan rapide (2 a 5 minutes) qui couvre les vulnerabilites les plus courantes sans exploration en profondeur. Pour les deploiements en staging, utilisez le mode full scan qui explore l application en profondeur et teste des scenarios d attaque plus complexes (30 a 60 minutes). Le mode API scan est specialise pour les API REST et GraphQL.

Configuration recommandee : executez ZAP baseline scan sur chaque PR qui modifie du code backend ou des routes API. Deployez l application dans un container ephemere dans le pipeline CI, lancez le scan ZAP contre cette instance, et collectez les resultats au format SARIF. Configurez un seuil de blocage pour les alertes de risque HIGH et CRITICAL. Pour les alertes de risque MEDIUM et LOW, generez un rapport sans bloquer le merge. Important : ajoutez un fichier zap-rules.tsv pour desactiver les regles qui generent des faux positifs systematiques dans votre contexte applicatif.

Etape 5 : Signer les artefacts et images Docker avec Cosign

La signature des artefacts de build est l etape la plus souvent negligee dans les pipelines CI/CD open source, et pourtant c est la derniere ligne de defense contre les attaques de supply chain. Sans signature, rien ne garantit que l image Docker deployee en production est bien celle construite par votre pipeline, et non une version modifiee par un attaquant qui a compromis votre registry. Cosign, developpe par le projet Sigstore (Linux Foundation), permet de signer cryptographiquement vos images Docker, vos binaires et vos fichiers SBOM avec une infrastructure de cles simplifiee.

L innovation majeure de Cosign par rapport aux outils de signature traditionnels (GPG, Notary v1) est le mode keyless signing via Fulcio et Rekor. Au lieu de gerer des cles privees (un cauchemar operationnel pour les projets open source communautaires), Cosign utilise l identite du workflow CI (le token OIDC de GitHub Actions) pour generer une signature ephemere. Cette signature est enregistree dans un log de transparence public (Rekor), ce qui permet a n importe qui de verifier que l image a ete construite par votre pipeline officiel, sans avoir besoin de votre cle publique.

Configuration recommandee : ajoutez un step Cosign apres le build et le push de votre image Docker. Utilisez le mode keyless avec cosign sign --yes $IMAGE_DIGEST (le flag --yes accepte automatiquement les termes Fulcio). Activez la permission id-token: write dans votre workflow pour permettre la generation du token OIDC. Cote deploiement, configurez votre cluster Kubernetes avec un admission controller (Kyverno ou Connaisseur) qui rejette les images non signees. Cela cree une chaine de confiance complete du build au deploiement. Pour plus de contexte sur l infrastructure de deploiement, voir notre guide sur l hebergement web performant.

Etape 6 : Mettre en place un monitoring de securite avec Grafana

Les etapes 1 a 5 couvrent la securite avant et pendant le deploiement. L etape 6 ferme la boucle avec un monitoring de securite en production. Sans monitoring, vous ne savez pas si une vulnerabilite detectee (et temporairement acceptee) est exploitee, si de nouvelles CVE affectent vos dependances deployees, ou si un comportement anormal indique une intrusion. Grafana (distribue sous licence AGPL-3.0) combine avec Loki pour les logs et Prometheus pour les metriques offre une plateforme de monitoring complete et open source.

Le monitoring de securite dans le contexte CI/CD couvre trois dimensions. Premiere dimension : dashboard de suivi des vulnerabilites. Agreez les resultats de Semgrep, Trivy et ZAP dans un dashboard Grafana qui affiche le nombre de vulnerabilites ouvertes par severite, le delai moyen de remediation, et l evolution dans le temps. Deuxieme dimension : alerting sur les nouvelles CVE. Configurez un job cron dans votre pipeline qui execute Trivy quotidiennement sur vos images deployees et envoie une alerte Slack ou email si une nouvelle CVE critique est decouverte. Troisieme dimension : detection d anomalies en production. Utilisez les logs applicatifs (via Loki) pour detecter les patterns d attaque en temps reel : pics de requetes 4xx/5xx, tentatives d injection dans les parametres, acces a des routes non documentees.

Configuration recommandee : deployez la stack Grafana + Loki + Prometheus via Helm sur votre cluster Kubernetes, ou utilisez Grafana Cloud (tier gratuit genereux pour les projets open source). Creez un dashboard dedie "Security Pipeline" avec quatre panels : (1) Vulnerabilites ouvertes par severite (barre chart), (2) Tendance des CVE sur 30 jours (line chart), (3) Secrets detectes et remedies (table), (4) Alertes DAST par categorie OWASP (pie chart). Configurez des alertes Grafana pour etre notifie immediatement quand une nouvelle vulnerabilite critique est decouverte dans vos dependances deployees. Ce monitoring continu est la difference entre une equipe qui reagit aux incidents et une equipe qui les anticipe.

Bonnes pratiques complementaires pour un pipeline blinde

Au-dela des 6 etapes, voici les bonnes pratiques transversales qui renforcent la securite de votre pipeline CI/CD :

Principe du moindre privilege pour les runners. Si vous utilisez des runners self-hosted (au lieu des runners GitHub-hosted), executez-les dans des conteneurs ephemeres avec des privileges minimaux. Ne montez jamais le socket Docker de l hote dans le runner. Utilisez des images de base minimales (distroless ou Alpine) et interdisez l execution en root. Chaque build doit s executer dans un environnement jetable qui est detruit apres le job.

Branch protection rules strictes. Configurez les branch protection rules de GitHub pour imposer le passage de tous les checks de securite avant le merge vers main. Exigez au minimum une review approuvee, le passage des jobs SAST, SCA et secrets, et interdisez le force push. Pour les projets avec des contributeurs externes, activez le mode Require approval for first-time contributors pour eviter que des workflows malveillants ne s executent automatiquement.

Generer un SBOM (Software Bill of Materials). A chaque release, generez un SBOM au format SPDX ou CycloneDX qui liste toutes les dependances, leurs versions et leurs licences. Trivy peut generer un SBOM avec trivy sbom. Le SBOM devient un element de conformite incontournable avec les reglementations europeennes DORA et le Cyber Resilience Act. Signez le SBOM avec Cosign et attachez-le a votre image Docker pour une tracabilite complete.

Un pipeline CI/CD sans securite, c est comme un coffre-fort avec la porte ouverte. Les 6 etapes de ce guide ne sont pas un luxe, c est le minimum syndical pour tout projet open source qui se respecte en 2026. La bonne nouvelle : tous les outils necessaires sont open source et gratuits. La mauvaise nouvelle : il n y a plus d excuse pour ne pas les utiliser. — Sophie Laurent, DevOps Lead et contributrice open source

FAQ : Pipeline CI/CD securise pour projets open source