Plumber pour GitLab CI/CD et GitHub Actions : premier scan de conformité

Si votre pipeline GitLab CI/CD utilise des images Docker non épinglées, des includes sur main ou un build basé sur Docker-in-Docker — ou si vos workflows GitHub Actions référencent encore des actions tierces par tag mutable — vous n'avez pas besoin d'une plateforme de gouvernance complète. Vous avez besoin d'un premier scan clair. Plumber sert à ça : vous créez une configuration minimale au schéma v2.0, vous lancez plumber analyze, vous lisez trois ou quatre problèmes concrets, puis vous intégrez le contrôle dans votre CI avec le composant officiel. Dans ce guide, on commence volontairement par la CLI, ensuite par le composant GitLab, puis on termine par le PBOM, le score A-E et la Platform.

Ce que vous allez apprendre

Créer une configuration minimale au schéma v2.0 avec plumber config init, puis la valider avant le premier scan
Migrer une configuration v1 existante vers le schéma v2.0 avec plumber config migrate
Lancer une analyse locale sur un dépôt GitLab ou un dépôt GitHub et comprendre l'auto-détection
Corriger les erreurs fréquentes : image non épinglée, action GitHub non pinnée par SHA, branche non protégée
Ajouter le composant GitLab CI/CD officiel sans créer de doubles pipelines ni de job .pre inutilisable
Exporter un PBOM et l'exploiter avec Trivy ou Grype

Plumber en une phrase

Plumber est un scanner de conformité pour GitLab CI/CD et GitHub Actions. Côté GitLab, il interroge l'API du projet et lit la configuration mergée ; côté GitHub, il analyse en local les fichiers de .github/workflows via le moteur Rego. Dans les deux cas, il signale les écarts les plus fréquents : images non fiables, tags mutables, actions tierces non épinglées par SHA, branches non protégées, includes obsolètes, scripts téléchargés sans vérification ou usage de Docker-in-Docker.

Par où commencer ?

Votre situation	Porte d'entrée recommandée	Pourquoi
Vous découvrez Plumber	CLI locale	Vous comprenez d'abord ce que l'outil détecte et comment lire la sortie
Vous voulez l'ajouter rapidement à un pipeline existant	Composant GitLab CI/CD	Vous évitez d'écrire un job manuel complet
Vous devez centraliser plusieurs projets	Platform	Vous passez de l'analyse projet par projet à la gouvernance

Prérequis

Avant de lancer votre premier scan, vous avez besoin de :

un dépôt Git lié à un projet GitLab ou GitHub ;
côté GitLab : un token avec les scopes read_api et read_repository (rôle Maintainer sur le projet, ou un Project Access Token doté de ce rôle) ;
côté GitHub : la CLI gh authentifiée (gh auth login). Plumber lit le token depuis ~/.config/gh automatiquement ; aucune variable d'environnement n'est nécessaire ;
un terminal interactif si vous voulez utiliser plumber config init ;
au moins une configuration .plumber.yaml si vous passez par la CLI.

Installation

mise use -g github:getplumber/plumber

brew tap getplumber/plumber
brew install getplumber/plumber/plumber

# Télécharger une version précise depuis la page Releases
# https://github.com/getplumber/plumber/releases

# Toujours épingler la version, pas :latest
docker pull getplumber/plumber:0.3.10

Vérification :

plumber version

La sortie doit afficher plumber version 0.3.10 (ou la version plus récente que vous avez installée) avec le hash de commit et la date de build.

Premier scan local en 5 minutes

Le chemin le plus simple est toujours le même : configurer, valider, scanner, corriger. Plumber détecte automatiquement le provider en lisant votre remote origin : si l'URL pointe vers GitLab, il bascule sur le chemin API GitLab ; si elle pointe vers GitHub, il scanne en local le dossier .github/workflows via le moteur Rego.

Créez une configuration minimale avec le wizard interactif
Fenêtre de terminal
```
plumber config init
plumber config validate
```
plumber config init pose des questions ciblées puis génère un fichier court au schéma v2.0, adapté à votre projet. plumber config validate vérifie ensuite que le YAML est correct et signale les fautes de frappe dans les noms de contrôles ou de clés.
Authentifiez-vous auprès de votre provider

