CINC Auditor : scanner la conformité de vos conteneurs

Comment être sûr qu'un serveur ou un conteneur est bien configuré selon vos règles de sécurité ? Les vérifier une à une à la main est long et vite oublié. L'idée de la conformité as code (compliance as code) : écrire ces règles une seule fois sous forme de tests, puis laisser un outil les rejouer automatiquement, autant de fois qu'on veut.

CINC Auditor est exactement cet outil, dans sa version libre et gratuite (c'est le build open source de Chef InSpec). Il audite une cible et indique, règle par règle, ce qui passe ou échoue face à un référentiel de sécurité reconnu : les CIS Benchmarks (les bonnes pratiques de durcissement de l'industrie) ou les STIG (les exigences plus strictes du département de la Défense américain).

Ce guide montre comment l'utiliser pour auditer des conteneurs : lancer un scan via le transport docker, écrire vos propres règles, rejouer un profil reconnu, et gérer le cas épineux des images distroless (sans shell). Public visé : DevSecOps et SRE, sans rien installer dans la cible.

Ce que vous allez apprendre

• Scanner un conteneur avec CINC Auditor en mode docker.
• Écrire un profil de contrôles de conformité.
• Rejouer un profil communautaire reconnu (dev-sec/linux-baseline).
• Contourner la limite des images distroless sans shell.

Prérequis

• Docker installé et fonctionnel.
• Aucune installation hôte : CINC Auditor tourne en conteneur.

Qu'est-ce que CINC Auditor

InSpec est un framework de compliance-as-code : on décrit l'état attendu d'un système dans un DSL lisible (« le port 22 ne doit écouter que sur l'interface d'admin », « /etc/shadow doit être en 0640 »), et l'outil audite la cible en produisant un rapport pass/fail. Depuis que Progress a relicencié InSpec sous une licence restrictive, la communauté maintient CINC Auditor, un rebuild strictement Apache-2.0 et compatible.

L'intérêt face à OpenSCAP (qui consomme des profils XCCDF/SCAP) : InSpec audite de l'extérieur, sans rien installer dans la cible, ce qui colle bien aux conteneurs. C'est un audit de posture de conformité, complémentaire d'un scanner de vulnérabilités comme Trivy : l'un vérifie comment c'est configuré, l'autre quelles failles sont présentes.

Scanner un conteneur via le transport docker

CINC Auditor cible un conteneur avec le transport docker:// : il shell-out vers la commande docker et exécute les contrôles dans la cible. L'image officielle contient cinc-auditor mais pas le client docker : on le lui fournit depuis l'hôte.

Préparez une cible de test (un nginx Debian, qui a un shell) :

docker run -d --name cible nginx:1.27-bookworm

Définissez l'image du scanner, épinglée par digest pour la reproductibilité :

AUDITOR="cincproject/auditor@sha256:14b1a2efb89ab141adb58e93c6c1bdcf196c9623498a292cbfaee28c46603568"

Lancez un premier scan avec un profil minimal (créé juste après) :

docker run --rm \
  -e CHEF_LICENSE=accept-silent \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$(command -v docker):/usr/bin/docker:ro" \
  -v "$PWD/profiles:/profiles:ro" \
  "$AUDITOR" exec /profiles/container-baseline \
  -t docker://cible --no-create-lockfile --reporter cli

Trois options qui bloquent si on les oublie

• CHEF_LICENSE=accept-silent : sans elle, le scan s'arrête sur l'acceptation de licence.
• montage du client docker : sans lui, -t docker:// ne peut pas shell-out vers le démon.
• --no-create-lockfile : le profil est monté en lecture seule ; InSpec échouerait à écrire inspec.lock (Errno::EROFS).

Écrire vos propres contrôles

Un profil InSpec est un dossier avec un inspec.yml et des contrôles dans controls/. Créez profiles/container-baseline/inspec.yml :

name: container-baseline
title: Baseline de conformité conteneur
maintainer: vous
license: Apache-2.0
version: 0.1.0
supports:
  - platform: os

Puis profiles/container-baseline/controls/baseline.rb avec quelques contrôles de durcissement. Chaque control porte un impact (de 0 à 1), un titre et des assertions describe :

control 'cnt-1.1-no-package-manager' do
  impact 0.7
  title "Pas de gestionnaire de paquets dans l'image finale"
  desc "Une image minimale réduit la surface d'attaque (esprit CIS Docker)."
  describe package('apt') do
    it { should_not be_installed }
  end
  describe package('apk') do
    it { should_not be_installed }
  end
end

control 'cnt-1.3-shadow-permissions' do
  impact 0.8
  title "/etc/shadow doit être protégé"
  describe file('/etc/shadow') do
    it { should exist }
    its('mode') { should cmp '0640' }
  end
end

Sur une image nginx Debian, le rapport montre un mélange réaliste : le contrôle cnt-1.1 échoue (apt est présent), tandis que cnt-1.3 passe. C'est exactement ce qu'on attend d'un audit : des findings exploitables, pas un simple « OK ».

Lire le résultat

Le rapport se termine par un Profile Summary (x successful controls, y control failures). Un contrôle est en échec dès qu'une de ses assertions échoue. Le code de sortie non nul de CINC Auditor permet de casser un pipeline CI quand la conformité régresse.

