Plumber : Scanner de conformité pour pipelines GitLab CI/CD

Plumber scanne vos pipelines GitLab CI/CD et génère un score de conformité de 0 à 100%. Il produit également un PBOM (Pipeline Bill of Materials) — l’inventaire complet de vos dépendances CI/CD : images Docker, composants GitLab, templates et includes. Ce PBOM peut ensuite être analysé par des outils de sécurité comme Grype ou Trivy.

Plumber détecte automatiquement les problèmes de sécurité : images Docker avec tags mutables (latest), registries non autorisés, branches non protégées, includes obsolètes, jobs hardcodés.

Deux modes d’utilisation :

• CLI open-source — Pour les développeurs. Scan ponctuel, génération de PBOM, intégration CI via composant GitLab.
• Platform — Pour les équipes. Interface web, inventaire multi-projets, analyses planifiées, gestion des issues, RBAC.

Version actuelle

Ce guide utilise Plumber CLI v0.1.41 et Platform v2.36.1. La version 0.1.37 a introduit le PBOM avec export CycloneDX pour l’intégration avec les outils de sécurité.

Choisir son mode

Critère	CLI open-source	Platform
Cas d’usage	Scan ponctuel, intégration CI, projet unique	Inventaire centralisé, multi-projets, gouvernance
Installation	Binaire local ou image Docker	Docker Compose / Kubernetes
Configuration	Fichier .plumber.yaml	Interface web + policies
Contrôles	8 contrôles de base	15+ contrôles (variables, secrets, MR, quotas)
Résultats	Terminal / JSON	Dashboard web, historique, exports
Coût	Gratuit (MPL-2.0)	Free tier / Enterprise

Glissez pour voir

Recommandation :

Situation	Mode conseillé
Je veux tester Plumber rapidement	CLI
J’ai 1-2 projets, équipe unique	CLI + composant GitLab CI
J’ai 10+ projets, besoin de reporting	Platform Free
Conformité réglementaire, audit, RBAC	Platform Enterprise

Glissez pour voir

---

Partie 1 : CLI open-source

La CLI est idéale pour les développeurs qui veulent un scan rapide ou intégrer Plumber dans leur pipeline GitLab.

Installation

mise

mise use -g github:getplumber/plumber

Activation mise requise

L’installation via mise nécessite l’activation de mise dans votre shell, ou utilisez mise exec -- plumber.

Homebrew

brew tap getplumber/plumber
brew install plumber

Binaire

# Télécharger le binaire (Linux/macOS)
curl -LO "https://github.com/getplumber/plumber/releases/latest/download/plumber-$(uname -s | tr '[:upper:]' '[:lower:]')-$(uname -m | sed 's/x86_64/amd64/' | sed 's/aarch64/arm64/')"
chmod +x plumber-* && sudo mv plumber-* /usr/local/bin/plumber

Docker

# Toujours épingler la version (pas de :latest !)
docker pull getplumber/plumber:0.1.41

Vérification :

plumber version
# plumber version 0.1.41
#   commit: 5a2a3aa3b67c8489289bf98f47f9494f386f6458
#   built:  2026-02-12T12:55:08Z

Configuration du token GitLab

Plumber nécessite un token GitLab avec les scopes read_api et read_repository :

1. Créer le token

   Allez dans GitLab → User Settings → Access Tokens ou utilisez ce lien direct.

2. Sélectionner les scopes

   • read_api : accès en lecture à l’API
   • read_repository : accès au contenu du dépôt

3. Exporter le token

   export GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx

Rôle Maintainer requis

Le token doit appartenir à un utilisateur avec le rôle Maintainer (ou supérieur) sur le projet pour accéder aux paramètres de protection des branches.

Première analyse

Depuis un dépôt Git local (détection automatique) :

cd mon-projet
plumber analyze

Sur un projet distant :

plumber analyze --gitlab-url https://gitlab.com --project mongroupe/monprojet

Exemple de sortie