Côté GitLab, créez un token via User Settings -> Access Tokens avec read_api et read_repository, puis exportez-le :
Fenêtre de terminal
```
export GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
```
Côté GitHub, authentifiez-vous une fois via la CLI gh — Plumber lit ensuite le token depuis ~/.config/gh sans variable d'environnement :
Fenêtre de terminal
```
gh auth login
gh auth status
```
Lancez l'analyse depuis le dépôt Git
Fenêtre de terminal
```
cd mon-projet
plumber analyze
```
Si votre dépôt possède un remote origin pointant vers GitLab ou GitHub, Plumber détecte automatiquement le provider, l'URL et le chemin du projet. Sur GitHub, l'analyse repose sur les fichiers locaux : aucun appel API n'est requis pour les contrôles workflow (l'API n'est appelée que pour la protection de branche).
Lisez d'abord le résumé, pas toute la sortie

Cherchez en priorité :
- le pourcentage de conformité global ;
- les contrôles en échec ;
- les codes ISSUE-XXX ;
- le nom précis du job ou du workflow concerné ;
- le score A-E et les points sur 100.

Si vous n'avez pas de terminal interactif, utilisez :

plumber config generate --output .plumber.yaml
plumber config validate

config generate écrit le template officiel complet, commenté, au schéma v2.0 (sections gitlab: et github:). Il est plus long, mais il convient mieux à un premier commit ou à un usage automatisé.

Exemple réel : pipeline GitLab opensource

Sur le dépôt de lab Bob74/pipeline-craft, la commande suivante analyse une branche de solution :

export GITLAB_TOKEN=glpat-xxxx
plumber analyze --branch solution/lab-12 --score

Voici le résumé observé :

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

Status: FAILED ✗
Total (required: 100%): 72.7%

Controls in failure:
- ISSUE-103 ×5 : images non épinglées par digest
- ISSUE-412 ×1 : Docker-in-Docker détecté
- ISSUE-401 ×5 : jobs hardcodés

Plumber Score: D (34 / 100 pts)
  Poor — High-severity issues impacting the pipeline
  Critical 0   High 6   Medium 6   Low 0

Exemple réel : workflow GitHub opensource

Le provider GitHub ne nécessite ni --gitlab-url ni GITLAB_TOKEN. Une fois gh auth login fait, lancez simplement :

git clone https://github.com/sigstore/cosign.git
cd cosign
plumber config generate --output .plumber.yaml --force
plumber analyze --score

Extrait du scan sur sigstore/cosign, projet opensource majeur de la CNCF :

HIGH [ISSUE-104] job "conformance-nightly/conformance" references
      action "sigstore/sigstore-conformance@main" with a mutable ref
      — pin by commit SHA instead
HIGH [ISSUE-505] Branch 'main' has non-compliant protection settings
MED  [ISSUE-304] job "e2e-tests/e2e-cross" runs with no explicit
      `permissions:` block — the GITHUB_TOKEN inherits the
      repository default scope

Status: FAILED ✗
Total (required: 100%): 66.7%

Plumber Score: D
  Critical 0   High 7   Medium 4   Low 0

ISSUE-104 est l'apport phare du provider GitHub : il détecte les uses: qui référencent une action tierce par tag ou branche au lieu d'un SHA de 40 caractères. C'est la classe de faille exploitée par la compromission tj-actions/changed-files (CVE-2025-30066) en mars 2025.

Si l'auto-détection ne marche pas

Le cas le plus fréquent est simple : le dépôt n'a pas de remote origin, ou l'URL du remote ne pointe ni vers GitLab ni vers GitHub.

Passez alors explicitement les paramètres :

# GitLab self-hosted
plumber analyze --gitlab-url https://gitlab.com --project mon-groupe/mon-projet

# GitHub Enterprise Server
plumber analyze --github-url https://github.example.com --project mon-org/mon-projet

Erreurs fréquentes à corriger d'abord

Plumber documente 62 codes d'issues organisés en six familles (voir l'annexe en bas de guide). Mais sur un projet qui n'a jamais été audité, ce sont presque toujours les mêmes quatre erreurs qui dominent — quel que soit le provider. Commencez par celles-ci.

1. Images de conteneur non épinglées par digest

Dans le lab pipeline-craft testé, Plumber a signalé :

HIGH [ISSUE-103] Job 'pytest' uses image without digest pinning: docker.io/python:3.12-slim
HIGH [ISSUE-103] Job 'docker-build' uses image without digest pinning: docker.io/docker:27

