Sécurité des images de conteneurs pour la défense : durcissement, analyse et intégrité de la chaîne d'approvisionnement

Par l'équipe d'ingénierie Corvus Intelligence · À propos de l'équipe →

25 juin 2026 11 min de lecture

Les images de conteneurs sont l'unité atomique de la livraison logicielle de défense moderne. Chaque charge de travail s'exécutant sur des clusters Kubernetes de défense — applications de mission, pipelines de données, services d'inférence IA — arrive sous la forme d'une image immuable qui a été construite quelque part, à partir de quelque chose. La sécurité de tout ce qui se trouve en aval dépend de l'intégrité de cette chaîne de construction. Dans les environnements d'entreprise, une image de conteneur compromise constitue un incident grave. Dans un environnement de défense classifié, il s'agit d'un vecteur potentiel de collecte de renseignements, d'un mécanisme de persistance pour un acteur étatique, ou du point d'entrée de capacités destructrices ciblant des infrastructures liées aux armements.

Cet article couvre l'intégralité du cycle de vie de la sécurité des images de conteneurs pour la défense : sélection et validation des images de base conformes aux STIG, durcissement des constructions avec des Dockerfiles multi-étapes, exécution de l'analyse des vulnérabilités dans des pipelines CI/CD en environnement isolé, signature des images avec Cosign/Sigstore dans des environnements déconnectés, génération de SBOM pour les packages ATO, et application des contrôles d'intégrité de registre dans Harbor. Ce contenu s'adresse aux ingénieurs de plateforme et aux architectes de sécurité travaillant sur des systèmes de défense classifiés ou sensibles.

Pourquoi la sécurité des images de conteneurs est plus critique en défense qu'en entreprise

Dans une entreprise commerciale, une image de conteneur vulnérable ou compromise représente un risque de violation de données, une perturbation opérationnelle et une responsabilité réglementaire. Dans un environnement de défense classifié, les conséquences s'étendent à l'exposition des sources et méthodes, à la compromission de la mission, et à des effets cinétiques sur des systèmes qu'une vulnérabilité logicielle pourrait permettre à un adversaire de contrôler ou de neutraliser. Le modèle de menace est qualitativement différent : l'adversaire n'est pas un groupe criminel motivé financièrement, mais un État-nation disposant d'opérations d'accès persistant et de la patience d'attendre des années pour le bon moment d'activer une capacité implantée.

Les attaques sur la chaîne d'approvisionnement des conteneurs exploitent la nature en couches des images de conteneurs. Une image d'application de mission typique peut être construite FROM une image de base OS, qui installe des paquets d'exécution depuis un dépôt de paquets, qui à leur tour incluent des dépendances transitives tirées au moment de la construction depuis des registres de paquets de langages en amont. L'adversaire n'a pas besoin de compromettre les systèmes internes du contractant de défense — compromettre une dépendance à trois niveaux de profondeur dans cette chaîne produit le même effet. Les incidents SolarWinds et XZ Utils ont démontré que ce modèle de menace n'est pas théorique ; les deux étaient des insertions dans la chaîne d'approvisionnement qui auraient été techniquement indétectables sans des contrôles approfondis de la chaîne d'approvisionnement.

Les environnements de défense ajoutent trois exigences qui rendent la sécurité des images de conteneurs considérablement plus complexe sur le plan opérationnel que dans les environnements d'entreprise :

Exigences d'isolement réseau. Les réseaux classifiés ne peuvent pas extraire des images depuis des registres internet au moment de l'exécution. Chaque dépendance d'image doit être pré-approuvée, pré-analysée et dupliquée dans un registre interne avant de pouvoir être utilisée — ce qui signifie que la frontière de la chaîne d'approvisionnement est un périmètre dur que les équipes d'ingénierie possèdent et dont elles sont entièrement responsables.
Exigences d'autorisation formelle. Les logiciels fonctionnant sur des systèmes classifiés doivent compléter un processus d'Autorisation à Opérer (ATO), qui exige une provenance documentée pour chaque composant logiciel. La génération de SBOM et la signature d'images passent de pratiques d'hygiène optionnelles à des livrables obligatoires de preuves ATO.
Application de l'infrastructure immuable. Les plateformes de défense imposent de plus en plus qu'aucune modification en cours d'exécution des images de conteneurs ne soit autorisée : les conteneurs sont détruits et remplacés, jamais corrigés en place. Cela signifie que la posture de sécurité d'une charge de travail déployée est définitivement fixée au moment de la construction de l'image, ce qui rend le durcissement et les portes d'analyse au moment de la construction non négociables plutôt que relevant du meilleur effort.

