Pipeline-uri CI/CD pentru medii de apărare air-gapped

Pipeline-urile CI/CD standard sunt construite pe presupunerea existenței unei conectivități internet omniprezente în exterior. Fiecare runner preia o imagine de bază dintr-un registru public, fiecare compilare rezolvă dependențele din depozitele de pachete upstream, fiecare instrument de scanare descarcă semnături actualizate ale vulnerabilităților la pornire. Într-un mediu de apărare clasificat, air-gapped, niciuna dintre aceste presupuneri nu se aplică — iar consecințele de inginerie ajung în fiecare strat al lanțului de instrumente. Acest ghid acoperă deciziile arhitecturale, alegerile de instrumente și procedurile operaționale care fac ca integrarea și livrarea continuă să funcționeze în absența accesului la internet, pe infrastructură întărită STIG, în interiorul unui perimetru de acreditare.

De ce CI/CD standard eșuează în medii de apărare air-gapped

Modul de eșec nu este o singură funcționalitate lipsă — este o cascadă de presupuneri integrate în fiecare instrument CI/CD modern, care se dizolvă la contactul cu un perimetru de acreditare air-gapped. Înțelegerea acestor moduri de eșec în avans previne cicluri de achiziție irosite și inversări arhitecturale de ultim moment când începe revizuirea ATO.

Izolarea rețelei. Un enclave clasificat la nivel Secret și superior nu are acces internet de ieșire din proiectare. Runnerele nu pot prelua imagini de la Docker Hub, Maven Central, npmjs.com sau PyPI. Instrumentele de compilare care descarcă plugin-uri sau extensii la prima utilizare eșuează în tăcere sau cu erori criptice despre gazde inaccesibile. Mecanismele de actualizare din Jenkins, GitLab și majoritatea instrumentelor CI comerciale se conectează acasă la pornire — acest trafic este blocat și generează adesea zgomot în consola de monitorizare a rețelei pe care ISSM trebuie să-l explice AO-ului.

Aprobarea și acreditarea software. Fiecare componentă software implementată în interiorul unui perimetru de acreditare DoD trebuie aprobată de Autoritatea de Autorizare (AO) ca parte a Pachetului de Autorizare a Sistemului. Aceasta include nu doar serverul CI, ci fiecare plugin, fiecare imagine a agentului de compilare, fiecare bibliotecă de care depinde pipeline-ul însuși. „Vom folosi cea mai recentă versiune din registrul public" nu este un răspuns acceptabil într-un context ATO. Lista de software aprobat este un document controlat; adăugarea de pachete noi necesită o cerere formală, o scanare de vulnerabilități, o revizuire a licenței și — pentru pachetele fără acoperire STIG existentă — o sarcină suplimentară de documentare pentru echipa de inginerie. Acest proces durează de obicei zile până la săptămâni per pachet, ceea ce face adăugările ad-hoc de dependențe incompatibile cu tempoul de dezvoltare pe care îl cere un pipeline CI modern. Soluția este să se prioritizeze procesul de aprobare prin identificarea fiecărei dependențe înainte ca pipeline-ul să fie implementat, nu după.

Achiziția și licențierea instrumentelor. Unele instrumente CI sunt disponibile în mod simplu pentru contractorii guvernamentali. Unele necesită acorduri de licențiere specifice pentru utilizare guvernamentală. Unele necesită revizuire privind controlul exporturilor (clasificare ITAR/EAR). Jenkins OSS și GitLab CE evită majoritatea acestor probleme, ceea ce explică parțial dominanța lor în mediile clasificate. Platformele CI comerciale care includ runnere proprietare, servicii gestionate de secrete sau analize bazate pe cloud nu sunt în general viabile în interiorul unui enclave air-gapped fără modificări arhitecturale semnificative.

