Deux jeux de règles distincts, pas un seul
C'est le détail que la plupart des comparatifs sautent : l'hygiène Dockerfile et la sécurité des pipelines CI/CD sont deux catégories de règles distinctes avec des états par défaut différents. Se tromper là-dessus veut dire soit manquer une couverture qu'on pensait avoir, soit être surpris qu'un scan n'ait rien signalé.
Hygiène Dockerfile — active par défaut
Les règles Dockerfile générales vivent sous la catégorie SECURITY, activées dans chaque scan sans configuration :
| Règle | Sévérité | Ce qui est détecté |
|---|---|---|
| dockerfile_root_user | HIGH | Aucune directive USER — le conteneur s'exécute en root par défaut. |
| dockerfile_copy_all | MEDIUM | COPY . . embarque tout le contexte de build dans l'image, y compris .env, identifiants, clés SSH. |
| dockerfile_unpinned_base | MEDIUM | Image de base non épinglée à une version spécifique. |
Règles pipeline CI/CD — optionnelles, désactivées par défaut
C'est le point à préciser : les 38 règles qui inspectent le contenu de .github/workflows/*.yml et .gitlab-ci.yml — injection d'expression, scoping des permissions, actions non épinglées, et la règle ci-dessous — sont regroupées sous une catégorie CICD séparée, désactivée par défaut, de la même manière que le scan de dépendances nécessite --with-deps. Aucun flag CLI pour ça ; c'est un réglage de configuration.
À activer dans audit.config.json :
"categories": {
"cicd": { "enabled": true, "weight": 2 }
}À définir avant le premier scan d'un projet (ou vider le cache de règles avec --no-cache une fois si vous l'activez sur un projet déjà scanné) — puis lancer normalement.
| Règle | Sévérité | Ce qui est détecté |
|---|---|---|
| pull_request_target_checkout | HIGH | pull_request_target combiné à un checkout du head du fork — permet à une PR forkée d'exécuter du code avec accès en écriture et aux secrets. |
| unpinned_action_version | MEDIUM | Une action référencée par branche ou tag (@main, @v4) plutôt qu'un SHA de commit complet. |
| gha_missing_permissions | LOW | Le workflow n'a pas de bloc permissions: explicite, retombant sur un accès plus large que nécessaire. |
| docker_latest_tag | LOW | Une clé image: dans un YAML CI épinglée sur :latest — note : cela correspond à la clé YAML image:/from:, pas à une ligne FROM de Dockerfile (une règle différente, langage Dockerfile, pas incluse actuellement). |
| workflow_not_in_codeowners | LOW | Fichiers de workflow non couverts par une entrée CODEOWNERS, donc les changements de logique CI ne nécessitent pas de relecteur spécifique. |
38 règles au total dans cette catégorie — le tableau ci-dessus est un échantillon, pas la liste complète.
Un exemple réel, de bout en bout
on: pull_request_target
jobs:
build:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}on: pull_request
jobs:
build:
steps:
- uses: actions/checkout@v4Le correctif ici n'est pas un ajustement de paramètre — c'est un changement d'événement déclencheur. pull_request_target s'exécute avec les permissions et secrets du repo de base, même pour des PR forkées ; pull_request non. Si des opérations privilégiées sont réellement nécessaires après revue, la recommandation propre de la règle est de les séparer dans un job workflow_run distinct plutôt que d'ajouter une étape checkout au job pull_request_target.
Questions fréquentes
Pourquoi le scan CI/CD est-il optionnel plutôt qu'actif par défaut ?
La même raison que le scan de dépendances nécessite --with-deps : tous les projets n'ont pas de .github/workflows ou de .gitlab-ci.yml pour commencer, et scanner les fichiers YAML/pipeline par défaut sur chaque projet ne remonterait aucun finding (tout en coûtant du temps de scan) pour ceux qui n'utilisent pas de CI/CD du tout. L'activation à la demande garde le scan par défaut concentré sur le code source applicatif.
docker_latest_tag détecte-t-il la ligne FROM d'un Dockerfile ?
Non — son motif correspond à une clé YAML image: ou from: (la syntaxe utilisée dans les définitions de jobs .gitlab-ci.yml), pas à la ligne FROM node:latest d'un Dockerfile, qui n'a pas de deux-points après l'instruction. C'est une distinction réelle et vérifiée, pas une précaution ajoutée pour l'effet — les deux syntaxes sont assez différentes pour qu'un seul motif ne couvre pas les deux.
Activer CICD change-t-il aussi le scan des Dockerfile ?
Non — les règles d'hygiène Dockerfile (utilisateur root, COPY . ., image de base non épinglée) sont dans la catégorie SECURITY toujours active, indépendamment du réglage CICD. Activer CICD ajoute seulement les règles spécifiques au YAML de pipeline en plus.
Est-ce la même détection que le linting de workflow natif de GitHub ?
Non — l'outillage natif de GitHub vérifie la validité syntaxique du workflow. Ces règles vérifient des motifs spécifiques, connus comme dangereux (élévation de privilèges via pull_request_target, risque supply chain d'actions non épinglées) qu'un workflow syntaxiquement valide peut quand même contenir.
Le voir sur un vrai pipeline
Ouvrez le rapport de démonstration en ligne — sans installation, sans inscription — ou activez la catégorie CICD sur votre propre projet et scannez-le.
Ouvrir le rapport en ligne Voir la référence CLI