Images de base conformes aux STIG

DISA (Defense Information Systems Agency) publie des Security Technical Implementation Guides (STIG) pour les systèmes d'exploitation et les plateformes utilisés dans les environnements de défense. Pour les charges de travail conteneurisées, les plus significatifs sur le plan opérationnel sont le STIG RHEL 8 et le STIG RHEL 9, qui s'appliquent aux dérivés de Red Hat Universal Base Image (UBI) — les images de base les plus couramment utilisées dans les plateformes de conteneurs de défense, y compris le référentiel d'images durcies Iron Bank de DoD Platform One.

Le STIG RHEL applique des contrôles dans plusieurs catégories qui diffèrent sensiblement d'une installation OS par défaut :

Paramètres noyau (sysctl). Transfert IP désactivé par défaut (net.ipv4.ip_forward=0), redirections ICMP rejetées, cookies TCP SYN activés et espace d'adressage virtuel aléatoire (ASLR) appliqué. Ces contrôles réduisent l'exposition de l'OS en tant que relais réseau et rendent l'exploitation de la mémoire plus difficile.
Configuration PAM. Règles de complexité des mots de passe (longueur minimale, classes de caractères), verrouillage de compte après des tentatives d'authentification échouées et exigences d'enregistrement de session. Pour les comptes de service de conteneurs utilisant une authentification par clé ou par jeton, certains de ces contrôles peuvent nécessiter des exceptions documentées.
Règles auditd. Le STIG spécifie un ensemble complet de règles auditd couvrant l'accès au système de fichiers vers des chemins sensibles, l'utilisation de commandes d'escalade de privilèges (sudo, su), la modification des bases de données d'utilisateurs et de groupes, les modifications de configuration réseau et le chargement de modules du noyau. Dans un contexte de conteneur, auditd s'exécute généralement sur le noyau hôte et s'applique à tous les conteneurs — les règles STIG doivent être appliquées au niveau du nœud, pas par conteneur.
Politique cryptographique FIPS 140. Le STIG exige que la politique cryptographique à l'échelle du système soit définie sur FIPS ou FIPS:OSCP, ce qui désactive TLS 1.0/1.1, MD5, SHA-1 pour les signatures, RC4 et DES/3DES. Les composants d'application qui dépendent d'algorithmes obsolètes échoueront sous la politique cryptographique FIPS — c'est un problème d'intégration courant découvert tardivement dans les projets de durcissement lorsque l'image de base STIG est validée contre les suites de tests d'application.

Iron Bank (le registre de conteneurs durcis de Platform One) publie des images pré-durcies qui ont été validées par rapport aux STIG de DISA, analysées pour les vulnérabilités et signées. Pour les programmes déjà sur Platform One, construire FROM une image de base Iron Bank est l'approche la plus pratique : elle fournit une base de référence documentée et pré-autorisée qui satisfait aux exigences d'image de base de la plupart des ATO. Pour les programmes n'étant pas sur Platform One, la construction et la validation indépendantes de la conformité STIG à l'aide d'OpenSCAP (oscap-docker ou oscap contre un système de fichiers de conteneur exporté) est le processus équivalent.

# Valider le système de fichiers d'une image de conteneur par rapport au STIG RHEL 9
# Exporter le système de fichiers de l'image dans un répertoire temporaire
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# Exécuter OpenSCAP contre le système de fichiers exporté
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/stig-results.xml \
  --report /tmp/stig-report.html \
  --chroot /tmp/image-fs \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Durcissement par construction multi-étapes

Les constructions Docker multi-étapes sont la technique individuelle la plus efficace pour réduire la surface d'attaque des images de conteneurs. Le principe est simple : utiliser une ou plusieurs étapes de construction intermédiaires contenant tous les outils nécessaires à la compilation et au packaging de l'application, et ne copier que les artefacts compilés dans une étape d'exécution finale qui ne contient rien dont l'application n'a pas besoin pour fonctionner. Une application C++ construite dans une étape contenant gcc, make, cmake et des en-têtes de développement produit une image finale ne contenant que le binaire et ses bibliothèques partagées d'exécution.

