Pipelines CI/CD pour les environnements de défense isolés

Les pipelines CI/CD classiques reposent sur l'hypothèse d'une connectivité internet sortante omniprésente. Chaque runner extrait une image de base d'un registre public, chaque build résout ses dépendances depuis des dépôts de paquets amont, chaque outil de scan télécharge de nouvelles signatures de vulnérabilités au démarrage. Dans un environnement de défense classifié et isolé du réseau, aucune de ces hypothèses ne tient — et les conséquences techniques se répercutent sur chaque couche de la chaîne d'outils. Ce guide couvre les décisions d'architecture, les choix d'outillage et les procédures opérationnelles qui permettent à l'intégration et à la livraison continues de fonctionner sans accès internet, sur une infrastructure durcie selon les STIG, à l'intérieur d'un périmètre d'accréditation.

Pourquoi les pipelines CI/CD standard échouent dans les environnements de défense isolés

Le mode d'échec n'est pas une fonctionnalité manquante unique — c'est une cascade d'hypothèses intégrées dans chaque outil CI/CD moderne qui s'effondre au contact d'un périmètre d'accréditation isolé. Comprendre ces modes d'échec à l'avance permet d'éviter des cycles d'approvisionnement inutiles et des révisions architecturales de dernière minute lors de la revue ATO.

Isolation réseau. Un environnement classifié au niveau Secret et au-dessus n'a aucun accès internet sortant par conception. Les runners ne peuvent pas extraire d'images depuis Docker Hub, Maven Central, npmjs.com ou PyPI. Les outils de build qui téléchargent des plugins ou des extensions à la première utilisation échouent silencieusement ou avec des erreurs cryptiques sur des hôtes inaccessibles. Les mécanismes de mise à jour dans Jenkins, GitLab et la plupart des outils CI commerciaux contactent un serveur distant au démarrage — ce trafic est bloqué et génère souvent du bruit dans la console de surveillance réseau que l'ISSM doit expliquer à l'AO.

Approbation et accréditation des logiciels. Tout composant logiciel déployé dans un périmètre d'accréditation DoD doit être approuvé par l'Autorité d'Autorisation (AO) dans le cadre du Dossier d'Autorisation Système. Cela inclut non seulement le serveur CI, mais aussi chaque plugin, chaque image d'agent de build, chaque bibliothèque dont le pipeline lui-même dépend. « Nous utiliserons la dernière version du registre public » n'est pas une réponse acceptable dans un contexte ATO. La liste des logiciels approuvés est un document contrôlé ; l'ajout de nouveaux paquets nécessite une demande formelle, un scan de vulnérabilités, une revue de licence et — pour les paquets sans couverture STIG existante — une charge documentaire supplémentaire pour l'équipe d'ingénierie. Ce processus prend généralement de plusieurs jours à plusieurs semaines par paquet, ce qui rend les ajouts de dépendances ad hoc incompatibles avec le rythme de développement qu'un pipeline CI moderne exige. La solution consiste à anticiper le processus d'approbation en identifiant toutes les dépendances avant le déploiement du pipeline, et non après.

Approvisionnement et licences des outils. Certains outillages CI sont directement disponibles pour les contractants gouvernementaux. D'autres nécessitent des accords de licence spécifiques pour un usage gouvernemental. Certains requièrent une revue de contrôle à l'exportation (classification ITAR/EAR). Jenkins OSS et GitLab CE évitent la plupart de ces problèmes, ce qui explique en partie leur prédominance dans les environnements classifiés. Les plateformes CI commerciales qui intègrent des runners propriétaires, des services de secrets gérés ou des analyses basées sur le cloud ne sont généralement pas viables dans un environnement isolé sans modification architecturale significative.

Le résultat net est que le CI/CD en environnement isolé doit être conçu à partir de principes fondamentaux, et non adapté d'un modèle SaaS commercial. Les composants sont disponibles et éprouvés — ils nécessitent simplement un provisionnement hors ligne explicite pour chaque composant qu'un pipeline standard résoudrait dynamiquement. Pour le cadre DevSecOps plus large qui régit ces décisions, consultez notre guide sur DevSecOps pour les pipelines de défense.

