Pipeline CI/CD pentru software de apărare: testare automatizată și implementare pentru sisteme militare

O echipă de software comercial poate livra o funcționalitate nouă în producție în câteva minute: o cerere de îmbinare trece testele automate, un revizor aprobă, pipeline-ul CI construiește și implementează. Pentru echipele de software de apărare, același drum de livrare trebuie să navigheze printr-un spațiu de constrângeri fundamental diferit: reglementările de export ITAR care restricționează accesul la artefactele de compilare, cerințele de conformitate STIG care definesc configurarea fiecărui strat al stivei, mandatele SBOM care impun un inventar lizibil automat al fiecărei dependențe și medii de implementare care pot să nu aibă nicio conexiune la internet. Rezultatul este că multe programe de apărare fie abandonează complet CI/CD în favoarea proceselor de lansare manuale — fie adoptă instrumente CI/CD comerciale fără cablarea conformității și creează riscuri de audit.

Niciunul din aceste rezultate nu este necesar. Un pipeline CI/CD pentru software de apărare care satisface controalele ITAR, produce artefacte conforme STIG, generează SBOM-uri semnate și se implementează în medii izolate este realizabil cu instrumentele open source disponibile și un model arhitectural clar. Acest articol descrie acel model, acoperind alegerile de infrastructură a pipeline-ului, etapele de testare automatizată, generarea SBOM, întărirea containerelor, implementarea Air Gap, procedurile de revenire și cerințele privind urmele de audit.

Constrângerile software-ului de apărare: ITAR, STIG și gestionarea clasificărilor în CI

International Traffic in Arms Regulations (ITAR) controlează exportul articolelor și serviciilor de apărare, inclusiv datele tehnice legate de sistemele de apărare. Într-un context CI/CD, codul sursă, artefactele de compilare și rezultatele testelor pot fi supuse controlului exportului, iar accesul trebuie restricționat la persoanele din SUA. Rulătorii de compilare care procesează cod controlat ITAR trebuie să ruleze pe sisteme unde accesul este impus la nivelul infrastructurii — rulători auto-gestionați pe hardware local sau rulători într-o enclavă cloud FedRAMP High sau DoD IL4/IL5 cu controale de acces documentate.

Technology Control Plan (TCP) al programului trebuie să includă infrastructura CI/CD în domeniul său de aplicare. Gestionarea clasificărilor adaugă o constrângere suplimentară: pipeline-ul CI/CD însuși rulează la cel mai înalt nivel de clasificare al oricărui artefact pe care îl produce.

Arhitectura pipeline-ului: GitLab on-premises vs SaaS, considerații Air Gap

GitLab auto-gestionat este alegerea dominantă a platformei CI/CD pentru programele de apărare sensibile. Rulează complet pe infrastructura controlată de dvs., suportă instalarea complet offline, se integrează cu Active Directory și LDAP pentru controlul accesului și are o bază mare de instalare în programele DoD. Registrul de artefacte trebuie să ruleze și el pe infrastructura controlată de dvs. — Harbor pentru containere, Artifactory sau Nexus pentru dependențele ecosistemului lingvistic. Pentru implementările izolate, un proces de actualizare a oglinzii transportă conținut extern prin izolare conform unui program documentat.

Etapele de testare automatizată: de la unitare până la scanarea conformității STIG

Un pipeline CI/CD de apărare necesită: teste unitare și de integrare la fiecare commit; SAST (Semgrep sau SonarQube) la fiecare cerere de îmbinare; DAST (OWASP ZAP) față de o instanță de test implementată; analiza compoziției software (Grype sau Trivy) față de o oglindă internă de vulnerabilități; scanarea conformității STIG (InSpec cu profilele DISA sau OpenSCAP); detecția secretelor; și conformitatea licențelor. Fiecare etapă oprește pipeline-ul la violările de politici fără posibilitate de ocolire manuală.

Generarea SBOM: CycloneDX/SPDX, Grype/Trivy, conformitatea licențelor

Secțiunea 1655 din NDAA (FY2023) a dat directive DoD să elaboreze ghiduri care să impună SBOM de la furnizorii de software. SBOM-urile sunt generate la momentul compilării folosind Syft sau cdxgen în format CycloneDX sau SPDX, semnate alături de artefactul de compilare folosind Cosign și stocate în registrul de artefacte ca artefacte de prim rang. Grype sau Trivy încrucișează componentele SBOM cu bazele de date CVE și produc adnotări VEX. Conformitatea licențelor este impusă ca o poartă paralelă.

Întărirea containerelor: baze distroless, execuție non-root, seccomp, semnarea imaginilor

Imaginile de containere de apărare utilizează imagini de bază distroless sau DISA STIG-întărite, rulează ca utilizatori non-root, utilizează sisteme de fișiere root numai pentru citire, aplică profiluri seccomp RuntimeDefault sau personalizate și sunt semnate cu Cosign sau Notary v2. Controlerele de admitere (OPA/Gatekeeper sau Kyverno) impun aceste cerințe la momentul planificării podurilor în toate clusterele.

Implementare în medii clasificate: transfer sneakernet, verificarea hash-ului, semnarea manifestului

Pipeline-ul produce un pachet de implementare semnat care conține: binare sau imagini de containere semnate, SBOM, rezultatele scanării vulnerabilităților, atestarea provenienței SLSA, manifestul de implementare și fișierul hash SHA-256. Transferul traversează izolarea printr-o soluție cross-domain acreditată sau proceduri sneakernet documentate. Pe partea clasificată, scriptul de instalare verifică hash-ul și semnătura înainte de a proceda.

Proceduri de revenire: blue-green pentru servicii, instantanee SQLite pentru sisteme încorporate

Serviciile web utilizează implementări blue-green — revenirea este o comutare a traficului, nu o reimplementare. Sistemele încorporate și aplicațiile bazate pe SQLite utilizează instantanee versionate înainte de actualizare. Pipeline-ul CI testează calea instantaneu/restaurare în testele de integrare. Toate evenimentele de revenire sunt înregistrate în urma de audit imuabilă.

Cerințe privind urmele de audit: jurnale imuabile, aprobări de modificări, trasabilitatea cerințelor

Jurnalele pipeline-ului sunt stocate într-un SIEM de scriere unică sau un depozit de obiecte cu blocare de obiecte. Fiecare implementare face referire la un bilet de modificare aprobat. Trasabilitatea leagă elementele de lucru de dezvoltare de elementele de cerințe, cu rezultatele testelor atașate la elementele de lucru. Pipeline-ul atașează rezumatele rezultatelor testelor și hash-urile artefactelor la problema relevantă la finalizarea implementării.