Auto-detected GitLab URL: https://gitlab.com
Auto-detected project: Bob74/test-gitlab-srt
Using configuration: .plumber.yaml
Analyzing project: Bob74/test-gitlab-srt on https://gitlab.com

Project: Bob74/test-gitlab-srt

──────────────────────────────────────────────────
Container images must not use forbidden tags (100.0% compliant)
──────────────────────────────────────────────────
  Total Images: 11
  Using Forbidden Tags: 0

──────────────────────────────────────────────────
Branch must be protected (0.0% compliant)
──────────────────────────────────────────────────
  Total Branches: 2
  Protected Branches: 1
  Unprotected: 1

  Issues Found:
    • Branch 'main' is not protected

────────────────────
Summary
────────────────────

  Status: FAILED ✗

  Compliance
  ╔════════════════════════════════════════════════════╤════════════╤══════════╗
  ║ Control                                            │ Compliance │   Status ║
  ╟────────────────────────────────────────────────────┼────────────┼──────────╢
  ║ Container images must not use forbidden tags       │     100.0% │        ✓ ║
  ║ Container images must come from authorized sources │     100.0% │        ✓ ║
  ║ Branch must be protected                           │       0.0% │        ✗ ║
  ║ Pipeline must not include hardcoded jobs           │       0.0% │        ✗ ║
  ╟────────────────────────────────────────────────────┼────────────┼──────────╢
  ║ Total (required: 100%)                             │      66.7% │        ✗ ║
  ╚════════════════════════════════════════════════════╧════════════╧══════════╝

Error: compliance 66.7% is below threshold 100.0%

Les 8 contrôles CLI

Contrôle	Description
containerImageMustNotUseForbiddenTags	Détecte les images avec tags mutables (latest, dev)
containerImageMustComeFromAuthorizedSources	Vérifie que les images viennent de registries autorisés
branchMustBeProtected	S’assure que les branches critiques sont protégées
pipelineMustNotIncludeHardcodedJobs	Détecte les jobs définis directement dans .gitlab-ci.yml
includesMustBeUpToDate	Vérifie que les includes utilisent la dernière version
includesMustNotUseForbiddenVersions	Détecte les includes avec versions mutables (main, HEAD)
pipelineMustIncludeComponent	Vérifie la présence de composants requis
pipelineMustIncludeTemplate	Vérifie la présence de templates requis

Glissez pour voir

Fichier de configuration

Générer la configuration par défaut :

plumber config generate

Voir la configuration effective :

plumber config view

Structure du fichier .plumber.yaml :

.plumber.yaml

version: "1.0"