Architecture du registre d'artefacts hors ligne

Le registre d'artefacts est l'ancre de la chaîne d'approvisionnement pour un environnement de build isolé. Chaque dépendance — JARs, paquets npm, wheels Python, modules Go, RPMs — doit être servie depuis l'intérieur de l'environnement. Deux produits dominent cet espace dans les environnements classifiés : Sonatype Nexus Repository (OSS et Pro) et JFrog Artifactory (OSS et Pro). Les deux sont déployables sur RHEL sans connectivité sortante requise pour le fonctionnement ; les deux prennent en charge les formats de dépôt dont un projet logiciel de défense typique a besoin.

La topologie se compose de deux parties. Du côté bas (connecté à internet mais non classifié), un poste de travail curateur exécute la même version de Nexus ou Artifactory que l'instance côté haut. Le curateur utilise les outils d'export/import intégrés du gestionnaire de dépôt ou un workflow scripté pour télécharger les artefacts approuvés, résoudre leurs dépendances transitives, vérifier les sommes de contrôle par rapport aux hachages publiés par le registre amont, et assembler un bundle de transfert signé. L'étape de signature est critique : le bundle de transfert doit être signé avec la clé de transfert du programme afin que le système côté haut puisse vérifier l'intégrité avant d'importer quoi que ce soit.

# Low-side curator: assemble and sign the transfer bundle
nexus-curator export \
  --format maven \
  --repos approved-central-proxy \
  --output /transfer/bundle-2026-06-24.tar.gz

# Generate SHA-256 manifest
sha256sum /transfer/bundle-2026-06-24.tar.gz \
  > /transfer/bundle-2026-06-24.manifest

# GPG-sign the manifest with the program transfer key
gpg --detach-sign --armor \
  --local-user transfer@program.mil \
  /transfer/bundle-2026-06-24.manifest

# Physical transfer via encrypted removable media or data diode
# ...

# High-side import: verify before extracting
gpg --verify bundle-2026-06-24.manifest.asc \
              bundle-2026-06-24.manifest
sha256sum -c bundle-2026-06-24.manifest
nexus-curator import --file bundle-2026-06-24.tar.gz
            

Du côté haut, l'instance Nexus ou Artifactory ne sert que des dépôts hébergés — il n'y a pas de dépôts proxy pointant vers des URLs externes, car ces URLs sont inaccessibles. Les fichiers de configuration des outils des agents de build ne référencent que le nom d'hôte interne. Un tableau des fichiers de configuration qui nécessitent une modification :

La cadence de curation est une décision de politique : généralement mensuelle pour les correctifs de sécurité, trimestrielle pour les nouvelles versions de dépendances, et immédiate pour tout CVE avec un score CVSS supérieur à 8,0. Le Comité de Contrôle de Configuration du programme est responsable de chaque décision d'import.

Serveur CI durci selon les STIG : Jenkins ou GitLab sur infrastructure classifiée

Les deux choix les plus courants pour l'exécution CI sur infrastructure classifiée sont Jenkins (l'option longtemps dominante, largement déployée dans les programmes DoD depuis le milieu des années 2010) et GitLab (de plus en plus privilégié pour les nouveaux programmes en raison de son STIG DISA publié et de ses fonctionnalités DevSecOps intégrées). Les deux peuvent être rendus conformes ; l'effort et le profil de risque résiduel diffèrent.

Pour Jenkins, le référentiel de durcissement est le DISA Application Server SRG combiné au RHEL 9 STIG pour le système d'exploitation sous-jacent. La liste de contrôle de durcissement spécifique à Jenkins couvre les domaines suivants :