Rezultatul net este că CI/CD air-gapped trebuie proiectat de la principii fundamentale, nu adaptat dintr-un model SaaS comercial. Blocurile de construcție sunt disponibile și dovedite — ele necesită pur și simplu provizionare offline explicită pentru fiecare componentă pe care un pipeline standard ar rezolva-o dinamic. Pentru cadrul DevSecOps mai larg care guvernează aceste decizii, consultați ghidul nostru despre DevSecOps pentru pipeline-urile de apărare.

Arhitectura registrului de artefacte offline

Registrul de artefacte este ancora lanțului de aprovizionare pentru un mediu de compilare air-gapped. Fiecare dependență — JAR-uri, pachete npm, wheel-uri Python, module Go, RPM-uri — trebuie servită din interiorul enclave-ului. Două produse domină acest spațiu în mediile clasificate: Sonatype Nexus Repository (OSS și Pro) și JFrog Artifactory (OSS și Pro). Ambele pot fi implementate pe RHEL fără conectivitate de ieșire necesară pentru operare; ambele suportă formatele de depozit de care are nevoie un proiect software de apărare tipic.

Topologia are două jumătăți. Pe latura joasă (conectată la internet dar neclasificată), o stație de lucru curator rulează aceeași versiune Nexus sau Artifactory ca instanța de pe latura înaltă. Curatorul folosește instrumentele de export/import integrate ale managerului de depozit sau un flux de lucru scriptizat pentru a descărca artefacte aprobate, a rezolva dependențele lor tranzitive, a verifica sumele de control față de hash-urile publicate de registrul upstream și a asambla un pachet de transfer semnat. Pasul de semnare este critic: pachetul de transfer trebuie semnat cu cheia de transfer a programului astfel încât sistemul de pe latura înaltă să poată verifica integritatea înainte de a importa orice.

# 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
            

Pe latura înaltă, instanța Nexus sau Artifactory servește doar depozite găzduite — nu există depozite proxy care să indice URL-uri externe, deoarece acele URL-uri sunt inaccesibile. Fișierele de configurare ale instrumentelor agentului de compilare referențiază doar hostname-ul intern. Un tabel al fișierelor de configurare care necesită modificare:

Cadența de curare este o decizie de politică: de obicei lunară pentru patch-urile de securitate, trimestrială pentru versiunile noi de dependențe și imediată pentru orice CVE cu un scor CVSS peste 8,0. Consiliul de Control al Configurației programului deține decizia pentru fiecare import.

Server CI întărit STIG: Jenkins sau GitLab pe infrastructură clasificată

Cele două opțiuni cele mai comune pentru execuția CI pe infrastructură clasificată sunt Jenkins (opțiunea dominantă de multă vreme, implementată pe scară largă în programele DoD din mijlocul anilor 2010) și GitLab (din ce în ce mai preferată pentru programele noi datorită STIG-ului DISA publicat și funcțiilor integrate DevSecOps). Ambele pot fi făcute conforme; efortul și profilul de risc rezidual diferă.

Pentru Jenkins, linia de bază de întărire este DISA Application Server SRG combinată cu STIG-ul RHEL 9 pentru sistemul de operare de bază. Lista de verificare a întăririi specifice Jenkins acoperă următoarele domenii:

• Dezactivați Jenkins CLI prin remoting (clasa de vulnerabilități CVE-2024-23897); folosiți CLI doar prin SSH dacă este necesar.
• Activați antetele Content Security Policy (CSP) pentru a preveni XSS în ieșirea consolei de compilare.
• Dezactivați accesul la Script Console pentru utilizatorii non-admin; restricționați scăpările din sandbox-ul Groovy.
• Configurați securitate bazată pe matrice cu principiul privilegiului minim: dezvoltatorii pot declanșa compilări, nu pot administra agenți sau credențiale.
• Activați plugin-ul audit-log; redirecționați jurnalele către SIEM-ul enclave-ului.
• Setați JENKINS_HOME pe un sistem de fișiere cu controale de acces; restricționați permisiunile lizibile de toți pe credentials.xml.
• Dezactivați conexiunile la site-ul de actualizări (hudson.model.UpdateCenter.never=true în jenkins.properties).
• Rulați Jenkins ca un cont de serviciu dedicat non-root; aplicați contexte SELinux.