controls:
  # Tags d'images interdits
  containerImageMustNotUseForbiddenTags:
    enabled: true
    tags:
      - latest
      - dev
      - main
    # Exiger que toutes les images soient épinglées par digest (sha256)
    # Ex: alpine@sha256:abc123... au lieu de alpine:3.19
    containerImagesMustBePinnedByDigest: false

  # Registries autorisés
  containerImageMustComeFromAuthorizedSources:
    enabled: true
    trustDockerHubOfficialImages: true
    trustedUrls:
      - $CI_REGISTRY_IMAGE:*
      - registry.gitlab.com/security-products/*
      - getplumber/plumber:*

  # Protection des branches
  branchMustBeProtected:
    enabled: true
    defaultMustBeProtected: true
    namePatterns:
      - main
      - release/*
    allowForcePush: false
    minMergeAccessLevel: 30   # Developer
    minPushAccessLevel: 40    # Maintainer

  # Pas de jobs hardcodés
  pipelineMustNotIncludeHardcodedJobs:
    enabled: true

  # Includes à jour
  includesMustBeUpToDate:
    enabled: true

  # Versions d'includes interdites
  includesMustNotUseForbiddenVersions:
    enabled: true
    forbiddenVersions:
      - latest
      - main
      - HEAD
    defaultBranchIsForbiddenVersion: false

  # Composants requis (expression booléenne ou tableau)
  pipelineMustIncludeComponent:
    enabled: false
    # Syntaxe expression (AND/OR) :
    # required: components/sast/sast AND components/secret-detection/secret-detection
    # Syntaxe tableau (OR de ANDs) :
    requiredGroups: []

  # Templates requis
  pipelineMustIncludeTemplate:
    enabled: false
    requiredGroups: []

Expression naturelle pour les composants requis

Depuis v0.1.34, vous pouvez utiliser une syntaxe naturelle pour les composants requis :

pipelineMustIncludeComponent:
  enabled: true
  required: (components/sast/sast AND components/secret-detection/secret-detection) OR security-team/full-pipeline/security

Options de la commande analyze

Option	Défaut	Description
--gitlab-url	Auto-détecté	URL de l’instance GitLab
--project	Auto-détecté	Chemin du projet (groupe/projet)
--config	.plumber.yaml	Chemin du fichier de configuration
--threshold	100	Score minimum pour passer (0-100)
--branch	Branche par défaut	Branche à analyser
--output	-	Fichier JSON de sortie (résultats)
--pbom	-	Fichier PBOM natif Plumber
--pbom-cyclonedx	-	Fichier PBOM au format CycloneDX (pour Grype, Trivy)
--print	true	Afficher la sortie texte
--verbose	false	Mode debug

Glissez pour voir

Codes de sortie : 0 = conformité ≥ threshold, 1 = échec ou erreur.

Analyse locale avant push

Depuis la version 0.1.41, Plumber peut analyser votre .gitlab-ci.yml local avant de le pousser sur GitLab. Cela permet de détecter les problèmes de conformité sans créer de commit.

# Plumber utilise automatiquement le fichier local si vous êtes dans le repo
cd mon-projet
plumber analyze

Ordre de priorité pour la source du .gitlab-ci.yml :

1. --branch spécifié → utilise le fichier distant de cette branche
2. Dans un repo Git correspondant au projet → utilise le fichier local
3. Sinon → utilise le fichier distant de la branche par défaut

Include local

Les fichiers include:local sont également résolus depuis votre filesystem local. Les autres types d’includes (components, templates, remote) sont toujours récupérés depuis leurs sources distantes.

---

PBOM : Pipeline Bill of Materials

Le PBOM (Pipeline Bill of Materials) est un inventaire complet de toutes les dépendances de votre pipeline CI/CD : images Docker, composants GitLab CI, templates et includes. C’est l’équivalent d’un SBOM (Software Bill of Materials) mais pour votre infrastructure CI/CD.

Pourquoi générer un PBOM ?

Besoin	PBOM apporte
Inventaire	Liste exhaustive des images et includes utilisés
Conformité	Preuve documentée des outils utilisés dans vos pipelines
Audit	Historique des versions et sources
Drift detection	Suivi des changements dans le temps (via Dependency-Track)

Glissez pour voir

Générer un PBOM

Plumber génère le PBOM en deux formats :

Format	Flag	Usage
Plumber natif	--pbom <fichier>	Inventaire détaillé avec métadonnées de conformité
CycloneDX SBOM	--pbom-cyclonedx <fichier>	Intégration avec Grype, Trivy, Dependency-Track, GitLab

Glissez pour voir

# Générer les deux formats
plumber analyze \
  --pbom pbom.json \
  --pbom-cyclonedx cyclonedx-sbom.json

Structure du PBOM natif

pbom.json

{
  "pbomVersion": "1.0.0",
  "generatedAt": "2026-02-15T18:35:11Z",
  "project": {
    "path": "mongroupe/monprojet",
    "id": 12345678,
    "gitlabUrl": "https://gitlab.com"
  },
  "containerImages": [
    {
      "image": "docker.io/python:3.11-slim",
      "registry": "docker.io",
      "name": "python",
      "tag": "3.11-slim",
      "jobs": ["unit-test", "deploy-staging"],
      "authorized": true,
      "forbiddenTag": false
    }
  ],
  "includes": [
    {
      "type": "component",
      "location": "gitlab.com/components/sast/sast",
      "version": "3.4.0",
      "latestVersion": "3.4.0",
      "upToDate": true,
      "componentName": "sast",
      "fromCatalog": true
    }
  ],
  "summary": {
    "totalImages": 2,
    "uniqueRegistries": 1,
    "totalIncludes": 1,
    "components": 1,
    "templates": 0
  }
}

Structure CycloneDX

Le format CycloneDX suit la spécification 1.5 et est compatible avec les outils de sécurité standard :

cyclonedx-sbom.json

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:16c5c32b-c05e-44f5-87c6-a4c2312e685e",
  "version": 1,
  "metadata": {
    "timestamp": "2026-02-15T18:35:11Z",
    "tools": [{ "vendor": "Plumber", "name": "plumber", "version": "0.1.41" }],
    "component": {
      "type": "application",
      "name": "mongroupe/monprojet"
    }
  },
  "components": [
    {
      "type": "container",
      "bom-ref": "container:0",
      "name": "python",
      "version": "3.11-slim",
      "purl": "pkg:docker/library/python@3.11-slim",
      "properties": [
        { "name": "plumber:registry", "value": "docker.io" },
        { "name": "plumber:jobs", "value": "unit-test,deploy-staging" },
        { "name": "plumber:authorized", "value": "true" }
      ]
    }
  ]
}

---

Analyser les PBOM avec Grype et Trivy

Le PBOM CycloneDX peut être analysé par des outils de sécurité pour détecter les vulnérabilités dans les images Docker référencées.

Limitation importante

Les composants GitLab CI et templates n’ont pas de CVE dans les bases de vulnérabilités publiques. Le PBOM est principalement un outil d’inventaire et de conformité. Pour scanner les vulnérabilités des images Docker en profondeur, utilisez trivy image ou grype directement sur les images.

Scanner avec Grype

Grype est un scanner de vulnérabilités d’Anchore.

# Installation
brew install grype
# ou
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Scanner le PBOM (préfixe sbom: requis)
grype sbom:cyclonedx-sbom.json

# Sortie JSON
grype sbom:cyclonedx-sbom.json -o json > vulnerabilities.json

# Échouer si vulnérabilités high/critical
grype sbom:cyclonedx-sbom.json --fail-on high

Sortie typique (peu ou pas de vulnérabilités attendues) :

 ✔ Vulnerability DB                [updated]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
No vulnerabilities found

Scanner avec Trivy

Trivy est le scanner de sécurité d’Aqua Security.

# Installation
brew install trivy
# ou
mise use -g trivy

# Scanner le PBOM
trivy sbom cyclonedx-sbom.json

# Format JSON
trivy sbom cyclonedx-sbom.json --format json > trivy-report.json

# Filtrer par sévérité
trivy sbom cyclonedx-sbom.json --severity HIGH,CRITICAL

# Échouer si vulnérabilités trouvées
trivy sbom cyclonedx-sbom.json --exit-code 1

Scanner les images directement

Pour un scan complet des vulnérabilités, scannez les images Docker directement :

# Extraire les images du PBOM et les scanner
jq -r '.containerImages[].image' pbom.json | while read image; do
  echo "=== Scanning $image ==="
  trivy image "$image"
done

Intégration GitLab CI

Plumber s’intègre directement dans vos pipelines GitLab CI de plusieurs façons.

Avec le composant officiel (recommandé) :

.gitlab-ci.yml

include:
  - component: gitlab.com/getplumber/plumber/plumber@v0.1.41

Le composant s’exécute automatiquement sur la branche par défaut, les tags et les merge requests. Il génère automatiquement les fichiers PBOM (natif et CycloneDX) comme artifacts.

Avec options :

.gitlab-ci.yml

include:
  - component: gitlab.com/getplumber/plumber/plumber@v0.1.41
    inputs:
      threshold: 80
      config_file: configs/my-plumber.yaml
      verbose: true

Avec Docker directement :

.gitlab-ci.yml

compliance:
  stage: validate
  image: getplumber/plumber:0.1.41
  script:
    - plumber analyze --threshold 80 --pbom pbom.json --pbom-cyclonedx sbom.json
  artifacts:
    paths:
      - pbom.json
      - sbom.json
    reports:
      cyclonedx: sbom.json
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Token CI/CD

Ajoutez GITLAB_TOKEN dans Settings → CI/CD → Variables (type : variable, masqué recommandé).

Scanner les vulnérabilités du PBOM :

.gitlab-ci.yml

# Après le job plumber
scan-pbom:
  stage: test
  image: aquasec/trivy:latest
  needs: ["plumber"]
  script:
    - trivy sbom plumber-cyclonedx-sbom.json --severity HIGH,CRITICAL --exit-code 1
  allow_failure: true

GitLab Ultimate

Sur GitLab Ultimate, le CycloneDX est automatiquement uploadé comme rapport de dépendances et visible dans l’onglet Licenses du pipeline.

GitLab Self-Hosted

Pour une instance GitLab auto-hébergée :

1. Importer le projet gitlab.com/getplumber/plumber vers votre instance

2. Activer CI/CD Catalog dans Settings → General → Visibility

3. Créer un tag pour publier : git tag v0.1.41 && git push origin v0.1.41

4. Utiliser le composant local :

   include:
     - component: gitlab.example.com/chemin/plumber/plumber@v0.1.41

---

Partie 2 : Platform

La Platform est une interface web qui étend les capacités de la CLI pour les équipes ayant plusieurs projets à gérer.

Quand passer à la Platform ?

Besoin	CLI suffit ?	Platform nécessaire ?
Scanner 1-2 projets ponctuellement	✅	❌
Intégrer dans un pipeline CI	✅	❌
Voir l’historique de conformité	❌	✅
Gérer 10+ projets	⚠️ Fastidieux	✅
Tracker les issues et leur résolution	❌	✅
Générer des rapports pour audit	❌	✅
Contrôler variables CI/CD et secrets	❌	✅
RBAC et permissions par équipe	❌	✅

Glissez pour voir

Contrôles supplémentaires Platform

La Platform ajoute des contrôles absents de la CLI :

Catégorie	Contrôle	Description
Variables CI/CD	Variables protégées	Vérifie le flag “protected”
Variables CI/CD	Variables masquées	Vérifie le flag “masked”
Secrets	Secrets dans la config	Détecte via Gitleaks
Merge Requests	Règles d’approbation	Vérifie les approval rules
Merge Requests	Settings MR	Squash, FF, etc.
Accès	Quotas de membres	Limite projet/groupe
Pipeline	Phases requises	Stages obligatoires
Sécurité	Security Policy source	Politiques de sécurité

Glissez pour voir

Policies et templates de conformité

La Platform organise les contrôles en policies (ensembles de contrôles thématiques). Trois templates sont disponibles :

Policy template	Description
OWASP	OWASP Top 10 CI/CD Security Risks
ISO27001 & ISO27002	Conformité aux contrôles de l’ISO/IEC 27001:2022 Annex A
SecNumCloud (SnC)	Conformité aux exigences de l’ANSSI pour les prestataires de services cloud

Glissez pour voir

Référentiels français

Le template SecNumCloud est particulièrement pertinent pour les organisations françaises souhaitant se conformer aux exigences de l’ANSSI. Il couvre les contrôles spécifiques aux prestataires de services d’informatique en nuage.

OWASP Top 10 CI/CD (détail)

Catégorie	Risques couverts	Contrôles associés
CICD-SEC-1, CICD-SEC-2	Flow Control, Access Management	Branch protection, quotas membres
CICD-SEC-3, CICD-SEC-4, CICD-SEC-7	Dependency Chain, Poisoned Pipeline, Insecure Config	Images autorisées, includes épinglés
CICD-SEC-6	Credential Hygiene	Variables protégées/masquées, secrets dans config

Glissez pour voir

Gestion des issues

Chaque problème détecté devient une issue :

Statut	Signification
Detected	Problème détecté au dernier scan
In progress	En cours de correction
Dismissed	Ignoré volontairement (exception documentée)
Fixed	Corrigé et vérifié

Glissez pour voir

RBAC et permissions

Rôle	Voir issues	Modifier statut	Gérer contrôles	Admin
Admin	✅	✅	✅	✅
Maintainer	✅	✅	✅	❌
Member	✅	✅	❌	❌

Glissez pour voir

Les permissions sont synchronisées avec GitLab.

Déploiement self-hosted

Prérequis : groupe GitLab

La Platform nécessite un groupe GitLab (pas un namespace utilisateur). Si vous n’avez que des projets personnels, créez d’abord un groupe sur https://gitlab.com/groups/new.

1. Cloner le repo

   git clone https://github.com/getplumber/platform.git plumber-platform
   cd plumber-platform
   cp .env.example .env

2. Créer une application OAuth sur GitLab

   Allez dans Settings → Applications de votre groupe GitLab.

   Champ	Valeur
   Name	Plumber Platform
   Redirect URI	http://localhost:3001/api/auth/gitlab/callback
   Confidential	✅ Coché
   Scopes	✅ api uniquement

   Glissez pour voir

3. Configurer .env

   # Générer des secrets
   SECRET_KEY=$(openssl rand -hex 32)
   DB_PASSWORD=$(openssl rand -base64 24 | tr -dc 'a-zA-Z0-9' | head -c 32)
   
   # Configurer
   sed -i "s|SECRET_KEY=.*|SECRET_KEY=\"$SECRET_KEY\"|" .env
   sed -i "s|JOBS_DB_PASSWORD=.*|JOBS_DB_PASSWORD=\"$DB_PASSWORD\"|" .env
   sed -i "s|JOBS_REDIS_PASSWORD=.*|JOBS_REDIS_PASSWORD=\"$DB_PASSWORD\"|" .env
   sed -i "s|JOBS_GITLAB_URL=.*|JOBS_GITLAB_URL=\"https://gitlab.com\"|" .env
   sed -i "s|ORGANIZATION=.*|ORGANIZATION=\"MON-GROUPE\"|" .env
   
   # OAuth (remplacer par vos valeurs)
   sed -i "s|GITLAB_OAUTH2_CLIENT_ID=.*|GITLAB_OAUTH2_CLIENT_ID=\"votre-client-id\"|" .env
   sed -i "s|GITLAB_OAUTH2_CLIENT_SECRET=.*|GITLAB_OAUTH2_CLIENT_SECRET=\"votre-secret\"|" .env

4. Lancer en mode local

   docker compose -f compose.local.yml up -d

   Service	URL
   Frontend	http://localhost:3000
   Backend API	http://localhost:3001

   Glissez pour voir

5. Se connecter

   Accédez à http://localhost:3000 et cliquez Sign in with GitLab.

Production (Docker Compose)

# Configurer le domaine
sed -i "s|FRONTEND_DOMAIN=.*|FRONTEND_DOMAIN=\"plumber.example.com\"|" .env
sed -i "s|API_DOMAIN=.*|API_DOMAIN=\"https://plumber.example.com\"|" .env

# Lancer avec Traefik + Let's Encrypt
docker compose up -d

Kubernetes (Helm)

helm repo add plumber https://charts.getplumber.io
helm repo update

helm install plumber plumber/plumber \
  --namespace plumber \
  --create-namespace \
  --set gitlab.url=https://gitlab.example.com \
  --set organization=MON-GROUPE \
  --set oauth.clientId=$OAUTH_CLIENT_ID \
  --set oauth.clientSecret=$OAUTH_CLIENT_SECRET

---

Pourquoi auditer ses pipelines ?

Les pipelines CI/CD concentrent les accès critiques : secrets, droits de publication, déploiement en production. Ils sont devenus une cible prioritaire des attaquants.

Attaques récentes

• SolarWinds (2020) — Backdoor injectée dans le pipeline, 18 000 organisations compromises
• Codecov (2021) — Script modifié exfiltrant les secrets CI
• tj-actions/changed-files (2025) — Action GitHub compromise, 23 000 repos exposés

GitLab CI/CD accepte des configurations dangereuses sans warning :

• Image python:latest → Tag mutable, peut changer à tout moment
• Include vers main → Version non épinglée
• Branche non protégée → Push malveillant possible

Plumber détecte ces problèmes avant qu’ils ne surviennent.

Vecteur d’attaque	Contrôle Plumber	Protection
Image empoisonnée	containerImageMustComeFromAuthorizedSources	Bloque registries non approuvés
Tag mutable	containerImageMustNotUseForbiddenTags	Interdit latest, dev
Include modifié	includesMustNotUseForbiddenVersions	Exige versions épinglées
Push non autorisé	branchMustBeProtected	Vérifie protection branches

Glissez pour voir

---

Bonnes pratiques

Commencer progressivement

Sur un projet existant :

plumber analyze --threshold 50

Puis augmentez jusqu’à 100%.

Désactiver les contrôles non pertinents

controls:
  pipelineMustNotIncludeHardcodedJobs:
    enabled: false  # Notre équipe utilise des jobs hardcodés par choix

Documenter les exceptions

containerImageMustComeFromAuthorizedSources:
  trustedUrls:
    # Registry interne - validé par l'équipe sécurité le 2026-01-15
    - registry.internal.example.com/*

Exiger des composants de sécurité

pipelineMustIncludeComponent:
  enabled: true
  requiredGroups:
    - ["components/sast/sast", "components/secret-detection/secret-detection"]

---

Dépannage

CLI

Problème	Cause	Solution
GITLAB_TOKEN environment variable is required	Token non défini	export GITLAB_TOKEN=glpat-xxx
401 Unauthorized	Token invalide	Vérifier scopes read_api + read_repository
403 Forbidden on MR settings	GitLab non-Premium	Normal, le scan continue
404 Not Found	Projet incorrect	Vérifier --project et --gitlab-url

Glissez pour voir

Platform

Problème	Cause	Solution
Containers redémarrent	REPLACE_ME_* dans .env	Générer secrets avec openssl rand -hex 32
User role is No One	ORGANIZATION est un user	Créer un groupe GitLab
Activate your license	Pas Owner/Maintainer du groupe	Vérifier droits sur le groupe
404 /groups/{org}/members	Namespace utilisateur	Utiliser un groupe GitLab
invalid_redirect_uri	Mauvaise URI OAuth	http://localhost:3001/api/auth/gitlab/callback
PostgreSQL auth failed	Anciens credentials	docker compose down -v puis relancer

Glissez pour voir

---

À retenir

• CLI : pour les développeurs, scan ponctuel, intégration CI
• Platform : pour les équipes, multi-projets, gouvernance
• PBOM : inventaire complet des dépendances CI/CD (images, components, templates)
• CycloneDX : format standard pour intégration avec Grype, Trivy, Dependency-Track
• 8 contrôles CLI configurables via .plumber.yaml
• 15+ contrôles Platform (variables, secrets, MR, quotas)
• Composant GitLab : 2 lignes dans le pipeline
• Analyse locale : valider le .gitlab-ci.yml avant de pousser
• Threshold : échouer si score < X%
• ORGANIZATION doit être un groupe GitLab, pas un user

---

Prochaines étapes

OWASP Top 10 CI/CD Les 10 risques majeurs des pipelines

Sécuriser les pipelines Bonnes pratiques de sécurité CI/CD

Trivy Scanner de vulnérabilités pour images et SBOM

Grype Scanner de vulnérabilités Anchore

---

Ressources

• Site officiel Plumber
• GitHub CLI
• GitHub Platform
• Composant GitLab CI/CD
• Documentation PBOM
• Tests PBOM avec Grype/Trivy
• Spécification CycloneDX 1.5
• Discord

×

📖 Voir la documentation →