Comment auditer la securite de vos registres container open source en 7 etapes

Les registres container sont devenus l'epine dorsale de la livraison logicielle moderne. Chaque equipe DevOps pousse des dizaines d'images Docker par semaine vers un registre — qu'il s'agisse de Docker Hub, du registre integre de Gitea, de Harbor, du GitLab Container Registry ou d'un Docker Registry auto-heberge. Mais combien d'equipes auditent reellement la securite de ces registres ? La reponse, comme l'a demontre la recente CVE-2026-27771 dans Gitea qui a expose 30 000 serveurs pendant 4 ans, est : pas assez.

Ce guide vous donne les 7 etapes concretes pour auditer la securite de vos registres container open source, avec des commandes prets a copier-coller et des exemples pour chaque registre majeur. Que vous geriez un registre Gitea pour une PME a Lyon, un Harbor pour un cluster Kubernetes a Paris, ou un GitLab Container Registry pour une ESN a Toulouse, ces etapes s'appliquent a votre contexte. L'objectif est de transformer un audit ponctuel en un processus reproductible que vous pourrez integrer dans votre cycle de securite trimestriel.

Etape 1 : Dresser l'inventaire de vos registres et versions

Avant de pouvoir securiser quoi que ce soit, vous devez savoir exactement ce que vous avez. La premiere etape est de recenser tous les registres container utilises dans votre organisation, y compris ceux deployes de maniere informelle par des equipes individuelles. C'est souvent la que les mauvaises surprises se cachent : un Harbor installe par un stagiaire il y a 2 ans, un registre Gitea active « pour tester » et jamais desactive, ou un Docker Registry lance en Docker Compose sans TLS ni authentification.

# Inventaire des registres sur votre reseau
# 1. Scanner les ports standard des registres container
nmap -sV -p 5000,5001,8080,3000,443 --open 10.0.0.0/16

# 2. Verifier les versions de chaque registre detecte
# Gitea
curl -s https://gitea.example.com/api/v1/version | jq .version

# Harbor
curl -s https://harbor.example.com/api/v2.0/systeminfo | jq .harbor_version

# GitLab Container Registry (via GitLab API)
curl -s --header "PRIVATE-TOKEN: $TOKEN" \
  https://gitlab.example.com/api/v4/version | jq .version

# Docker Registry standalone
curl -s https://registry.example.com/v2/ | jq .

Documentez chaque registre dans un tableau avec : URL, version, type (Gitea, Harbor, GitLab, Docker Registry), nombre d'images hebergees, equipes utilisatrices, et date de derniere mise a jour. Ce document sera votre reference pour les 6 etapes suivantes et deviendra un livrable precieux pour la conformite NIS2/DORA.

Etape 2 : Tester les controles d'acces (le test du pull anonyme)

C'est le test le plus important de l'audit, et aussi le plus simple. L'objectif est de verifier que les images marquees comme privees ne sont pas accessibles sans authentification. C'est exactement cette verification qui aurait permis de detecter CVE-2026-27771 dans Gitea des sa premiere apparition il y a 4 ans.

# Test du pull anonyme — a executer depuis une machine EXTERNE
# Sans aucun docker login prealable

# Gitea
docker pull gitea.example.com/org/private-image:latest
# Attendu : "unauthorized: authentication required"
# ALERTE si : le pull reussit

# Harbor
docker pull harbor.example.com/project/private-image:latest
# Attendu : "unauthorized: authentication required"

# GitLab Container Registry
docker pull registry.gitlab.example.com/group/project/image:latest
# Attendu : "unauthorized: authentication required"

# Docker Registry standalone
docker pull registry.example.com/private-image:latest
# Attendu : "no basic auth credentials"

# Test supplementaire : enumerer les depots sans auth
curl -s https://registry.example.com/v2/_catalog
# Attendu : 401 Unauthorized
# ALERTE si : la liste des depots est retournee

Pour chaque registre, testez depuis trois emplacements : le reseau interne, un VPN, et Internet public. Un registre qui bloque les pulls anonymes depuis Internet mais les autorise depuis le reseau interne n'est que partiellement securise — une compromission d'un poste de travail ou d'un runner CI suffirait pour exfiltrer les images. Pour aller plus loin sur la securisation des runners, consultez notre guide sur la securisation des pipelines CI/CD open source.

Etape 3 : Auditer les politiques RBAC et les tokens d'acces

Meme si vos registres exigent une authentification, la question suivante est : qui a acces a quoi ? Un modele RBAC (Role-Based Access Control) mal configure peut donner a un stagiaire les memes permissions qu'un lead DevOps, ou permettre a un token CI/CD de lire toutes les images de l'organisation alors qu'il n'a besoin que d'une seule.

# Auditer les tokens d acces — exemples par registre

# Harbor : lister les comptes robot et leurs permissions
curl -s -u admin:$HARBOR_PASS \
  https://harbor.example.com/api/v2.0/robots | \
  jq '.[] | {name, permissions: .permissions[].access}'