Rejouer un profil reconnu

Vous n'êtes pas obligé d'écrire tous les contrôles : la communauté dev-sec maintient des profils prêts à l'emploi. CINC Auditor sait récupérer un profil directement depuis une archive GitHub (épinglez le tag) :

docker run --rm \
  -e CHEF_LICENSE=accept-silent \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$(command -v docker):/usr/bin/docker:ro" \
  "$AUDITOR" exec \
  https://github.com/dev-sec/linux-baseline/archive/refs/tags/2.10.0.tar.gz \
  -t docker://cible --no-create-lockfile --reporter cli

Le profil linux-baseline déroule des dizaines de contrôles (sysctl, permissions, paquets sensibles). Sur un conteneur, beaucoup de contrôles noyau sont skippés (only_if), ce qui est normal : un conteneur partage le noyau de l'hôte. Vous gardez les contrôles filesystem et paquets, directement pertinents pour une image.

Le cas des images distroless

Les images distroless (Chainguard, gcr.io/distroless) n'ont ni shell ni coreutils. Le transport docker:// échoue alors à détecter la plateforme :

Train::PlatformDetectionFailed: Sorry, we are unable to detect your platform

InSpec a besoin d'utilitaires système dans la cible pour exécuter ses commandes. Deux contournements existent :

1. Mode filesystem : on déballe l'image (docker export) et on scanne le système de fichiers côté hôte, avec l'outillage de l'hôte plutôt que celui de la cible. C'est l'approche des scripts wrapper que Chainguard publie (chainguard-dev/chainguard-inspec), qui couvrent aussi le scan via procfs et la couche overlay2.

2. Bind-mount de BusyBox : on injecte BusyBox dans la cible pour fournir les utilitaires manquants au transport docker://.

L'image Chainguard CINC Auditor

Chainguard publie cgr.dev/chainguard/cinc-auditor, une image durcie qui embarque le profil GPOS SRG (dérivé des STIG DISA) et les wrappers de scan prêts à l'emploi. Pratique pour partir d'un référentiel STIG sans le reconstruire.

Auditer la config effective, pas juste le fichier

C'est l'avantage décisif de CINC Auditor sur les scanners qui se contentent de lire des fichiers. Sous Linux, la configuration appliquée par un service n'est pas celle de son fichier principal : elle résulte des Include, des drop-ins (/etc/ssh/sshd_config.d/*, *.service.d/) et des défauts du démon. Un contrôle qui lit /etc/ssh/sshd_config peut donc passer à tort alors qu'un drop-in réautorise root.

Prenez un conteneur dont le fichier dit PermitRootLogin no, mais avec un drop-in lu en premier qui le surcharge en yes. Deux contrôles, deux verdicts opposés :

# Façon "lecture de fichier" : rate le drop-in -> PASSE à tort
describe file('/etc/ssh/sshd_config') do
  its('content') { should match(/^PermitRootLogin\s+no/i) }
end

# Config effective : interroge ce que sshd applique vraiment -> attrape la surcharge
describe command('sshd -T') do
  its('stdout') { should match(/^permitrootlogin\s+no$/i) }
end

Le premier réussit (le fichier dit no), le second échoue : sshd -T résout les Include et drop-ins, et l'effectif est yes. Le réflexe : auditer la source résolue, jamais le seul fichier.

Brique	Commande de config effective
SSH	sshd -T
Noyau	sysctl -a (pas /etc/sysctl.conf)
systemd	systemctl show <unité>
Nginx / Apache	nginx -T / apachectl -S

Glissez pour voir

La limite des scanners basés sur des fichiers

Beaucoup de checks OVAL (le moteur d'OpenSCAP) inspectent des fichiers à des chemins fixes et ne résolvent pas ces surcharges. CINC Auditor, parce qu'il peut exécuter la commande de dump du service, audite ce qui tourne réellement, pas ce qui est écrit.

Quand choisir CINC Auditor

CINC Auditor n'est pas un scanner de vulnérabilités : c'est un auditeur de conformité. On le choisit quand :

• on doit prouver le respect d'un référentiel CIS ou STIG sur des conteneurs ou des serveurs ;
• l'écosystème de l'équipe est déjà InSpec (vs XCCDF/SCAP côté OpenSCAP) ;
• on veut des contrôles versionnés et testables, intégrés en CI.

Pour les vulnérabilités (CVE), associez-le à Trivy ou Grype. Pour le durcissement système de fond, voyez les CIS Benchmarks et OpenSCAP.

À retenir

• CINC Auditor est le build open source Apache-2.0 de Chef InSpec.
• Il audite la conformité (CIS, STIG) de l'extérieur, sans agent.
• Le transport docker:// scanne un conteneur, à condition de lui fournir le client docker et d'accepter la licence en silencieux.
• Les images distroless demandent un mode filesystem ou un BusyBox injecté.
• C'est un audit de posture, complémentaire d'un scanner de vulnérabilités.

Prochaines étapes

Trivy Scanner de vulnérabilités, secrets et IaC pour vos images

CIS Benchmarks Les référentiels de durcissement que CINC peut auditer

OpenSCAP L'alternative XCCDF/SCAP pour l'audit de conformité

Sécurité des conteneurs Le parcours complet : images, clusters, runtime

×

📖 Voir la documentation →