Le problème n'est pas seulement l'usage de latest. Un tag de version comme python:3.12-slim reste mutable : si le registre republie l'image, votre pipeline peut exécuter autre chose demain.

Pour activer le mode strict, la clé se trouve dans le schéma v2.0 sous la section provider :

version: "2.0"
gitlab:
  controls:
    containerImageMustNotUseForbiddenTags:
      enabled: true
      containerImagesMustBePinnedByDigest: true

2. Actions GitHub non pinnées par SHA (provider GitHub)

C'est la nouveauté la plus visible apportée par le provider GitHub :

HIGH [ISSUE-104] job "conformance-nightly/conformance" references
      action "sigstore/sigstore-conformance@main" with a mutable ref
      — pin by commit SHA instead

Un uses: owner/action@v4 ou uses: owner/action@main reste mutable côté maintainer. Si l'action est compromise — comme tj-actions/changed-files en mars 2025 (CVE-2025-30066) — votre workflow exécute silencieusement le code modifié avec ses secrets.

Activez le contrôle dans la section GitHub :

github:
  controls:
    actionsMustBePinnedByCommitSha:
      enabled: true
      trustedOwners:
        - actions
        - github

La liste trustedOwners exempte les actions GitHub de premier rang (actions/*, github/*) pour concentrer le signal initial sur la surface tierce.

3. Includes sur `main`, `master` ou `HEAD` (provider GitLab)

Un include pointant sur une branche mutable rend votre pipeline difficile à reproduire et peut casser sans changement dans votre dépôt.

include:
  - project: security/templates
    file: /pipelines/sast.yml
    ref: main

include:
  - project: security/templates
    file: /pipelines/sast.yml
    ref: v2.4.1

Le contrôle associé est includesMustNotUseForbiddenVersions avec ISSUE-404.

4. Branche principale non protégée

Si la branche par défaut n'est pas protégée, un push direct ou une modification non revue peut contourner vos pratiques de revue et de sécurité. Le contrôle existe sous les deux providers et renvoie ISSUE-501 (absence de protection) ou ISSUE-505 (protection incomplète).

gitlab:
  controls:
    branchMustBeProtected:
      enabled: true
      defaultMustBeProtected: true
      namePatterns:
        - main
      allowForcePush: false

Une cinquième erreur très courante : Docker-in-Docker

Le lab a également remonté :

HIGH [ISSUE-412] job "docker-build" uses Docker-in-Docker service "docker:27-dind"
  ↳ at .gitlab-ci.yml:55
  ↳ docs: https://getplumber.io/docs/use-plumber/issues/ISSUE-412

Sur des runners partagés, DinD augmente le risque d'évasion de conteneur et de mouvement latéral. Si vous construisez des images, privilégiez Kaniko ou Buildah. Le contrôle existe aussi côté GitHub avec ISSUE-413 (mode daemon non sécurisé).

Fichier de configuration : schéma v2.0 par provider

Le schéma v2.0 introduit en 0.3 organise les contrôles par provider : tout ce qui concerne GitLab CI/CD vit sous gitlab.controls:, tout ce qui concerne GitHub Actions vit sous github.controls:. Le top-level controls: de la v1 disparaît, et le bloc engine: aussi (le moteur Rego est désormais le seul disponible et tourne par défaut).

Exemple minimal pour démarrer

version: "2.0"

gitlab:
  controls:
    containerImageMustNotUseForbiddenTags:
      enabled: true
      tags:
        - latest
        - dev
        - main
      containerImagesMustBePinnedByDigest: true

    containerImageMustComeFromAuthorizedSources:
      enabled: true
      trustDockerHubOfficialImages: true
      trustedUrls:
        - $CI_REGISTRY_IMAGE:*
        - registry.gitlab.com/security-products/*

    branchMustBeProtected:
      enabled: true
      defaultMustBeProtected: true
      namePatterns:
        - main
      allowForcePush: false

    includesMustNotUseForbiddenVersions:
      enabled: true
      forbiddenVersions:
        - latest
        - main
        - HEAD

github:
  controls:
    actionsMustBePinnedByCommitSha:
      enabled: true
      trustedOwners:
        - actions
        - github

    branchMustBeProtected:
      enabled: true
      defaultMustBeProtected: true
      namePatterns:
        - main

Migrer une configuration v1 en une commande

Si vous arrivez d'une version antérieure et que votre .plumber.yaml utilise encore le top-level controls:, plumber config migrate ré-écrit le fichier au schéma v2.0 en préservant commentaires et ordre :

# Crée .plumber.yaml.v2 à côté du fichier original
plumber config migrate

# Ou écrase en place (le fichier original part en .plumber.yaml.bak)
plumber config migrate --in-place

La migration encapsule le bloc controls: existant sous gitlab.controls:, upgrade version: "1.0" vers "2.0" et supprime le bloc engine: devenu obsolète. Les sections gitlab: ou github: déjà présentes sont laissées intactes.

Commandes utiles autour de la configuration

# Vérifier le fichier
plumber config validate

# Voir la configuration effective sans commentaires
plumber config view

# Comparer la configuration locale au défaut (sortie colorisée)
plumber config diff

# Générer le template complet officiel (sections gitlab: et github:)
plumber config generate --output .plumber.yaml --force

plumber config diff est apparu en 0.3 et permet de voir d'un coup d'œil ce qui diffère du template officiel : vert pour ce que vous avez ajouté ou modifié, rouge pour ce que vous avez retiré. Utile sur un projet hérité avant de proposer un durcissement.

Ajouter Plumber à GitLab CI avec le composant officiel

Une fois le premier scan local compris, le bon point d'entrée côté GitLab est le composant CI/CD officiel.

Démarrage rapide recommandé

Ajoutez d'abord le token GITLAB_TOKEN dans Settings -> CI/CD -> Variables, puis utilisez ce squelette :

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH
    - if: $CI_COMMIT_TAG

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

Ce bloc workflow:rules évite de créer à la fois un pipeline de branche et un pipeline de merge request sur le même push.

Variante personnalisée

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH
    - if: $CI_COMMIT_TAG

include:
  - component: gitlab.com/getplumber/plumber/plumber@v0.3.10
    inputs:
      stage: test
      threshold: 80
      config_file: .plumber.yaml
      pbom_file: plumber-pbom.json
      pbom_cyclonedx_file: plumber-cyclonedx-sbom.json

Priorité de configuration du composant

Le composant recherche la configuration dans cet ordre :

l'input config_file s'il est défini ;
le fichier .plumber.yaml à la racine du dépôt ;
la configuration par défaut embarquée dans l'image.

Et si vous écrivez un job manuel ?

Gardez cette variante pour les besoins spécifiques. Si vous voulez ajouter --mr-comment et --badge dans un job manuel, séparez-les en deux jobs : le commentaire de merge request n'a de sens qu'en pipeline de MR, et le badge ne se met à jour que sur la branche par défaut.

GitLab self-hosted : le minimum à savoir

Sur un GitLab auto-hébergé, vous ne pouvez pas consommer directement le composant depuis gitlab.com. Le chemin correct est le suivant :

Importez le dépôt https://gitlab.com/getplumber/plumber.git dans votre instance.
Activez le CI/CD Catalog dans le projet importé.
Publiez une release en lançant un pipeline sur un tag déjà importé, par exemple v0.3.10.
Consommez ensuite le composant local dans vos pipelines.

include:
  - component: gitlab.example.com/infrastructure/plumber/plumber@v0.3.10

Exporter un PBOM et l'analyser

Une fois la lecture du scan comprise, vous pouvez passer au PBOM.

Le PBOM (Pipeline Bill of Materials) est l'inventaire des dépendances de votre pipeline : images Docker, composants GitLab, templates et includes.

plumber analyze \
  --pbom plumber-pbom.json \
  --pbom-cyclonedx plumber-cyclonedx-sbom.json

Quand utiliser chaque format ?

Format	Quand l'utiliser	Ce qu'il contient
PBOM natif	Vous voulez comprendre le pipeline en détail	Métadonnées riches propres à Plumber
CycloneDX	Vous voulez brancher un autre outil	Format standard pour Trivy, Grype ou Dependency-Track

Scanner le CycloneDX avec Trivy

trivy sbom plumber-cyclonedx-sbom.json --severity HIGH,CRITICAL

Scanner le CycloneDX avec Grype

grype sbom:plumber-cyclonedx-sbom.json --fail-on high

Remonter les findings dans les tableaux de bord sécurité

Le PBOM inventorie le pipeline ; pour faire remonter les écarts de conformité dans les plateformes, Plumber produit deux rapports de findings standardisés. Vous les générez en ajoutant un drapeau à plumber analyze.

--sarif écrit un rapport au format SARIF 2.1.0, consommé par GitHub Code Scanning (onglet Security du dépôt) et par le Security Dashboard de GitLab.
--glsast écrit un rapport GitLab SAST (gl-sast-report.json) qui alimente le Security Dashboard et le widget de merge request GitLab.

# Rapport SARIF — GitHub Code Scanning ou Security Dashboard GitLab
plumber analyze --sarif plumber.sarif

# Rapport SAST natif GitLab — widget de merge request
plumber analyze --glsast gl-sast-report.json

Dans un job GitLab manuel, déclarez le fichier produit comme artefact de rapport sast pour que GitLab l'affiche automatiquement dans la merge request :

plumber-scan:
  # ... un script qui lance « plumber analyze --glsast gl-sast-report.json »
  artifacts:
    reports:
      sast: gl-sast-report.json

Ces deux formats ne remplacent pas la lecture du résumé : ils servent à historiser les findings et à les rapprocher des autres scanners de sécurité déjà branchés sur vos tableaux de bord.

Aller plus loin après le premier scan

À ce stade, vous savez déjà lancer Plumber et lire les erreurs les plus utiles. Les fonctionnalités suivantes sont pratiques, mais elles ne doivent pas être votre point d'entrée.

Comprendre un code avec `plumber explain`

plumber explain ISSUE-412
# raccourci accepté : plumber explain 412

Cette commande renvoie la description du problème, son impact, la remédiation et le lien vers la documentation officielle. La 0.3 ajoute trois flags utiles :

# Liste compacte des 62 codes disponibles
plumber explain --list

# Référence exhaustive (description + remédiation pour chaque code)
plumber explain --all

# Sortie JSON, exploitable dans un script
plumber explain ISSUE-104 --json

Utiliser le score A-E

plumber analyze --score
plumber analyze --score-point

Sur Bob74/pipeline-craft, le scan de solution/lab-12 a produit :

Plumber Score: D
Final points: 34 / 100
Critical 0   High 6   Medium 6   Low 0

Le score sert à prioriser. Il ne remplace pas la lecture des contrôles en échec. La 0.3 introduit scoring-v3 avec des plafonds par code et des poids rééquilibrés : un même nombre d'issues ne produit plus mécaniquement la même note qu'auparavant.

Cibler seulement certains contrôles

# Uniquement les images et la protection de branche
plumber analyze --controls containerImageMustNotUseForbiddenTags,branchMustBeProtected

# Tout sauf la protection de branche
plumber analyze --skip-controls branchMustBeProtected

Commentaires de merge request et badges projet

Avec le composant GitLab, activez-les ainsi :

include:
  - component: gitlab.com/getplumber/plumber/plumber@v0.3.10
    inputs:
      mr_comment: true
      badge: true

Quand passer à la Platform ?

La Platform n'est pas le bon point de départ pour un débutant. Elle devient pertinente quand vous devez :

suivre plusieurs projets dans le temps ;
disposer d'un tableau de bord centralisé ;
gérer des politiques communes à plusieurs équipes ;
auditer des variables, des quotas ou des règles de merge request à plus grande échelle.

Annexe : les 62 codes d'issues par famille

La 0.3 documente 62 codes d'issues organisés en six familles, chacun avec une description et une remédiation accessibles via plumber explain ISSUE-XXX. Pour obtenir la liste à jour depuis votre installation, utilisez :

# Liste compacte (un code = une ligne)
plumber explain --list

# Référence complète (description + remédiation pour chaque code)
plumber explain --all

# Détail d'un code en JSON, exploitable dans un script
plumber explain ISSUE-104 --json

Le tableau ci-dessous donne la grille de lecture pour identifier rapidement la famille concernée par une issue remontée :

Famille	Plage	Couvre	Exemples
Sources et binaires	ISSUE-1XX (15 codes)	Images, actions, registries	ISSUE-101 source non autorisée, ISSUE-103 image non pinnée, ISSUE-104 action non SHA, ISSUE-107 FROM non pinné
Runtime et logs	ISSUE-2XX (12 codes)	Variables, injection, traces	ISSUE-203 debug trace, ISSUE-204 variable unsafe, ISSUE-206 template injection, ISSUE-209 `$GITHUB_ENV` écrit
Secrets et permissions	ISSUE-3XX (8 codes)	Tokens, `permissions:`, secrets	ISSUE-302 `secrets: inherit`, ISSUE-304 pas de `permissions:`, ISSUE-307 credentials persistés
Jobs et structure	ISSUE-4XX (14 codes)	Hardcoded jobs, includes, triggers	ISSUE-401 job hardcodé, ISSUE-404 include mutable, ISSUE-411 script non vérifié, ISSUE-412 DinD, ISSUE-414 trigger dangereux
Protection de branches	ISSUE-5XX (3 codes)	`branchMustBeProtected`	ISSUE-501 absence de protection, ISSUE-505 protection incomplète
Hygiène repo et workflows	ISSUE-6XX (10 codes)	Concurrency, OIDC, Dependabot	ISSUE-602 pas de `concurrency:`, ISSUE-605 publish sans OIDC, ISSUE-608 pas d'outil de mise à jour, ISSUE-610 pas de `SECURITY.md`

La famille 1XX est la plus dense et concentre la majorité des nouveautés du provider GitHub (codes 104 à 115). Les familles 3XX et 6XX sont quasi-exclusivement GitHub : elles couvrent ce que la CLI gh et l'écosystème Actions exposent comme surface de risque (secrets, OIDC, Dependabot, scanners CI).

Dépannage

Avant de parcourir le tableau, gardez en tête deux pièges propres à la 0.3 : la migration v1 → v2 est nécessaire dès que votre .plumber.yaml utilise encore le top-level controls:, et le provider GitHub s'appuie sur la CLI gh pour l'authentification (pas de variable d'environnement à exporter).

Symptôme	Cause probable	Solution
`configuration file not found`	Aucun `.plumber.yaml` présent pour la CLI	Créez le fichier avec `plumber config init` ou `plumber config generate`
`unknown key 'controls' at root`	Configuration encore au schéma v1	Lancez `plumber config migrate` pour passer au schéma v2.0
`GITLAB_TOKEN environment variable is required`	Variable manquante côté provider GitLab	Exportez `GITLAB_TOKEN` avant `plumber analyze`
`401 Unauthorized` (GitLab)	Token incomplet ou invalide	Vérifiez `read_api` + `read_repository` sur le token
Aucune authentification GitHub détectée	Pas de session `gh` active	Lancez `gh auth login` ; Plumber lit ensuite `~/.config/gh` automatiquement
`403 Forbidden on MR comment`	Scope insuffisant	Utilisez `api` si vous activez `mr_comment`
`403 Forbidden on badge`	Scope insuffisant ou rôle trop faible	Utilisez `api` et un rôle Maintainer
Le composant ne s'exécute pas	Job en `.pre` sans autre stage normal	Forcez `stage: test`
Deux pipelines sont créés sur le même push	`workflow:rules` absent	Ajoutez le bloc recommandé par GitLab
Le projet n'est pas auto-détecté	Remote Git absent ou mal nommé	Vérifiez le remote `origin` ou passez `--gitlab-url` / `--github-url` et `--project`

À retenir

Plumber 0.3 scanne désormais GitLab CI/CD et GitHub Actions depuis la même CLI
Le chemin débutant est simple : config init, config validate, plumber analyze
Le schéma v2.0 sépare les contrôles par provider (gitlab.controls: / github.controls:) ; plumber config migrate fait la conversion depuis la v1
L'auto-détection repose sur un remote origin pointant vers GitLab ou GitHub ; côté GitHub, l'authentification passe par la CLI gh
Commencez par corriger les images non épinglées, les actions non SHA, les includes mutables et les branches non protégées
Le composant GitLab est la meilleure intégration par défaut ; le job manuel vient ensuite
Le PBOM sert à inventorier le pipeline ; le CycloneDX facilite l'intégration avec Trivy et Grype
Les rapports --sarif et --glsast font remonter les findings dans GitHub Code Scanning et le Security Dashboard GitLab
Le score A-E (scoring-v3), plumber explain --list, les commentaires de MR et les badges sont utiles après le premier scan, pas avant
Gardez la Platform pour les besoins de gouvernance multi-projets

Prochaines étapes

CLI GitLab Configurer le token, explorer les projets et automatiser vos actions GitLab depuis le terminal.

Sécuriser les pipelines Voir les bonnes pratiques globales de durcissement et de gouvernance CI/CD.

Trivy Scanner vos images, vos fichiers SBOM et vos dépôts avec un outil simple à intégrer.

OWASP Top 10 CI/CD Comprendre les risques que Plumber aide à réduire dans les pipelines modernes.