# Étape 1 : construction — chaîne d'outils complète, absente de l'image finale
FROM registry.mil/ironbank/redhat/ubi/ubi9:latest AS builder
RUN dnf install -y gcc make cmake openssl-devel && dnf clean all
WORKDIR /build
COPY src/ .
RUN cmake -DCMAKE_BUILD_TYPE=Release . && make -j$(nproc)

# Étape 2 : exécution — base minimale, sans outils de construction
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Utilisateur non-root — exigence de durcissement STIG et NSA
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

Pour les applications Go ou Rust compilées de manière statique, l'étape finale peut être scratch — une image complètement vide ne contenant que le binaire. Cela élimine entièrement la couche OS, supprimant toutes les vulnérabilités au niveau OS de la surface de détection du scanner. Les capacités de compilation croisée et de liaison statique de la bibliothèque standard Go rendent les images scratch pratiques pour une large classe de microservices de défense sans complexité de construction supplémentaire.

Lorsque l'application nécessite un shell ou des utilitaires OS à l'exécution (débogage en développement, scripts de vérification de l'état, logique d'initialisation), les images gcr.io/distroless offrent un compromis : une base Debian ou Alpine minimale contenant uniquement le runtime du langage et la bibliothèque C, sans shell, sans gestionnaire de paquets et sans utilitaires système. Les images distroless sont maintenues par Google et publiées avec les résultats d'analyse des vulnérabilités ; les programmes de défense utilisant distroless doivent dupliquer ces images dans leur registre interne et conserver leurs propres enregistrements d'évaluation des vulnérabilités.

L'application de l'utilisateur non-root est une exigence de durcissement dans le Guide de durcissement Kubernetes de la NSA et dans le STIG. L'instruction USER dans le Dockerfile définit l'utilisateur par défaut pour toutes les commandes suivantes et pour le point d'entrée du conteneur. Utilisez un UID numérique (pas un utilisateur nommé) pour éviter la dépendance au fichier /etc/passwd, et choisissez un UID supérieur à 10000 pour éviter les conflits avec les plages d'utilisateurs système. Les contrôleurs d'admission appliquant le profil restricted de Pod Security rejetteront les pods où runAsNonRoot n'est pas vrai ou où un conteneur déclare runAsUser: 0.

Analyse des vulnérabilités dans les pipelines CI/CD classifiés

L'analyse des vulnérabilités est la porte qualité qui empêche les images contenant des CVE exploitables connus d'atteindre les déploiements classifiés. Deux scanners open source dominent les implémentations de plateformes de conteneurs de défense : Trivy (Aqua Security) et Grype (Anchore). Les deux prennent en charge le fonctionnement hors ligne — une exigence non négociable pour les environnements de CI/CD en réseau isolé pour la défense.

Le mode hors ligne de Trivy nécessite que la base de données des vulnérabilités soit pré-téléchargée et transférée vers l'environnement isolé. La base de données couvre les paquets OS (RPM, DEB, APK), les paquets d'écosystèmes de langages (pip, npm, Maven, modules Go, Cargo) et les signatures binaires d'application. Le flux de travail de transfert utilisant des supports amovibles ou une solution inter-domaines doit être intégré dans les opérations régulières de l'équipe en tant que tâche planifiée — une base de données obsolète (datant de plus de 14 jours) est un constat courant dans les évaluations de sécurité des environnements classifiés.

# Sur le système connecté (face internet) — télécharger la base Trivy
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# Transférer /transfer/trivy-cache vers le système isolé via support approuvé

# Sur le runner CI/CD isolé — analyser l'image avec la base locale
trivy image \
  --skip-update \
  --cache-dir /opt/trivy-cache \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --ignore-unfixed \
  --format json \
  --output /artifacts/scan-results.json \
  registry.classified.mil/myapp@sha256:abc123...

# Équivalent Grype — désactiver la mise à jour auto, pointer vers la base locale
GRYPE_DB_AUTO_UPDATE=false \
GRYPE_DB_CACHE_DIR=/opt/grype-db \
grype registry.classified.mil/myapp@sha256:abc123... \
  --fail-on critical \
  --output json > /artifacts/grype-results.json