GitLab CE/EE pe RHEL beneficiază de DISA GitLab Enterprise Edition STIG (V1R1, publicat în 2022), care mapează controalele direct la setările de configurare GitLab. Controalele cheie includ aplicarea minimului TLS 1.2, dezactivarea înregistrării și a furnizorilor OAuth, activarea evenimentelor de audit la syslog, restricționarea protocolului Git la SSH pe un port cunoscut și dezactivarea funcțiilor auto-DevOps care fac apeluri de ieșire. Registrul integrat al GitLab, fluxul de lucru merge request și sintaxa YAML a pipeline-ului reduc numărul de componente acreditate separat față de un stack centrat pe Jenkins, ceea ce este adesea factorul decisiv în programele în care termenele ATO sunt limitate.

În oricare dintre cazuri, agenții de compilare trebuie să ruleze în același perimetru de clasificare ca și controlerul. Imaginile agenților sunt construite din imagini de bază aprobate deținute în registrul de containere al enclave-ului și sunt reconstruite pe un program definit (de obicei lunar) pentru a incorpora actualizările de patch-uri ale sistemului de operare transferate prin fluxul de lucru de curare.

Registru de containere deconectat

Imaginile de containere într-un pipeline air-gapped trebuie stocate, scanate și semnate în interiorul enclave-ului. Două produse sunt cele mai comune: Harbor (absolvit CNCF, utilizat pe scară largă în mediile DoD Platform One) și Red Hat Quay (susținut în cadrul acordului Red Hat enterprise al DoD, se integrează strâns cu OpenShift). Ambele suportă semnarea imaginilor OCI, controlul accesului bazat pe roluri și scanarea vulnerabilităților cu baze de date offline.

Populația inițială a registrului urmează același flux de transfer ca și registrul de artefacte: imaginile de bază aprobate (RHEL UBI, imagini Iron Bank întărite, straturi de bază de aplicație aprobate) sunt exportate de pe latura joasă ca arhive OCI, transferate și importate în Harbor sau Quay folosind 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}
            

Semnarea imaginilor cu Cosign în modul offline folosește o cheie de semnare pe termen lung stocată în motorul Transit Vault al enclave-ului, ocolind jurnalul de transparență Sigstore (care este găzduit pe internet). Cheia de semnare este generată în interiorul Vault și nu este niciodată exportată; pipeline-ul CI apelează API-ul Transit Vault pentru a semna rezumatul imaginii și atașează semnătura rezultată ca artefact OCI alături de manifestul imaginii în Harbor. Verificarea la momentul admiterii este gestionată de o politică Kyverno care apelează verificatorul Cosign față de Harbor folosind pachetul de încredere PKI intern al enclave-ului.

# 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
            

Scanarea vulnerabilităților în interiorul registrului folosește Trivy sau Grype configurate cu un pachet de baze de date offline. Baza de date a vulnerabilităților (NVD, OSV, avize RedHat) este descărcată pe latura joasă, transferată pe latura înaltă și încărcată în calea bazei de date locale a scanerului. Un job zilnic de pipeline reîmprospătează pachetul bazei de date prin fluxul de lucru de curare, menținând cunoștințele scanerului actuale în cadrul cadenței de transfer.

Fluxul de transport software: de la sneakernet la serverul de actualizări securizate

Termenul „sneakernet" precede CI/CD, dar conceptul este exact ceea ce face ca livrarea software air-gapped să funcționeze: transportul fizic al datelor între rețele cu niveluri diferite de clasificare. În facilitățile clasificate moderne, acest transport este sistematizat într-un flux de lucru documentat cu porți obligatorii, trasee de audit și cerințe de lanț de custodie care reflectă ceea ce controalele automate ale lanțului de aprovizionare oferă într-un mediu conectat. Provocarea pentru pipeline-urile CI/CD este că timpul ciclului de transport — măsurat de obicei în zile, nu în milisecunde — trebuie integrat în modelul de planificare a lansărilor.