• Désactiver le CLI Jenkins via remoting (classe de vulnérabilités CVE-2024-23897) ; utiliser le CLI uniquement via SSH si nécessaire.
• Activer les en-têtes Content Security Policy (CSP) pour prévenir les XSS dans la sortie console des builds.
• Désactiver l'accès à la Console de Scripts pour les utilisateurs non administrateurs ; restreindre les échappements du sandbox Groovy.
• Configurer la sécurité matricielle avec le principe du moindre privilège : les développeurs peuvent déclencher des builds, mais ne peuvent pas administrer les agents ou les identifiants.
• Activer le plugin audit-log ; transférer les journaux vers le SIEM de l'environnement.
• Définir JENKINS_HOME sur un système de fichiers avec contrôles d'accès ; restreindre les permissions lisibles par tous sur credentials.xml.
• Désactiver les connexions au site de mise à jour (hudson.model.UpdateCenter.never=true dans jenkins.properties).
• Exécuter Jenkins en tant que compte de service dédié sans privilèges root ; appliquer les contextes SELinux.

GitLab CE/EE sur RHEL bénéficie du STIG DISA GitLab Enterprise Edition (V1R1, publié en 2022), qui mappe les contrôles directement aux paramètres de configuration GitLab. Les contrôles clés incluent l'application d'un minimum TLS 1.2, la désactivation des inscriptions et des fournisseurs OAuth, l'activation des événements d'audit vers syslog, la restriction du protocole Git au SSH sur un port connu, et la désactivation des fonctionnalités auto-DevOps qui effectuent des appels sortants. Le registre intégré de GitLab, le workflow de merge request et la syntaxe YAML de pipeline réduisent le nombre de composants accrédités séparément par rapport à une pile centrée sur Jenkins, ce qui est souvent le facteur décisif dans les programmes où les délais ATO sont contraints.

Dans les deux cas, les agents de build doivent s'exécuter dans le même périmètre de classification que le contrôleur. Les images d'agents sont construites à partir d'images de base approuvées stockées dans le registre de conteneurs de l'environnement, et sont reconstruites selon un calendrier défini (généralement mensuel) pour intégrer les mises à jour de correctifs OS transférées via le workflow de curation.

Registre de conteneurs déconnecté

Les images de conteneurs dans un pipeline isolé doivent être stockées, scannées et signées à l'intérieur de l'environnement. Deux produits sont les plus courants : Harbor (diplômé CNCF, largement utilisé dans les environnements DoD Platform One) et Red Hat Quay (supporté dans le cadre de l'accord Red Hat d'entreprise du DoD, s'intègre étroitement avec OpenShift). Les deux prennent en charge la signature d'images OCI, le contrôle d'accès basé sur les rôles et le scan de vulnérabilités avec des bases de données hors ligne.

Le peuplement initial du registre suit le même workflow de transfert que le registre d'artefacts : les images de base approuvées (RHEL UBI, images Iron Bank durcies, couches de base d'application approuvées) sont exportées du côté bas sous forme de tarballs OCI, transférées, puis importées dans Harbor ou Quay à l'aide de skopeo copy :

# Low side: export approved images as OCI tarballs
skopeo copy \
  docker://registry.access.redhat.com/ubi9/ubi:9.4 \
  oci-archive:/transfer/ubi9-9.4.tar \
  --override-os linux

# Generate and sign manifest
sha256sum /transfer/ubi9-9.4.tar >> /transfer/images.manifest
gpg --detach-sign --armor --local-user transfer@program.mil \
    /transfer/images.manifest

# High side: verify and import
gpg --verify images.manifest.asc images.manifest
sha256sum -c images.manifest
skopeo copy \
  oci-archive:/transfer/ubi9-9.4.tar \
  docker://harbor.enclave.mil/base/ubi9:9.4 \
  --dest-creds admin:${HARBOR_TOKEN}
            

La signature d'images avec Cosign en mode hors ligne utilise une clé de signature à longue durée de vie stockée dans le moteur Transit Vault de l'environnement, en contournant le journal de transparence Sigstore (hébergé sur internet). La clé de signature est générée dans Vault et n'est jamais exportée ; le pipeline CI appelle l'API Transit de Vault pour signer le condensé de l'image et attache la signature résultante en tant qu'artefact OCI aux côtés du manifeste de l'image dans Harbor. La vérification au moment de l'admission est gérée par une politique Kyverno qui appelle le vérificateur Cosign contre Harbor en utilisant le bundle de confiance PKI interne de l'environnement.