Les portes de politique d'analyse définissent quels résultats bloquent une construction de pipeline par rapport à la génération d'avertissements. Une politique de porte défendable pour les environnements classifiés :

Bloquer (le pipeline échoue, l'image n'est pas poussée) : toute CVE de sévérité CRITICAL, toute CVE de sévérité HIGH dans une dépendance directe avec un sous-score d'exploitabilité CVSS supérieur à 7,0 ou un score EPSS supérieur à 0,05.
Avertir et exiger une dérogation : CVE de sévérité HIGH dans des dépendances transitives, CVE de sévérité HIGH sans correctif fournisseur disponible, CVE de sévérité MEDIUM.
Informatif uniquement : résultats LOW et NEGLIGIBLE, CVE affectant des composants qui ne sont manifestement pas accessibles dans le chemin d'exécution de l'application.

Chaque dérogation doit être un document signé et limité dans le temps reliant l'identifiant CVE, la justification (pas de correctif disponible, composant non accessible, contrôle compensatoire), l'agent de sécurité approbateur et une date d'expiration déclenchant une réévaluation. Les dérogations stockées sous forme de fichiers YAML révisés par code dans le dépôt CI/CD fournissent un enregistrement auditable qui satisfait aux exigences de preuves ATO.

Signature d'images avec Cosign/Sigstore en environnements déconnectés

La signature d'images fournit une preuve cryptographique qu'une image de conteneur spécifique — identifiée par son condensé de contenu SHA-256 — a été produite par un pipeline autorisé et n'a pas été modifiée depuis la signature. Cosign (partie du projet Sigstore de la Linux Foundation) est devenu l'outil standard de signature d'images pour les environnements de conteneurs, produisant des signatures compatibles OCI stockées en tant qu'artefacts dans le même registre que l'image.

Le flux de signature sans clé de Sigstore utilise des jetons d'identité OIDC et une infrastructure publique (CA Fulcio et journal de transparence Rekor) pour signer des images sans gérer de clés privées à longue durée de vie. Ce modèle convient bien aux pipelines CI/CD open source publics mais nécessite un accès internet à l'infrastructure publique Sigstore — incompatible avec les environnements classifiés isolés. Les environnements déconnectés disposent de deux options pratiques :

Signature avec clé (recommandée pour le classifié). Générer une paire de clés Cosign ; stocker la clé privée dans un HSM ou un gestionnaire de secrets approuvé (HashiCorp Vault avec backend validé FIPS, AWS CloudHSM ou Azure Dedicated HSM). L'étape de signature dans le pipeline CI/CD récupère la référence de clé et signe le condensé d'image. La clé publique est distribuée aux contrôleurs d'admission pour vérification. Aucune infrastructure externe n'est requise.
Instance Sigstore privée. Déployer Fulcio et Rekor à l'intérieur du réseau classifié. Cela fournit l'expérience utilisateur sans clé et les avantages du journal de transparence mais nécessite l'exploitation d'une infrastructure supplémentaire, y compris un fournisseur d'identité OIDC interne. Approprié pour les grands programmes avec des équipes d'ingénierie de plateforme dédiées.

# Générer une paire de clés Cosign (exécuter une fois, stocker la clé privée dans HSM/Vault)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Signer l'image après le passage des portes d'analyse — référencer l'image par condensé, pas par tag
IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myapp:v1.2.3)
cosign sign \
  --key awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def \
  --tlog-upload=false \
  registry.classified.mil/myapp@${IMAGE_DIGEST}

# Vérifier la signature (utilisé par les contrôleurs d'admission et lors des audits manuels)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

L'application par le contrôleur d'admission de la vérification des signatures d'images comble l'écart entre la signature dans le pipeline et le déploiement en cours d'exécution. Une ClusterPolicy Kyverno avec une règle verifyImages refuse tout pod qui référence une image sans signature valide de la clé publique Cosign approuvée. La politique devrait également activer mutateDigest: true, qui réécrit les références de tag mutables en références de condensé immuables dans la spécification du pod au moment de l'admission — garantissant que le runtime de conteneur extrait exactement l'image qui a été vérifiée, et non un push ultérieur vers le même tag.

