Sélectionnez Dockerfile, GitHub Actions ou Kubernetes et collez la configuration. Examinez les lignes ou champs signalés concernant les versions d’images, les permissions et les paramètres d’exécution de votre environnement.
Fonctionne localement dans votre navigateurLes règles sont intentionnellement conservatrices. Examinez chaque résultat par rapport à l'image, à la stratégie de cluster, aux autorisations de flux de travail et à l'environnement que vous utilisez réellement.
Choisissez Dockerfile, GitHub Actions ou Kubernetes, collez la configuration ou chargez-la depuis un fichier, puis lancez l’analyse. La page signale les lignes et les champs qui posent problème dans votre texte : images et actions non épinglées, permissions de jeton trop larges, conteneurs privilégiés et durcissement d’exécution absent.
Le jeu de règles s’exécute dans la page. Pendant les tests, l’analyse n’a envoyé aucune requête : la configuration reste dans le navigateur et la vérification continue de fonctionner sans réseau.
Une commande RUN poursuivie par une barre oblique inverse est évaluée comme une seule instruction : apt-get install … && rm -rf /var/lib/apt/lists/* n’est pas signalé (les listes disparaissent dans la même couche), alors qu’une installation qui ne les supprime jamais l’est. La même passe repère le tube curl … | sh même lorsque le tube se trouve à la ligne suivante.
Les autres contrôles portent sur l’image de base (latest, ou sans tag ni digest — scratch excepté), un FROM absent, USER root ou 0:0, un USER absent, ADD là où COPY suffirait, COPY . . sans .dockerignore et les noms évoquant un secret dans ENV ou ARG.
Les contrôles du workflow examinent les déclencheurs pull_request_target, les permissions du GITHUB_TOKEN déclarées au niveau du workflow ou du job (write-all est signalé), les actions tierces épinglées à un SHA de commit et les téléchargements envoyés directement dans un shell. Les actions locales (./chemin) et les références docker:// ne se voient pas demander de version : il n’y a aucun commit à épingler.
Les contrôles du manifeste couvrent apiVersion, kind ou nom absents, les types de Service qui exposent la charge au-delà du cluster, le partage de namespaces de l’hôte, les images non épinglées ou latest, les conteneurs privilégiés, allowPrivilegeEscalation activé, readOnlyRootFilesystem non défini, runAsNonRoot non défini aux deux niveaux, et l’absence de requests et limits CPU et mémoire. Un wrapper kind: List est ouvert et ses éléments sont vérifiés un par un.
Le jeu de règles est volontairement conservateur et cherche des erreurs pratiques courantes, pas une conformité complète. Il n’analyse pas les images, ne résout pas les politiques d’admission et ne remplace pas un moteur de politiques CI : un rapport sans constat signifie que ces règles précises n’ont rien trouvé, pas que la configuration est sûre.
Les constats sont des heuristiques sur le texte collé : confrontez chacun à l’image, à la politique du cluster et aux permissions réellement utilisées. Un YAML multi-documents est découpé sur les lignes --- en colonne 0, et le JSON est accepté partout où le YAML l’est.