# Sign image using Vault Transit key (no transparency log)
cosign sign \
  --key hashivault://transit/keys/image-signing-key \
  --no-tlog-upload \
  harbor.enclave.mil/myapp/service:v1.4.2@sha256:abc123...

# Kyverno policy: require valid Cosign signature on every pod
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["harbor.enclave.mil/*"]
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ... (enclave signing public key) ...
              -----END PUBLIC KEY-----
            rekor:
              ignoreTlog: true
            

Le scan de vulnérabilités à l'intérieur du registre utilise Trivy ou Grype configuré avec un bundle de base de données hors ligne. La base de données de vulnérabilités (NVD, OSV, avis RedHat) est téléchargée du côté bas, transférée vers le côté haut, et chargée dans le chemin de base de données locale du scanner. Un job de pipeline quotidien actualise le bundle de base de données via le workflow de curation, maintenant les connaissances du scanner à jour dans les limites de la cadence de transfert.

Le workflow de transport logiciel : du sneakernet au serveur de mise à jour sécurisé

Le terme « sneakernet » est antérieur au CI/CD, mais le concept est précisément ce qui permet la livraison logicielle en environnement isolé : transport physique de données entre des réseaux de niveaux de classification différents. Dans les installations classifiées modernes, ce transport est systématisé dans un workflow documenté avec des points de contrôle obligatoires, des pistes d'audit et des exigences de chaîne de custody qui reflètent ce que les contrôles de chaîne d'approvisionnement automatisés fournissent dans un environnement connecté. Le défi pour les pipelines CI/CD est que le cycle de transport — généralement mesuré en jours, pas en millisecondes — doit être intégré dans le modèle de planification des releases.

Le workflow a une structure définie :

Low-side workstation (UNCLASSIFIED)
    │
    ├─ [1] Assemble candidate package set
    │      - download, resolve transitive deps
    │      - verify upstream signatures/checksums
    │      - run malware scan (ClamAV / commercial AV)
    │      - run vulnerability scan (Grype offline db)
    │      - license review
    │
    ├─ [2] Generate signed manifest
    │      sha256sum * > manifest.txt
    │      gpg --detach-sign manifest.txt
    │
    ├─ [3] Submit transfer request (CMT/JIRA ticket)
    │      - package name, version, purpose, license
    │      - vulnerability scan results attached
    │
    ├─ [4] ISSO/AO review and approval (Gate)
    │
    ├─ [5] Physical transfer
    │      - encrypted USB (FIPS 140-2 validated)
    │      - OR hardware data diode (one-way)
    │      - transfer log entry created
    │
High-side secure update server (CLASSIFIED)
    │
    ├─ [6] Verify manifest signature
    │      gpg --verify manifest.txt.asc manifest.txt
    │      sha256sum -c manifest.txt
    │
    ├─ [7] Import into Nexus / Harbor
    │
    └─ [8] Log in configuration management tool
            

La signature des paquets utilise soit GPG avec des clés spécifiques au programme, soit — dans les programmes qui ont adopté des outils basés sur PKI — sigstore/cosign contre l'instance Rekor interne du programme. Le point clé est que la clé de signature utilisée pour les manifestes de transfert est distincte de la clé utilisée pour la signature des artefacts de build. La clé de transfert est détenue par le rôle de curateur, et non par des agents de build automatisés, car l'approbation du transfert est un point de contrôle humain qui ne doit pas être automatisable.