Génération de SBOM pour les packages ATO

Un Software Bill of Materials (SBOM) est un inventaire lisible par machine de chaque composant logiciel dans un artefact déployé — paquets OS, bibliothèques de runtime de langage, dépendances d'application et leurs relations. Pour les packages ATO, le SBOM fournit à l'officiel d'autorisation une visibilité sur la chaîne d'approvisionnement logicielle du système déployé et constitue de plus en plus un livrable requis en vertu de la politique d'acquisition de logiciels du DoD et des orientations CISA mettant en œuvre le Décret exécutif 14028.

Syft (Anchore) est le générateur SBOM open source standard pour les images de conteneurs. Il analyse le système de fichiers de l'image couche par couche, identifie les paquets à la fois par les enregistrements de la base de données des paquets OS et par les fichiers de verrouillage des écosystèmes de langages, et produit des documents SBOM structurés. L'exécution de Syft sur le condensé d'image finale (et non sur le Dockerfile ou le dépôt source) capture l'ensemble de composants déployés réel, y compris les paquets installés de manière transitive ou ajoutés pendant le processus de construction qui ne sont pas explicitement listés dans les fichiers de dépendances d'application.

# Générer un SBOM aux formats SPDX et CycloneDX depuis l'image finale
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# Attacher le SBOM à l'image dans le registre (stocké comme artefact OCI)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# Vérifier l'attachement SBOM
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

Sur la question SPDX versus CycloneDX : les deux formats sont acceptés par les orientations CISA et sont capables de représenter les mêmes informations sur les composants. SPDX (ISO/IEC 5962:2021) est la norme plus ancienne avec le mandat le plus fort dans les contextes gouvernementaux ; CycloneDX dispose d'un meilleur support d'outillage pour l'enrichissement des vulnérabilités via les documents VEX (Vulnerability Exploitability eXchange). Pour l'application du SBOM dans les pipelines de défense, générer les deux formats depuis une seule invocation de Syft ne coûte rien et garantit la compatibilité avec tout outillage ATO en aval ou toute préférence de l'officiel d'autorisation.

Le SBOM soumis à l'AO doit être accompagné d'un document de divulgation des vulnérabilités mappant les identifiants de composants SBOM aux résultats d'analyse et à leur disposition (corrigé, dérogé avec justification, non affecté). Ce package combiné — condensé d'image, SBOM, résultats d'analyse, dérogations et signature Cosign — constitue l'ensemble de preuves de la chaîne d'approvisionnement que les auditeurs utilisent pour évaluer la fiabilité d'un système déployé.

Sécurité du registre d'images de conteneurs

Harbor est le registre de conteneurs diplômé CNCF le plus largement déployé dans les environnements de défense et classifiés. Son ensemble de fonctionnalités répond aux exigences opérationnelles spécifiques des registres de défense : immuabilité des tags, intégration de la confiance du contenu avec Cosign, contrôle d'accès basé sur les rôles, intégration de l'analyse des vulnérabilités (Trivy) et politiques de réplication pour les réseaux de registres multi-enclaves. L'exécution de Harbor dans un environnement classifié nécessite une attention particulière à plusieurs domaines de configuration que les paramètres par défaut n'appliquent pas.

L'immuabilité des tags empêche toute opération de push d'écraser un tag d'image existant. Sans ce contrôle, un compte de service CI/CD compromis ou un pipeline mal configuré pourrait silencieusement remplacer une image approuvée et signée par une image malveillante ou non signée sous le même tag. Les règles d'immuabilité des tags de Harbor sont configurées par projet et peuvent être limitées à des patterns de tags spécifiques — par exemple, verrouiller tous les tags correspondant à v[0-9]* (versions de publication) tout en autorisant les tags dev-* mutables dans les projets de développement.

La politique de confiance du contenu dans Harbor s'intègre à Cosign pour appliquer la vérification des signatures au moment de l'extraction. Lorsque la confiance du contenu est activée pour un projet, la couche proxy de Harbor appelle la vérification Cosign pour chaque demande d'extraction d'image et renvoie une erreur d'autorisation si l'image ne dispose pas d'une signature valide de la clé publique configurée. Cela fournit une application au niveau du registre indépendante du contrôleur d'admission Kubernetes — les images ne peuvent pas être extraites même par des outils qui contournent le webhook d'admission.

