Pipeline CI/CD pour logiciels de défense : tests automatisés et déploiement pour systèmes militaires

Une équipe de développement logiciel commercial peut livrer une nouvelle fonctionnalité en production en quelques minutes : une pull request passe les tests automatisés, un relecteur approuve, le pipeline CI construit et déploie. Pour les équipes de logiciels de défense, le même chemin de livraison doit naviguer dans un espace de contraintes fondamentalement différent : les réglementations d'exportation ITAR qui restreignent l'accès aux artefacts de compilation, les exigences de conformité STIG qui définissent la configuration de chaque couche de la pile, les mandats SBOM qui exigent un inventaire lisible par machine de chaque dépendance, et des environnements de déploiement qui peuvent n'avoir aucune connexion internet du tout. Le résultat est que de nombreux programmes de défense abandonnent complètement CI/CD au profit de processus de publication manuels et à plusieurs niveaux — ou adoptent des outils CI/CD commerciaux sans le câblage de conformité et créent des responsabilités d'audit.

Aucun de ces résultats n'est nécessaire. Un pipeline CI/CD pour logiciels de défense qui satisfait les contrôles ITAR, produit des artefacts conformes STIG, génère des SBOM signés et se déploie dans des environnements isolés est réalisable avec les outils open source disponibles et un modèle architectural clair. Cet article décrit ce modèle, couvrant les choix d'infrastructure de pipeline, les étapes de test automatisé, la génération de SBOM, le durcissement des conteneurs, le déploiement en Air Gap, les procédures de retour arrière et les exigences de piste d'audit.

Contraintes des logiciels de défense : ITAR, STIG et gestion des classifications en CI

Les International Traffic in Arms Regulations (ITAR) contrôlent l'exportation d'articles et de services de défense, y compris les données techniques relatives aux systèmes de défense. Dans un contexte CI/CD, le code source, les artefacts de compilation et les résultats de tests peuvent tous être soumis au contrôle des exportations, et l'accès doit être limité aux personnes américaines. Les runners de compilation qui traitent du code contrôlé par ITAR doivent fonctionner sur des systèmes où l'accès est imposé au niveau de l'infrastructure — des runners auto-gérés sur du matériel local ou des runners dans une enclave cloud FedRAMP High ou DoD IL4/IL5 avec des contrôles d'accès documentés.

Le Technology Control Plan (TCP) du programme doit inclure l'infrastructure CI/CD dans son périmètre. La gestion des classifications ajoute une contrainte supplémentaire : le pipeline CI/CD lui-même fonctionne au niveau de classification le plus élevé de tout artefact qu'il produit.

Architecture du pipeline : GitLab on-premises vs SaaS, considérations Air Gap

GitLab auto-géré est le choix dominant de plateforme CI/CD pour les programmes de défense sensibles. Il fonctionne entièrement sur une infrastructure que vous contrôlez, prend en charge l'installation entièrement hors ligne, s'intègre avec Active Directory et LDAP pour le contrôle d'accès, et dispose d'une grande base installée dans les programmes DoD. Le registre d'artefacts doit également fonctionner sur une infrastructure que vous contrôlez — Harbor pour les conteneurs, Artifactory ou Nexus pour les dépendances d'écosystèmes linguistiques. Pour les déploiements isolés, un processus de mise à jour miroir transporte le contenu externe à travers l'Air Gap selon un calendrier documenté.

Étapes de test automatisé : des tests unitaires jusqu'au scan de conformité STIG

Un pipeline CI/CD de défense requiert : des tests unitaires et d'intégration à chaque commit ; du SAST (Semgrep ou SonarQube) à chaque pull request ; du DAST (OWASP ZAP) contre une instance de test déployée ; une analyse de composition logicielle (Grype ou Trivy) contre un miroir de vulnérabilités interne ; un scan de conformité STIG (InSpec avec les profils DISA ou OpenSCAP) ; la détection de secrets ; et la conformité des licences. Chaque étape arrête le pipeline en cas de violations de politique sans possibilité de contournement manuel.

Génération de SBOM : CycloneDX/SPDX, Grype/Trivy, conformité des licences

La section 1655 du NDAA (FY2023) a ordonné au DoD de développer des directives exigeant des SBOM de la part des fournisseurs de logiciels. Les SBOM sont générés au moment de la compilation avec Syft ou cdxgen au format CycloneDX ou SPDX, signés avec l'artefact de compilation grâce à Cosign, et stockés dans le registre d'artefacts comme artefacts de premier ordre. Grype ou Trivy recoupent les composants SBOM avec les bases de données CVE et produisent des annotations VEX. La conformité des licences est imposée comme une porte parallèle.

Durcissement des conteneurs : bases distroless, exécution non-root, seccomp, signature d'images

Les images de conteneurs de défense utilisent des images de base distroless ou DISA STIG-renforcées, s'exécutent en tant qu'utilisateurs non-root, utilisent des systèmes de fichiers root en lecture seule, appliquent des profils seccomp RuntimeDefault ou personnalisés, et sont signées avec Cosign ou Notary v2. Les contrôleurs d'admission (OPA/Gatekeeper ou Kyverno) imposent ces exigences au moment de la planification des pods dans tous les clusters.

Déploiement dans des environnements classifiés : transfert sneakernet, vérification de hash, signature de manifeste

Le pipeline produit un paquet de déploiement signé contenant : des binaires ou images de conteneurs signés, le SBOM, les résultats de scan de vulnérabilités, l'attestation de provenance SLSA, le manifeste de déploiement et le fichier de hash SHA-256. Le transfert traverse l'Air Gap via une solution cross-domaine accréditée ou des procédures sneakernet documentées. Côté classifié, le script d'installation vérifie le hash et la signature avant de procéder.

Procédures de retour arrière : Blue-Green pour les services, snapshots SQLite pour les systèmes embarqués

Les services web utilisent des déploiements Blue-Green — le retour arrière est un basculement de trafic, pas un redéploiement. Les systèmes embarqués et les applications basées sur SQLite utilisent des snapshots versionés avant mise à niveau. Le pipeline CI teste le chemin snapshot/restauration dans les tests d'intégration. Tous les événements de retour arrière sont enregistrés dans la piste d'audit immuable.

Exigences de piste d'audit : journaux immuables, approbations de changements, traçabilité des exigences

Les journaux de pipeline sont stockés dans un SIEM en écriture unique ou un stockage objet avec verrouillage d'objet. Chaque déploiement référence un ticket de changement approuvé. La traçabilité relie les éléments de travail de développement aux éléments d'exigences, avec les résultats de tests attachés aux éléments de travail. Le pipeline attache les résumés de résultats de tests et les hashs d'artefacts au problème pertinent à la fin du déploiement.