# Gitea : verifier les tokens avec acces au registre
curl -s -H "Authorization: token $GITEA_TOKEN" \
  https://gitea.example.com/api/v1/user/tokens | \
  jq '.[] | select(.name | contains("registry") or contains("package"))'

# GitLab : auditer les deploy tokens
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  https://gitlab.example.com/api/v4/groups/$GROUP_ID/deploy_tokens | \
  jq '.[] | {name, scopes, expires_at}'

# Verifier les tokens expires mais toujours actifs
# C est une source frequente de comptes orphelins

Points critiques a verifier lors de l'audit RBAC :

• Principe du moindre privilege : chaque token ne doit avoir que les permissions strictement necessaires (pull uniquement pour les deploiements, push uniquement pour la CI)
• Expiration des tokens : tout token sans date d'expiration est un risque. Configurez une rotation automatique tous les 90 jours maximum
• Comptes orphelins : les tokens de collaborateurs ayant quitte l'organisation doivent etre revoques immediatement
• Tokens partages : un token utilise par plusieurs pipelines CI est un SPOF (Single Point of Failure) de securite. Creez un token par pipeline

Etape 4 : Scanner toutes les images pour vulnerabilites connues

Un registre container securise au niveau acces mais contenant des images vulnerables est un faux sentiment de securite. L'etape 4 consiste a scanner l'integralite de vos images pour identifier les vulnerabilites connues (CVE), les paquets obsoletes et les configurations dangereuses.

# Scanner avec Trivy — le couteau suisse de l audit container

# Scanner une image specifique
trivy image gitea.example.com/org/app:latest

# Scanner toutes les images d un registre Harbor
trivy registry harbor.example.com --severity HIGH,CRITICAL

# Scanner avec rapport JSON pour integration CI/CD
trivy image --format json --output report.json \
  registry.example.com/app:latest

# Scanner avec Grype (alternative rapide)
grype registry.example.com/app:latest --scope all-layers

# Generer un SBOM (Software Bill of Materials) avec Syft
syft packages registry.example.com/app:latest -o spdx-json > sbom.json