# Configuration du projet Harbor via CLI (harbor-cli ou curl contre l'API Harbor)
# Activer l'immuabilité des tags pour le projet de production
curl -X POST https://registry.classified.mil/api/v2.0/projects/mission-apps/immutabletagrules \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{
    "action": "immutableTagRule",
    "scope_selectors": {"repository": [{"decoration": "repoMatches","pattern": "**"}]},
    "tag_selectors": [{"decoration": "matches","pattern": "v[0-9]*"}]
  }'

# Activer l'analyse des vulnérabilités lors du push pour tous les projets
curl -X PUT https://registry.classified.mil/api/v2.0/projects/mission-apps \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{"metadata": {"auto_scan": "true", "severity": "critical"}}'

Le cache pull-through dans Harbor joue un rôle critique dans les architectures multi-enclaves. L'instance Harbor connectée (de classification inférieure) est configurée avec des projets de cache proxy en amont pointant vers des registres externes approuvés (Red Hat Registry, Iron Bank). Du côté classifié, une instance Harbor distincte n'a pas de registre en amont configuré — elle ne sert que des images qui ont été extraites via le cache du côté de l'enclave connectée, analysées, signées et transférées physiquement vers le registre classifié via le mécanisme de transfert inter-domaines approuvé. Cela crée un flux de travail de promotion d'images contrôlé où chaque image doit passer les contrôles de sécurité avant d'entrer dans l'environnement classifié plutôt qu'au moment de l'entrée.

La politique de collecte des déchets dans Harbor supprime les manifestes non tagués et les couches inutilisées selon un calendrier défini. Dans les environnements classifiés avec une capacité de stockage limitée, la collecte des déchets empêche le stockage du registre de croître de façon illimitée à mesure que les images sont remplacées par de nouvelles versions. La configuration recommandée exécute la collecte des déchets hebdomadairement pendant une fenêtre de maintenance, conserve un nombre configurable d'images taguées historiques par dépôt pour la capacité de restauration, et génère un journal de suppression pour l'auditabilité. La suppression d'images dans un registre classifié doit être coordonnée avec les exigences de rétention des preuves ATO — les artefacts SBOM et d'analyse pour les versions d'images déployées peuvent nécessiter une conservation au-delà du cycle de vie de l'image.

Point clé : La sécurité des images de conteneurs n'est pas un contrôle unique mais une chaîne de défense en profondeur : les images de base STIG réduisent la surface de vulnérabilité héritée ; les constructions multi-étapes éliminent la surface d'attaque inutilisée de l'image d'exécution ; l'analyse des vulnérabilités au moment de la construction détecte les CVE connus avant le déploiement ; la signature d'images fournit une vérification d'intégrité de la construction à l'exécution ; la génération de SBOM fournit une transparence de la chaîne d'approvisionnement pour l'autorisation ; et les contrôles de registre (immuabilité, confiance du contenu, cache pull-through) appliquent la chaîne au niveau de la distribution. Une lacune dans un maillon de cette chaîne — une image non signée, une base de données de vulnérabilités obsolète, un tag mutable — est la surface d'attaque qu'un adversaire disposant d'un accès à la chaîne d'approvisionnement exploitera.

Discutez de votre projet

Nous concevons et mettons en œuvre des pipelines de sécurité de conteneurs pour les environnements de défense classifiés — de la validation des images de base STIG et de l'analyse des vulnérabilités en réseau isolé à l'infrastructure de signature Cosign et à la configuration du registre Harbor pour les architectures multi-enclaves.

Services Cloud sécurisé → Réserver un briefing

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui développent des logiciels critiques pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →

Questions fréquemment posées

Pourquoi la sécurité des images de conteneurs nécessite-t-elle une approche différente en défense par rapport à l'entreprise commerciale ?