Fluxul de lucru are o structură definită:

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
            

Semnarea pachetelor folosește fie GPG cu chei specifice programului, fie — pe programele care au adoptat instrumente bazate pe PKI — sigstore/cosign față de instanța internă Rekor a programului. Punctul cheie este că cheia de semnare folosită pentru manifestele de transfer este distinctă de cheia folosită pentru semnarea artefactelor de compilare. Cheia de transfer este deținută de rolul curatorului, nu de agenții automați de compilare, deoarece aprobarea transferului este o poartă umană care nu trebuie să fie automatizabilă.

Pentru programele care rulează cicluri de patch-uri cu tempo ridicat, diodele de date hardware unidirecționale (cum ar fi cele de la Owl Cyber Defense sau Waterfall Security) automatizează stratul fizic al transferului păstrând în același timp garanția unidirecțională. Datele curg doar de la nivelul jos la cel înalt; sistemul de pe latura înaltă nu poate trimite niciun trafic înapoi. Aceasta nu elimină poarta de aprobare, dar elimină pasul cu medii amovibile fizice și poate fi folosită pentru a trimite pachete de patch-uri nocturne pe un program definit. Consultați tratamentul nostru mai larg al securității lanțului de aprovizionare pentru software de apărare pentru cadrul de politică care guvernează ce intră în fluxul de transfer.

Automatizarea conformității STIG în pipeline

Listele de verificare STIG manuale sunt incompatibile cu un tempo de livrare continuă. O compilare care se implementează zilnic nu poate fi revizuită manual față de 300+ controale STIG înainte de fiecare lansare. Soluția este conformitatea ca și cod: codificarea controalelor STIG ca politici verificabile de mașină, rularea politicii în pipeline ca poartă automată și generarea de dovezi structurate care satisfac cerințele de monitorizare continuă ale AO-ului.

Lanțul de instrumente principal este OpenSCAP cu SCAP Security Guide (SSG). SSG include conținut XCCDF/OVAL pentru RHEL 8, RHEL 9 și distribuții conexe care mapează direct la STIG-urile DISA. Într-un mediu air-gapped, conținutul SSG este inclus în imaginea agentului de compilare în loc să fie descărcat la runtime:

# 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
            

Aplicația DISA STIG Viewer poate ingera ieșirea results.xml de la OpenSCAP și o poate afișa în formatul familiar de listă de verificare pe care AO-urile și ISSO-urile îl folosesc în timpul recenziilor. Pentru programele care operează un tablou de bord de monitorizare continuă (care alimentează de obicei un SIEM sau un instrument GRC), ieșirea JSON structurată din scriptul de analiză este trimisă la depozitul de dovezi ca artefact pipeline alături de compilare.

Un model comun este separarea scanării STIG la nivel de gazdă (rulată de echipa de infrastructură față de imaginile de bază ale agentului de compilare pe o cadență lunară) de scanarea STIG la nivel de imagine (rulată de pipeline-ul aplicației la fiecare compilare față de containerul livrabil). Constatările la nivel de gazdă afectează ATO-ul infrastructurii CI în sine și sunt urmărite în POA&M-ul sistemului. Constatările la nivel de imagine sunt urmărite la nivelul aplicației și sunt responsabilitatea echipei de dezvoltare. Traseul de audit delimitează clar care echipă deține care constatare, ceea ce contează când un acreditator revizuiește pachetul de dovezi de monitorizare continuă.

Pentru aplicarea SBOM în pipeline-urile de apărare, ieșirea scanării STIG completează SBOM-ul prin furnizarea de dovezi că mediul de runtime în care va executa artefactul este de asemenea conform — nu doar componentele software ale artefactului.

Gestionarea secretelor fără internet: HashiCorp Vault în modul air-gap