Pour les programmes qui opèrent des cycles de correctifs à haute cadence, les diodes de données matérielles unidirectionnelles (comme celles d'Owl Cyber Defense ou Waterfall Security) automatisent la couche physique du transfert tout en préservant la garantie unidirectionnelle. Les données ne circulent que du bas vers le haut ; le système côté haut ne peut envoyer aucun trafic en retour. Cela n'élimine pas le point de contrôle d'approbation, mais élimine l'étape de support amovible physique et peut être utilisé pour pousser des bundles de correctifs nocturnes selon un calendrier défini. Consultez notre traitement plus large de la sécurité de la chaîne d'approvisionnement pour les logiciels de défense pour le cadre de politique qui régit ce qui entre dans le workflow de transfert en premier lieu.

Automatisation de la conformité STIG dans le pipeline

Les listes de contrôle STIG manuelles sont incompatibles avec un rythme de livraison continue. Un build qui se déploie quotidiennement ne peut pas être manuellement examiné par rapport à plus de 300 contrôles STIG avant chaque release. La solution est la conformité en tant que code : encoder les contrôles STIG sous forme de politiques vérifiables par machine, exécuter la politique dans le pipeline comme point de contrôle automatisé, et générer des preuves structurées qui satisfont aux exigences de surveillance continue de l'AO.

La chaîne d'outils principale est OpenSCAP avec le SCAP Security Guide (SSG). SSG fournit du contenu XCCDF/OVAL pour RHEL 8, RHEL 9 et les distributions connexes qui s'associe directement aux STIG DISA. Dans un environnement isolé, le contenu SSG est intégré dans l'image de l'agent de build plutôt que téléchargé à l'exécution :

# Pipeline stage: STIG scan of a deliverable container image
stages:
  - build
  - stig-scan
  - sign
  - promote

stig-scan:
  stage: stig-scan
  image: harbor.enclave.mil/tools/openscap-runner:latest
  script:
    - |
      # Mount the container image filesystem for scanning
      skopeo copy \
        docker://harbor.enclave.mil/${CI_PROJECT_PATH}:${CI_COMMIT_SHA} \
        oci:./image-under-test

      # Run STIG profile evaluation
      oscap-chroot ./rootfs xccdf eval \
        --profile xccdf_org.ssgproject.content_profile_stig \
        --results stig-results.xml \
        --report stig-report.html \
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

      # Block on any CAT I (high severity) failures
      python3 /tools/parse-stig-results.py \
        --results stig-results.xml \
        --fail-on-severity high \
        --output stig-summary.json

  artifacts:
    paths:
      - stig-results.xml
      - stig-report.html
      - stig-summary.json
    expire_in: 90 days
            

L'application DISA STIG Viewer peut ingérer la sortie results.xml d'OpenSCAP et l'afficher dans le format de liste de contrôle familier utilisé par les AO et les ISSO lors des revues. Pour les programmes qui opèrent un tableau de bord de surveillance continue (alimentant généralement un SIEM ou un outil GRC), la sortie JSON structurée du script de parsing est poussée vers le dépôt de preuves en tant qu'artefact de pipeline aux côtés du build.

Un modèle courant consiste à séparer le scan STIG au niveau de l'hôte (exécuté par l'équipe infrastructure contre les images de base des agents de build sur une cadence mensuelle) du scan STIG au niveau de l'image (exécuté par le pipeline applicatif à chaque build contre le conteneur livrable). Les constats au niveau hôte affectent l'ATO de l'infrastructure CI elle-même et sont suivis dans le POA&M du système. Les constats au niveau image sont suivis au niveau applicatif et relèvent de la responsabilité de l'équipe de développement. La piste d'audit délimite clairement quelle équipe possède quel constat, ce qui est important lorsqu'un accrédideur examine le dossier de preuves de surveillance continue.

Pour l'application des SBOM dans les pipelines de défense, la sortie du scan STIG complète le SBOM en fournissant la preuve que l'environnement d'exécution dans lequel l'artefact s'exécutera est également conforme — pas seulement les composants logiciels de l'artefact.

Gestion des secrets sans internet : HashiCorp Vault en mode isolé

La gestion des secrets est le composant le plus susceptible d'être improvisé de manière inadéquate dans les environnements isolés. L'improvisation courante — stocker les identifiants dans le magasin d'identifiants intégré au serveur CI, dans un gestionnaire de mots de passe partagé, ou dans des variables d'environnement intégrées dans les images d'agents — échoue aux mêmes contrôles d'audit qu'un environnement connecté échouerait. La solution approuvée est un système de gestion des secrets dédié déployé à l'intérieur du périmètre d'accréditation.