Les environnements de défense ajoutent trois pressions absentes de la plupart des environnements d'entreprise. Premièrement, les charges de travail classifiées ne peuvent pas extraire des images depuis des registres internet, donc chaque dépendance doit être dupliquée dans un registre interne approuvé — ce qui signifie que la frontière de la chaîne d'approvisionnement est un périmètre dur entièrement à votre charge. Deuxièmement, les logiciels de défense doivent satisfaire un processus d'autorisation formel (ATO) qui exige une provenance documentée pour chaque composant, ce qui fait passer la génération de SBOM et la signature d'images de pratiques optionnelles à obligatoires. Troisièmement, le modèle de menace de l'adversaire inclut des acteurs étatiques avec la capacité et la motivation d'injecter des composants malveillants en amont dans des bibliothèques open source ou des paquets OS de base — la surface d'attaque exacte qu'une chaîne d'approvisionnement d'images de conteneurs expose.

Quel STIG s'applique aux images de base de conteneurs et qu'applique-t-il ?

DISA publie le Container Platform Security Requirements Guide (SRG) et des STIG spécifiques pour les dérivés de Red Hat Universal Base Image (UBI) et RHEL 8/9. Le STIG RHEL est la référence la plus pertinente sur le plan opérationnel : il mandate des valeurs spécifiques de paramètres noyau sysctl (restreignant le transfert IP, les redirections ICMP et les cookies SYN), la configuration PAM appliquant la complexité des mots de passe et le verrouillage de compte, les règles auditd couvrant l'accès aux fichiers, l'escalade de privilèges et les modifications de configuration réseau, ainsi que la politique cryptographique FIPS 140-2/140-3. Lorsque vous construisez FROM une image de base fournie par DISA ou durcie indépendamment selon les STIG, vous héritez des contrôles au niveau OS et n'avez qu'à durcir votre couche applicative par-dessus.

Qu'est-ce qu'une image de conteneur distroless et quand les charges de travail de défense doivent-elles l'utiliser ?

Une image distroless ne contient que le runtime de l'application et ses dépendances de bibliothèques directes — sans gestionnaire de paquets, sans shell, sans utilitaires système. L'avantage en termes de sécurité est significatif : un conteneur sans shell ne peut pas être exploité via une injection de shell ; un conteneur sans gestionnaire de paquets ne peut pas être utilisé pour télécharger et installer des outils d'attaquant après compromission. Pour les binaires Go ou Rust compilés de manière statique, scratch (une image de base complètement vide) est encore plus minimal. Les charges de travail de défense qui peuvent tolérer distroless — la plupart des microservices sans état le peuvent — devraient le préférer aux images OS à usage général, quel que soit le degré de durcissement de cette image OS.

Comment exécuter Trivy ou Grype dans un réseau classifié isolé ?

Trivy et Grype prennent tous deux en charge le fonctionnement hors ligne de la base de données. Pour Trivy, téléchargez le bundle de base de données des vulnérabilités sur un système connecté, transférez-le via la diode de données ou un support amovible vers le réseau classifié, et pointez Trivy vers la copie locale avec les drapeaux --skip-update et --cache-dir. Grype utilise un schéma similaire : téléchargez le bundle grype-db, placez-le dans le répertoire de cache configuré et définissez GRYPE_DB_AUTO_UPDATE=false. La discipline opérationnelle clé est un cycle régulier (hebdomadaire ou par sprint) de rafraîchissement de la base de données — les bases de données de vulnérabilités obsolètes dans les environnements classifiés sont un constat de conformité courant car le processus de rafraîchissement nécessite un transfert physique de supports et est facile à différer.

Qu'est-ce que Cosign et comment permet-il la signature d'images sans instance publique Fulcio/Rekor ?

Cosign (partie du projet Sigstore) signe les images de conteneurs en attachant une signature cryptographique sous forme d'artefact OCI stocké dans le même registre aux côtés de l'image. Dans un flux Sigstore sans clé, Cosign utilise des jetons d'identité OIDC et le CA Fulcio public et le journal de transparence Rekor — ce qui nécessite un accès internet. Dans un environnement de défense isolé, le flux de signature avec clé plus simple — où Cosign signe avec une clé privée stockée dans un HSM ou un gestionnaire de secrets — ne nécessite aucune infrastructure externe et est l'approche la plus pratique pour les environnements classifiés. Le drapeau --tlog-upload=false désactive le téléchargement dans le journal de transparence, et --insecure-ignore-tlog=true ignore la vérification Rekor du côté de la vérification.

Quel format SBOM les programmes de défense doivent-ils utiliser — SPDX ou CycloneDX ?