Gestionarea secretelor este componenta cel mai susceptibilă de a fi improvizată deficitar în mediile air-gapped. Improvizația comună — stocarea credențialelor în depozitul de credențiale integrat al serverului CI, sau într-un manager de parole partajat, sau în variabile de mediu integrate în imaginile agenților — eșuează aceleași controale de audit pe care le-ar eșua un mediu conectat. Soluția aprobată este un sistem dedicat de gestionare a secretelor implementat în interiorul perimetrului de acreditare.

HashiCorp Vault OSS (open-source, nu Enterprise) nu necesită conectivitate internet pentru operare. Poate fi implementat pe un host RHEL întărit STIG în interiorul enclave-ului, inițializat cu o împărțire a cheii secrete Shamir distribuită între custodii autorizați ai cheilor:

# 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
            

Bootstrapping-ul PKI într-un mediu air-gapped folosește motorul de secrete PKI integrat al Vault pentru a gestiona infrastructura de certificate a programului. Procesul: generați o cheie CA rădăcină și un certificat offline (pe o stație de lucru air-gapped, nu în interiorul Vault), stocați cheia CA rădăcină într-un HSM hardware sau o copie de rezervă criptată offline conform planului de gestionare a cheilor al programului. Importați certificatul CA rădăcină în Vault. În interiorul motorului PKI al Vault, generați o pereche de chei CA intermediare și un CSR, semnați CSR-ul cu CA rădăcină (pas offline), importați certificatul intermediar semnat înapoi în Vault. Din acest moment, Vault emite toate certificatele TLS de scurtă durată pentru serviciile enclave-ului — serverul CI, registrul de artefacte, registrul de containere, managerul de secrete în sine — fără nicio dependență de CA externă.

Autentificarea agentului CI folosește metoda de autentificare AppRole a Vault. Fiecare agent de compilare este provizionat cu un role_id (non-secret, poate fi în configurația agentului) și un secret_id (de scurtă durată, injectat de provizionarul infrastructurii la pornirea agentului). Agentul schimbă acestea pentru un token Vault limitat doar la secretele de care au nevoie compilările sale. Token-urile sunt de scurtă durată (implicit 1 oră, reînnoibile în timpul compilării) și expiră automat după finalizarea compilării. Acest model înseamnă că un agent de compilare compromis nu are acces persistent la secrete — deține doar un token care expiră, nu o credențială care supraviețuiește indefinit.

Rotația secretelor fără acces la internet urmează o ceremonie programată: rotație trimestrială a secretelor statice (chei API, parole ale conturilor de serviciu), rotație anuală a cheilor de semnare. Politicile de rotație integrate ale Vault gestionează sincronizarea; ieșirea fiecărei rotații este înregistrată în jurnalul de audit al Vault, care este redirecționat către SIEM-ul enclave-ului. Pentru secretele dinamice — credențiale de baze de date, certificate PKI — motoarele de secrete dinamice ale Vault generează credențiale per-compilare cu TTL-uri scurte, făcând rotația un non-eveniment deoarece fiecare credențială este deja efemeră.

Disciplina operațională necesară pentru a rula acest stack nu este trivială. Rolurile de curator, procedurile de aprobare a transferurilor, ceremoniile custodelor cheilor și cadențele de scanare lunare sunt angajamente organizaționale, nu decizii de inginerie punctuale. Programele care investesc în documentarea acestor proceduri ca parte a Planului de Securitate a Sistemului (SSP) mai degrabă decât ca cunoștințe tribale informale sunt semnificativ mai rezistente la fluctuația personalului — care, dat fiind cerințele de autorizare de securitate și piața forței de muncă în domeniul apărării, este un risc operațional realist pe orice program de lungă durată.

Pentru stratul de politică al lanțului de aprovizionare care guvernează ce intră în pipeline în primul rând, consultați articolul nostru despre aplicarea SBOM în pipeline-urile de apărare. Stack-ul CI air-gapped descris aici este stratul de execuție; aplicarea SBOM și cadrul mai larg DevSecOps pentru pipeline-urile de apărare sunt stratul de politică care determină ce compilează, scanează și atestă pipeline-ul.