HashiCorp Vault OSS (open-source, pas Enterprise) ne nécessite aucune connectivité internet pour fonctionner. Il est déployable sur un hôte RHEL durci selon les STIG à l'intérieur de l'environnement, initialisé avec un partage de clé secrète Shamir distribué parmi les dépositaires de clés autorisés :

# Initialize Vault with 5 key shares, threshold of 3
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# Example output (each share goes to a separate custodian):
# Unseal Key 1: AbCdEf...
# Unseal Key 2: GhIjKl...
# Unseal Key 3: MnOpQr...
# Unseal Key 4: StUvWx...
# Unseal Key 5: YzAbCd...
# Initial Root Token: hvs.XXXXXX (use once, then revoke)

# Unseal using 3 of 5 shares (separate operator ceremony)
vault operator unseal  # enter share 1
vault operator unseal  # enter share 2
vault operator unseal  # enter share 3
            

L'amorçage PKI dans un environnement isolé utilise le moteur de secrets PKI intégré de Vault pour gérer l'infrastructure de certificats du programme. Le processus : générer une clé et un certificat d'AC racine hors ligne (sur un poste de travail isolé, pas dans Vault), stocker la clé de l'AC racine dans un HSM matériel ou une sauvegarde chiffrée hors ligne selon le plan de gestion des clés du programme. Importer le certificat de l'AC racine dans Vault. Dans le moteur PKI de Vault, générer une paire de clés et une CSR pour l'AC intermédiaire, signer la CSR avec l'AC racine (étape hors ligne), importer le certificat intermédiaire signé dans Vault. À partir de ce moment, Vault émet tous les certificats TLS à courte durée de vie pour les services de l'environnement — le serveur CI, le registre d'artefacts, le registre de conteneurs, le gestionnaire de secrets lui-même — sans aucune dépendance à une AC externe.

L'authentification des agents CI utilise la méthode d'authentification AppRole de Vault. Chaque agent de build est provisionné avec un role_id (non secret, peut figurer dans la configuration de l'agent) et un secret_id (de courte durée, injecté par le provisionnement d'infrastructure au démarrage de l'agent). L'agent échange ces éléments contre un token Vault limité aux seuls secrets dont ses builds ont besoin. Les tokens sont de courte durée (1 heure par défaut, renouvelable pendant le build) et expirent automatiquement une fois le build terminé. Ce modèle signifie qu'un agent de build compromis n'a pas d'accès persistant aux secrets — il ne détient qu'un token qui expire, pas un identifiant qui survit indéfiniment.

La rotation des secrets sans accès internet suit une cérémonie planifiée : rotation trimestrielle des secrets statiques (clés API, mots de passe de comptes de service), rotation annuelle des clés de signature. Les politiques de rotation intégrées de Vault gèrent le calendrier ; le résultat de chaque rotation est enregistré dans le journal d'audit de Vault, qui est transféré vers le SIEM de l'environnement. Pour les secrets dynamiques — identifiants de base de données, certificats PKI — les moteurs de secrets dynamiques de Vault génèrent des identifiants par build avec des TTL courts, rendant la rotation sans événement car chaque identifiant est déjà éphémère.

La discipline opérationnelle requise pour exploiter cette pile n'est pas anodine. Les rôles de curateur, les procédures d'approbation de transfert, les cérémonies de dépositaires de clés et les cadences de scan mensuelles sont des engagements organisationnels, pas des décisions d'ingénierie ponctuelles. Les programmes qui investissent dans la documentation de ces procédures dans le cadre du Plan de Sécurité Système (SSP) plutôt que comme connaissances tribales informelles sont significativement plus résilients aux changements de personnel — ce qui, compte tenu des exigences d'habilitation et du marché du travail de la défense, est un risque opérationnel réaliste sur tout programme à long terme.

Pour la couche de politique de chaîne d'approvisionnement qui régit ce qui entre dans le pipeline en premier lieu, consultez notre article sur l'application des SBOM dans les pipelines de défense. La pile CI isolée décrite ici est la couche d'exécution ; l'application des SBOM et le cadre DevSecOps pour les pipelines de défense plus large constituent la couche de politique qui détermine ce que le pipeline construit, scanne et atteste.