Les deux formats sont acceptés par CISA et capables de représenter les mêmes informations sur la chaîne d'approvisionnement. SPDX (ISO/IEC 5962:2021) est la norme plus ancienne avec de plus forts mandats gouvernementaux, y compris les orientations SBOM du Décret exécutif 14028. CycloneDX a un meilleur support pour l'enrichissement des vulnérabilités (documents VEX), les évaluations de sécurité et l'identité des composants lisible par machine, et est de plus en plus préféré par l'outillage d'analyse SBOM. Pour les packages ATO, produire les deux formats depuis une seule exécution Syft ne coûte rien et satisfait toute exigence d'officiel d'autorisation en aval — utilisez deux drapeaux --output dans une seule commande.

Comment l'immuabilité des tags dans Harbor protège-t-elle contre les attaques de substitution d'images ?

Par défaut, les registres de conteneurs autorisent l'écrasement d'un tag existant avec un condensé d'image différent — donc :latest ou :v2.3.1 peut pointer vers une image complètement différente demain. Dans une chaîne d'approvisionnement de défense, un compte de registre compromis ou un pipeline CI mal configuré pourrait silencieusement remplacer une image approuvée par une image malveillante sous le même tag. La fonctionnalité d'immuabilité des tags de Harbor, configurée par projet, empêche tout push qui écraserait un tag existant. Combinée à la signature d'images (qui engage le condensé dans la signature) et à l'épinglage de condensé par le contrôleur d'admission, l'immuabilité des tags ferme complètement le vecteur d'attaque de substitution d'images.

Quels seuils de porte de politique d'analyse sont appropriés pour les pipelines CI/CD de défense ?

Une politique défendable : bloquer toute vulnérabilité CRITICAL avec un exploit connu (score EPSS supérieur à 0,05 ou sous-score d'exploitabilité CVSS supérieur à 7,0) ; bloquer toute vulnérabilité HIGH dans une dépendance directe avec un exploit connu ; avertir et exiger une dérogation documentée pour les vulnérabilités HIGH sans exploit public et les vulnérabilités MEDIUM. La règle de blocage sur toutes les HIGH est courante dans les cadres de conformité mais génère un bruit excessif en pratique — en particulier pour les vulnérabilités de paquets OS dans les images de base STIG où le correctif du fournisseur n'est pas encore disponible. Le blocage par sévérité plus exploitabilité réduit les blocages faux positifs tout en détectant les vulnérabilités les plus susceptibles d'être transformées en armes.

Quel est le rôle d'un SBOM dans le processus ATO (Autorisation à Opérer) ?

Un SBOM est une nomenclature logicielle lisible par machine listant chaque composant logiciel dans un système déployé, y compris les identifiants de version et les relations entre composants. Dans le processus ATO, le SBOM fournit à l'officiel d'autorisation (AO) une visibilité sur la chaîne d'approvisionnement logicielle complète — permettant à l'AO d'évaluer si un composant présente des vulnérabilités connues, des contraintes de licence commerciale ou une origine non fiable. Le SBOM soumis à l'AO doit être généré au moment de la construction de l'image (pas depuis la source), doit couvrir toutes les couches de chaque image de conteneur, et doit être stocké de manière immuable aux côtés de l'image signée dans le registre d'artefacts. Un document VEX d'accompagnement mappant les CVE à leur statut d'exploitabilité renforce la soumission.

Comment le cache pull-through dans Harbor prend-il en charge les opérations réseau classifiées ?

Le projet de cache proxy de Harbor vous permet de configurer un registre en amont (Red Hat Registry, Iron Bank) et de dupliquer transparemment les images au premier pull. Dans un réseau classifié sans accès internet, le cache pull-through est généralement pré-rempli : les images sont extraites via le cache du côté de l'enclave connectée, et les données du registre Harbor sont répliquées vers l'instance Harbor du côté classifié via un support amovible ou un transfert par diode de données. L'instance Harbor du côté classifié n'a pas de registre en amont configuré et ne sert que des images pré-approuvées, pré-analysées et pré-signées. Cela applique les contrôles de sécurité avant que les images n'entrent jamais dans l'environnement classifié plutôt que de s'appuyer uniquement sur l'application en cours d'exécution.