# Script pour scanner en masse toutes les images d un registre
for repo in $(curl -s https://registry.example.com/v2/_catalog | jq -r '.repositories[]'); do
  for tag in $(curl -s "https://registry.example.com/v2/$repo/tags/list" | jq -r '.tags[]' 2>/dev/null); do
    echo "=== Scanning $repo:$tag ==="
    trivy image --severity HIGH,CRITICAL "registry.example.com/$repo:$tag"
  done
done

Pour chaque image, focalisez-vous sur les vulnerabilites critiques et hautes avec un fix disponible. Les CVE sans fix ne sont pas actionnables immediatement, mais doivent etre documentees et surveillees. Generez un rapport consolide avec le nombre de CVE critiques, hautes, moyennes et basses par image, et priorisez la remediation sur les images de production actives.

Etape 5 : Detecter les secrets embarques dans les images

C'est l'etape la plus sous-estimee, et pourtant la plus critique en cas de breach. Comme l'a demontre CVE-2026-27771, quand un registre est compromis, ce sont les secrets embarques dans les images qui causent les degats les plus graves : cles API, tokens d'acces, certificats TLS, mots de passe de bases de donnees, et cles privees SSH.

# Detecter les secrets avec Trivy (mode secret scan)
trivy image --scanners secret registry.example.com/app:latest

# Detecter avec gitleaks (analyse de chaque layer)
docker save registry.example.com/app:latest | \
  tar -xf - -C /tmp/image-layers/ && \
  gitleaks detect --source /tmp/image-layers/ --report-format json

# Detecter avec ggshield (GitGuardian)
ggshield secret scan docker registry.example.com/app:latest

# Verifier les variables d environnement embarquees
docker inspect registry.example.com/app:latest | \
  jq '.[0].Config.Env[]' | \
  grep -iE "key|secret|token|password|api|auth"

# Verifier l historique des layers pour les fichiers supprimes
# (les secrets supprimes dans un layer ulterieur restent dans les layers precedents)
docker history --no-trunc registry.example.com/app:latest | \
  grep -iE "COPY|ADD|ENV|ARG" | head -20

Un point crucial souvent oublie : meme si un secret a ete « supprime » dans un layer Docker ulterieur, il reste accessible dans les layers precedents. L'architecture en couches de Docker conserve chaque modification comme un layer independant. Un attaquant peut extraire chaque layer individuellement et recuperer les fichiers « supprimes ». C'est pourquoi le scan doit couvrir tous les layers, pas seulement le layer final.

Etape 6 : Durcir la configuration reseau et la defense en profondeur

Le controle d'acces applicatif est votre premiere ligne de defense, mais il ne doit pas etre la seule. L'etape 6 consiste a mettre en place une defense en profondeur autour de votre registre container, avec des couches de securite reseau supplementaires qui protegent meme en cas de bypass d'authentification (exactement le scenario de CVE-2026-27771).

# Exemple de configuration NGINX reverse proxy pour un registre container
# Ajoute une couche d authentification et de filtrage supplementaire

upstream registry_backend {
    server 127.0.0.1:5000;  # Registre ecoute uniquement sur localhost
}

server {
    listen 443 ssl http2;
    server_name registry.example.com;

    ssl_certificate /etc/ssl/certs/registry.pem;
    ssl_certificate_key /etc/ssl/private/registry.key;

    # Rate limiting pour prevenir les scans massifs
    limit_req_zone $binary_remote_addr zone=registry:10m rate=10r/s;

    # Restreindre les IP sources autorisees
    allow 10.0.0.0/8;      # Reseau interne
    allow 172.16.0.0/12;   # Runners CI/CD
    deny all;               # Bloquer tout le reste

    location /v2/ {
        limit_req zone=registry burst=20 nodelay;

        # Authentification basique supplementaire
        auth_basic "Container Registry";
        auth_basic_user_file /etc/nginx/registry.htpasswd;

        proxy_pass http://registry_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Log tous les pulls pour audit
        access_log /var/log/nginx/registry-access.log combined;
    }
}

Points cles du durcissement reseau :

• Le registre ne doit jamais ecouter sur 0.0.0.0. Configurez-le pour ecouter uniquement sur 127.0.0.1 et placez un reverse proxy devant
• Restreignez les IP sources aux seuls reseaux qui ont legitimement besoin d'acceder au registre (runners CI, postes developpeurs, clusters Kubernetes)
• Activez le rate limiting pour prevenir les scans massifs et les tentatives de brute force
• TLS obligatoire — ne deployez jamais un registre en HTTP, meme en reseau interne. Les attaques MITM sont triviales sur un reseau non segmente
• Loggez tous les acces vers l'API /v2/ pour pouvoir auditer les pulls et detecter les comportements suspects

Etape 7 : Mettre en place le monitoring continu et les alertes

Un audit ponctuel ne suffit pas. La securite de vos registres container doit etre surveillee en continu pour detecter les nouvelles vulnerabilites, les acces suspects et les regressions de configuration. L'etape 7 transforme votre audit en un processus permanent.

# 1. Scan quotidien des nouvelles CVE dans vos images
# Ajouter dans votre crontab ou pipeline CI
0 6 * * * trivy image --severity CRITICAL,HIGH \
  registry.example.com/app:latest 2>&1 | \
  mail -s "[SECURITY] Scan container quotidien" team@example.com

# 2. Alerting Prometheus/Grafana pour les pulls suspects
# prometheus-alerting-rules.yml
groups:
  - name: container-registry-security
    rules:
      - alert: RegistryUnauthorizedPull
        expr: increase(registry_http_requests_total{method="GET",code="200",handler="/v2/*/manifests/*"}[5m]) > 50
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Pull massif detecte sur le registre container"

      - alert: RegistryAuthFailures
        expr: increase(registry_http_requests_total{code="401"}[5m]) > 20
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Tentatives d authentification echouees sur le registre"

# 3. Webhook de notification pour les nouvelles images poussees
# Harbor : configurer un webhook dans Project > Webhooks
# Gitea : configurer un webhook dans Settings > Webhooks
# Chaque push declenche un scan automatique

Pour les equipes qui utilisent Harbor, activez la fonctionnalite de scan automatique a chaque push — Harbor integre nativement Trivy et peut bloquer le pull d'images avec des CVE critiques non resolues. Pour GitLab, activez le Container Scanning dans votre fichier .gitlab-ci.yml. Pour Gitea, integrez Trivy dans votre pipeline CI via GitHub Actions ou Gitea Actions.

Enfin, mettez en place une politique de retention pour supprimer automatiquement les images obsoletes. Les images non utilisees depuis plus de 90 jours et les tags non semver (comme :test, :debug, :fix-lucas) sont des candidats a la suppression. Moins d'images dans votre registre signifie moins de surface d'attaque et des scans plus rapides.

Checklist recapitulative

Voici la checklist complete a utiliser pour chaque audit trimestriel de vos registres container. Cochez chaque point et documentez les resultats pour votre equipe et pour la conformite reglementaire.

1. Inventaire complet : tous les registres recenses avec version, type, nombre d'images, equipes utilisatrices
2. Test du pull anonyme : aucune image privee accessible sans authentification depuis 3 emplacements (interne, VPN, Internet)
3. RBAC audit : tokens avec moindre privilege, rotation < 90 jours, comptes orphelins revoques, pas de tokens partages
4. Scan de vulnerabilites : toutes les images de production scannees, zero CVE critique avec fix disponible
5. Detection de secrets : scan de tous les layers, rotation des secrets detectes, Dockerfiles audites
6. Defense en profondeur : reverse proxy, restriction IP, TLS, rate limiting, logging
7. Monitoring continu : scan quotidien, alerting sur pulls suspects, webhook de notification, politique de retention

FAQ