Potoki CI/CD dla izolowanych środowisk obronnych (air-gapped)

Standardowe potoki CI/CD są budowane przy założeniu wszechobecnej łączności z Internetem. Każdy runner pobiera obraz bazowy z publicznego rejestru, każda kompilacja rozwiązuje zależności z repozytoriów pakietów upstream, każde narzędzie skanujące pobiera aktualne sygnatury podatności przy uruchomieniu. W niejawnym, izolowanym środowisku obronnym (air-gapped) żadne z tych założeń nie jest spełnione — a konsekwencje inżynierskie sięgają każdej warstwy łańcucha narzędzi. Niniejszy przewodnik omawia decyzje architektoniczne, wybory narzędziowe i procedury operacyjne, które umożliwiają ciągłą integrację i dostarczanie bez dostępu do Internetu, na infrastrukturze wzmocnionej zgodnie ze STIG, w granicach akredytacji.

Dlaczego standardowe CI/CD zawodzi w izolowanych środowiskach obronnych

Tryb awarii to nie jeden brakujący element — to kaskada założeń wbudowanych w każde nowoczesne narzędzie CI/CD, które rozpada się w kontakcie z granicą akredytacji air-gapped. Zrozumienie tych trybów awarii z wyprzedzeniem zapobiega marnotrawnym cyklom zamówień i lastminute'owym odwrotom architektonicznym, gdy rozpoczyna się przegląd ATO.

Izolacja sieci. Niejawna enklawa na poziomie Secret i wyżej nie ma domyślnie dostępu wychodzącego do Internetu. Runnery nie mogą pobierać obrazów z Docker Hub, Maven Central, npmjs.com ani PyPI. Narzędzia kompilacji pobierające wtyczki lub rozszerzenia przy pierwszym użyciu kończą się błędem cichym lub z kryptycznym komunikatem o nieosiągalnych hostach. Mechanizmy aktualizacji w Jenkins, GitLab i większości komercyjnych narzędzi CI kontaktują się z serwerem zewnętrznym przy uruchomieniu — ruch ten jest blokowany i często generuje szum w konsoli monitorowania sieci, który ISSM musi wytłumaczyć AO.

Zatwierdzenie i akredytacja oprogramowania. Każdy komponent oprogramowania wdrożony w granicach akredytacji DoD musi być zatwierdzony przez Authorizing Official (AO) jako część System Authorization Package. Obejmuje to nie tylko serwer CI, ale każdą wtyczkę, każdy obraz agenta kompilacji, każdą bibliotekę, od której sam potok jest zależny. „Użyjemy najnowszej wersji z publicznego rejestru" nie jest akceptowalną odpowiedzią w kontekście ATO. Zatwierdzona lista oprogramowania jest dokumentem kontrolowanym; dodawanie nowych pakietów wymaga formalnego wniosku, skanowania podatności, przeglądu licencji i — dla pakietów bez istniejącego pokrycia STIG — dodatkowego obciążenia dokumentacyjnego zespołu inżynierów. Proces ten trwa zwykle od kilku dni do kilku tygodni na pakiet, co sprawia, że doraźne dodawanie zależności jest niekompatybilne z tempem rozwoju, jakiego wymaga nowoczesny potok CI. Rozwiązaniem jest przyspieszenie procesu zatwierdzania poprzez identyfikację każdej zależności przed wdrożeniem potoku, a nie po nim.

Zamówienia i licencjonowanie narzędzi. Część narzędzi CI jest wprost dostępna dla wykonawców rządowych. Część wymaga szczególnych umów licencyjnych do użytku rządowego. Część wymaga przeglądu kontroli eksportu (klasyfikacja ITAR/EAR). Jenkins OSS i GitLab CE omijają większość tych problemów, co częściowo wyjaśnia ich dominację w środowiskach niejawnych. Komercyjne platformy CI łączące zastrzeżone runnery, zarządzane usługi sekretów lub analitykę chmurową na ogół nie są wykonalne w izolowanej enklawie bez znaczącej modyfikacji architektonicznej.

Efekt netto jest taki, że air-gapped CI/CD musi być projektowane od podstaw, a nie adaptowane ze wzorca komercyjnego SaaS. Elementy składowe są dostępne i sprawdzone — wymagają jedynie jawnego zapewnienia offline dla każdego komponentu, który standardowy potok rozwiązałby dynamicznie. W szerszym kontekście DevSecOps, który reguluje te decyzje, zapoznaj się z naszym przewodnikiem po DevSecOps dla potoków obronnych.

Architektura offline rejestru artefaktów

Rejestr artefaktów jest kotwicą łańcucha dostaw dla środowiska kompilacji air-gapped. Każda zależność — pliki JAR, pakiety npm, koła Python, moduły Go, pakiety RPM — musi być serwowana z wnętrza enklawy. Dwa produkty dominują w tej dziedzinie w środowiskach niejawnych: Sonatype Nexus Repository (OSS i Pro) oraz JFrog Artifactory (OSS i Pro). Oba można wdrożyć na RHEL bez wymaganej łączności wychodzącej dla działania; oba obsługują formaty repozytoriów potrzebne typowemu projektowi oprogramowania obronnego.

Topologia ma dwie połówki. Po niskiej stronie (podłączonej do Internetu, ale nieniejawnej) stacja robocza kuratora uruchamia tę samą wersję Nexusa lub Artifactory co instancja po wysokiej stronie. Kurator używa wbudowanych narzędzi eksportu/importu menedżera repozytoriów lub skryptowanego przepływu pracy, aby pobierać zatwierdzone artefakty, rozwiązywać ich zależności przechodnie, weryfikować sumy kontrolne względem opublikowanych skrótów rejestru upstream i składać podpisany pakiet transferowy. Krok podpisywania jest krytyczny: pakiet transferowy musi być podpisany kluczem transferowym programu, aby system po wysokiej stronie mógł zweryfikować integralność przed zaimportowaniem czegokolwiek.

# Kurator po niskiej stronie: złożenie i podpisanie pakietu transferowego
nexus-curator export \
  --format maven \
  --repos approved-central-proxy \
  --output /transfer/bundle-2026-06-24.tar.gz

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

# Podpisanie manifestu GPG kluczem transferowym programu
gpg --detach-sign --armor \
  --local-user transfer@program.mil \
  /transfer/bundle-2026-06-24.manifest

# Transfer fizyczny przez zaszyfrowane nośniki wymienne lub diodę danych
# ...

# Import po wysokiej stronie: weryfikacja przed wypakowaniem
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
            

Po wysokiej stronie instancja Nexusa lub Artifactory serwuje wyłącznie repozytoria hostowane — nie ma repozytoriów proxy wskazujących na zewnętrzne URL, ponieważ te URL są nieosiągalne. Pliki konfiguracyjne narzędzi agentów kompilacji odwołują się wyłącznie do wewnętrznej nazwy hosta. Tabela plików konfiguracyjnych wymagających modyfikacji:

Częstotliwość kuracji jest decyzją polityczną: zazwyczaj miesięcznie dla poprawek bezpieczeństwa, kwartalnie dla nowych wersji zależności i natychmiastowo dla każdego CVE z wynikiem CVSS powyżej 8.0. Decyzja o każdym imporcie należy do Configuration Control Board programu.

Serwer CI wzmocniony zgodnie ze STIG: Jenkins lub GitLab na infrastrukturze niejawnej

Dwa najczęstsze wybory dla wykonania CI na infrastrukturze niejawnej to Jenkins (opcja dominująca od dawna, szeroko wdrożona w programach DoD od połowy lat 2010) i GitLab (coraz bardziej preferowany dla nowych programów ze względu na opublikowany STIG DISA i zintegrowane funkcje DevSecOps). Oba mogą być dostosowane do wymogów zgodności; nakład pracy i profil ryzyka rezydualnego różnią się.

Dla Jenkins, bazą wzmocnienia jest DISA Application Server SRG w połączeniu z RHEL 9 STIG dla bazowego systemu operacyjnego. Lista kontrolna wzmocnienia specyficzna dla Jenkins obejmuje następujące obszary:

• Wyłączenie Jenkins CLI przez zdalność (klasa podatności CVE-2024-23897); używanie CLI tylko przez SSH, jeśli jest to konieczne.
• Włączenie nagłówków Content Security Policy (CSP) w celu zapobiegania XSS w wyjściu konsoli kompilacji.
• Wyłączenie dostępu do Script Console dla użytkowników innych niż administrator; ograniczenie ucieczek piaskownicy Groovy.
• Konfiguracja zabezpieczeń opartych na macierzy z zasadą najmniejszych uprawnień: programiści mogą wyzwalać kompilacje, nie mogą administrować agentami ani danymi uwierzytelniającymi.
• Włączenie wtyczki audit-log; przekazywanie logów do SIEM enklawy.
• Ustawienie JENKINS_HOME na systemie plików z kontrolą dostępu; ograniczenie uprawnień do odczytu dla wszystkich na credentials.xml.
• Wyłączenie połączeń z witryną aktualizacji (hudson.model.UpdateCenter.never=true w jenkins.properties).
• Uruchomienie Jenkins jako dedykowane konto usługi bez uprawnień roota; zastosowanie kontekstów SELinux.

GitLab CE/EE na RHEL korzysta z DISA GitLab Enterprise Edition STIG (V1R1, opublikowany 2022), który mapuje kontrole bezpośrednio na ustawienia konfiguracyjne GitLab. Kluczowe kontrole obejmują wymuszanie minimum TLS 1.2, wyłączanie rejestracji i dostawców OAuth, włączanie zdarzeń audytu do syslog, ograniczanie protokołu Git do SSH przez znany port i wyłączanie funkcji auto-DevOps wykonujących połączenia wychodzące. Zintegrowany rejestr GitLab, przepływ żądań scalania i składnia YAML potoku zmniejszają liczbę osobno akredytowanych komponentów w porównaniu ze stosem skoncentrowanym na Jenkins, co często jest czynnikiem decydującym w programach, gdzie harmonogramy ATO są ograniczone.

W obu przypadkach agenty kompilacji muszą działać w tych samych granicach klasyfikacji co kontroler. Obrazy agentów są budowane z zatwierdzonych obrazów bazowych przechowywanych w rejestrze kontenerów enklawy i są przebudowywane według określonego harmonogramu (zazwyczaj miesięcznie) w celu włączenia aktualizacji łatek systemu operacyjnego przeniesionych przez przepływ kuracji.

Odłączony rejestr kontenerów

Obrazy kontenerów w potoku air-gapped muszą być przechowywane, skanowane i podpisywane wewnątrz enklawy. Dwa produkty są najbardziej powszechne: Harbor (ukończony projekt CNCF, szeroko stosowany w środowiskach DoD Platform One) i Red Hat Quay (obsługiwany w ramach korporacyjnej umowy Red Hat DoD, ściśle zintegrowany z OpenShift). Oba obsługują podpisywanie obrazów OCI, kontrolę dostępu opartą na rolach i skanowanie podatności z offline bazami danych.

Początkowe zasilanie rejestru odbywa się tym samym przepływem transferu co rejestr artefaktów: zatwierdzone obrazy bazowe (RHEL UBI, wzmocnione obrazy Iron Bank, zatwierdzone warstwy bazy aplikacji) są eksportowane z niskiej strony jako archiwum OCI, transferowane i importowane do Harbor lub Quay przy użyciu skopeo copy:

# Niska strona: eksport zatwierdzonych obrazów jako archiwów OCI
skopeo copy \
  docker://registry.access.redhat.com/ubi9/ubi:9.4 \
  oci-archive:/transfer/ubi9-9.4.tar \
  --override-os linux

# Wygenerowanie i podpisanie manifestu
sha256sum /transfer/ubi9-9.4.tar >> /transfer/images.manifest
gpg --detach-sign --armor --local-user transfer@program.mil \
    /transfer/images.manifest

# Wysoka strona: weryfikacja i 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}
            

Podpisywanie obrazów za pomocą Cosign w trybie offline używa długotrwałego klucza podpisywania przechowywanego w silniku Transit Vault enklawy, pomijając log przejrzystości Sigstore (który jest hostowany w Internecie). Klucz podpisywania jest generowany wewnątrz Vault i nigdy nie jest eksportowany; potok CI wywołuje Transit API Vault, aby podpisać skrót obrazu i dołączyć wynikowy podpis jako artefakt OCI obok manifestu obrazu w Harbor. Weryfikacja w czasie przyjęcia jest obsługiwana przez politykę Kyverno, która wywołuje weryfikator Cosign w Harbor przy użyciu wewnętrznego pakietu zaufania PKI enklawy.

# Podpisywanie obrazu za pomocą klucza Transit Vault (bez logu przejrzystości)
cosign sign \
  --key hashivault://transit/keys/image-signing-key \
  --no-tlog-upload \
  harbor.enclave.mil/myapp/service:v1.4.2@sha256:abc123...

# Polityka Kyverno: wymaganie ważnego podpisu Cosign na każdym podzie
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-----
              ... (klucz publiczny podpisywania enklawy) ...
              -----END PUBLIC KEY-----
            rekor:
              ignoreTlog: true
            

Skanowanie podatności wewnątrz rejestru używa Trivy lub Grype skonfigurowanego z offline pakietem bazy danych. Baza danych podatności (NVD, OSV, zalecenia RedHat) jest pobierana po niskiej stronie, transferowana na wysoką stronę i ładowana do lokalnej ścieżki bazy danych skanera. Codzienne zadanie potoku odświeża pakiet bazy danych przez przepływ kuracji, utrzymując wiedzę skanera aktualną w ramach cyklu transferu.

Przepływ transportu oprogramowania: sneakernet do bezpiecznego serwera aktualizacji

Termin „sneakernet" poprzedza CI/CD, ale koncepcja jest właśnie tym, co umożliwia funkcjonowanie dostarczania oprogramowania air-gapped: fizyczny transport danych między sieciami różnych poziomów klasyfikacji. W nowoczesnych niejawnych obiektach ten transport jest zorganizowany w udokumentowany przepływ pracy z obowiązkowymi bramami, ścieżkami audytu i wymaganiami dotyczącymi łańcucha nadzoru, które odzwierciedlają to, co zautomatyzowane kontrole łańcucha dostaw zapewniają w środowisku podłączonym. Wyzwaniem dla potoków CI/CD jest to, że czas cyklu transportu — zazwyczaj mierzony w dniach, nie milisekundach — musi być wbudowany w model planowania wydania.

Przepływ ma zdefiniowaną strukturę:

Stacja robocza po niskiej stronie (NIEJAWNA)
    │
    ├─ [1] Złożenie zestawu pakietów kandydatów
    │      - pobieranie, rozwiązywanie zależności przechodnich
    │      - weryfikacja podpisów/sum kontrolnych upstream
    │      - skanowanie antymalware (ClamAV / komercyjny AV)
    │      - skanowanie podatności (Grype offline db)
    │      - przegląd licencji
    │
    ├─ [2] Generowanie podpisanego manifestu
    │      sha256sum * > manifest.txt
    │      gpg --detach-sign manifest.txt
    │
    ├─ [3] Zgłoszenie wniosku o transfer (bilet CMT/JIRA)
    │      - nazwa pakietu, wersja, cel, licencja
    │      - dołączone wyniki skanowania podatności
    │
    ├─ [4] Przegląd i zatwierdzenie ISSO/AO (Brama)
    │
    ├─ [5] Transfer fizyczny
    │      - zaszyfrowany USB (zatwierdzone FIPS 140-2)
    │      - LUB sprzętowa dioda danych (jednokierunkowa)
    │      - utworzenie wpisu w dzienniku transferu
    │
Bezpieczny serwer aktualizacji po wysokiej stronie (NIEJAWNY)
    │
    ├─ [6] Weryfikacja podpisu manifestu
    │      gpg --verify manifest.txt.asc manifest.txt
    │      sha256sum -c manifest.txt
    │
    ├─ [7] Import do Nexus / Harbor
    │
    └─ [8] Rejestracja w narzędziu do zarządzania konfiguracją
            

Podpisywanie pakietów używa GPG z kluczami specyficznymi dla programu lub — w programach, które przyjęły narzędzia oparte na PKI — sigstore/cosign względem wewnętrznej instancji Rekor programu. Kluczowym punktem jest to, że klucz podpisywania używany do manifestów transferowych różni się od klucza używanego do podpisywania artefaktów kompilacji. Klucz transferowy jest przechowywany przez rolę kuratora, nie przez automatycznych agentów kompilacji, ponieważ zatwierdzenie transferu jest bramą ludzką, która nie może być zautomatyzowana.

W programach realizujących szybkie cykle aktualizacji łatek, jednokierunkowe sprzętowe diody danych (takie jak te od Owl Cyber Defense lub Waterfall Security) automatyzują fizyczną warstwę transferu, zachowując gwarancję jednokierunkowości. Dane przepływają tylko z niskiej do wysokiej strony; system po wysokiej stronie nie może wysyłać żadnego ruchu zwrotnego. Nie eliminuje to bramy zatwierdzania, ale eliminuje krok z fizycznym nośnikiem wymiennym i może być używane do przesyłania nocnych pakietów łatek według określonego harmonogramu. Zapoznaj się z naszym szerszym omówieniem bezpieczeństwa łańcucha dostaw dla oprogramowania obronnego, aby poznać ramy polityki, które regulują to, co wchodzi do przepływu transferu.

Automatyzacja zgodności ze STIG w potoku

Ręczne listy kontrolne STIG są niekompatybilne z tempem ciągłego dostarczania. Kompilacja wdrażana codziennie nie może być ręcznie przeglądana względem ponad 300 kontrolek STIG przed każdym wydaniem. Rozwiązaniem jest zgodność jako kod: kodowanie kontrolek STIG jako zasad sprawdzalnych maszynowo, uruchamianie zasad w potoku jako zautomatyzowanej bramy i generowanie ustrukturyzowanych dowodów spełniających wymagania AO dotyczące ciągłego monitorowania.

Główny łańcuch narzędzi to OpenSCAP z SCAP Security Guide (SSG). SSG dostarcza zawartość XCCDF/OVAL dla RHEL 8, RHEL 9 i powiązanych dystrybucji, która mapuje bezpośrednio do DISA STIG. W środowisku air-gapped zawartość SSG jest dołączana do obrazu agenta kompilacji, a nie pobierana w czasie wykonywania:

# Etap potoku: skanowanie STIG dostarczonego obrazu kontenera
stages:
  - build
  - stig-scan
  - sign
  - promote

stig-scan:
  stage: stig-scan
  image: harbor.enclave.mil/tools/openscap-runner:latest
  script:
    - |
      # Montowanie systemu plików obrazu kontenera do skanowania
      skopeo copy \
        docker://harbor.enclave.mil/${CI_PROJECT_PATH}:${CI_COMMIT_SHA} \
        oci:./image-under-test

      # Uruchomienie oceny profilu STIG
      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

      # Blokowanie przy jakichkolwiek błędach CAT I (wysokie zagrożenie)
      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
            

Aplikacja DISA STIG Viewer może pobierać dane wyjściowe results.xml z OpenSCAP i wyświetlać je w znanych formacie listy kontrolnej używanym przez AO i ISSO podczas przeglądów. W programach obsługujących pulpit ciągłego monitorowania (zazwyczaj zasilający SIEM lub narzędzie GRC), ustrukturyzowane wyjście JSON ze skryptu parsującego jest przesyłane do repozytorium dowodów jako artefakt potoku obok kompilacji.

Powszechnym wzorcem jest oddzielenie skanowania STIG na poziomie hosta (przeprowadzanego przez zespół infrastruktury względem bazowych obrazów agentów kompilacji co miesiąc) od skanowania STIG na poziomie obrazu (przeprowadzanego przez potok aplikacji przy każdej kompilacji względem dostarczonego kontenera). Wyniki na poziomie hosta wpływają na ATO infrastruktury CI i są śledzone w POA&M systemu. Wyniki na poziomie obrazu są śledzone na poziomie aplikacji i są odpowiedzialnością zespołu programistycznego. Ścieżka audytu wyraźnie określa, który zespół jest właścicielem danego wyniku, co ma znaczenie, gdy akredytator przegląda pakiet dowodów ciągłego monitorowania.

W przypadku egzekwowania SBOM w potokach obronnych, wynik skanowania STIG uzupełnia SBOM, dostarczając dowodów, że środowisko uruchomieniowe, w którym artefakt będzie wykonywany, jest również zgodne — nie tylko komponenty oprogramowania artefaktu.

Zarządzanie sekretami bez Internetu: HashiCorp Vault w trybie air-gap

Zarządzanie sekretami to komponent, który najczęściej jest prowizoryczno improwizowany w środowiskach air-gapped. Powszechna improwizacja — przechowywanie danych uwierzytelniających w wbudowanym magazynie danych uwierzytelniających serwera CI, w menedżerze haseł współdzielonym lub w zmiennych środowiskowych wbudowanych w obrazy agentów — nie spełnia tych samych kontrolek audytu, które nie spełniałoby w środowisku podłączonym. Zatwierdzoną roziązaniem jest dedykowany system zarządzania sekretami wdrożony w granicach akredytacji.

HashiCorp Vault OSS (open-source, nie Enterprise) nie wymaga łączności z Internetem do działania. Można go wdrożyć na hoście RHEL wzmocnionym zgodnie ze STIG wewnątrz enklawy, zainicjalizowanym z podziałem klucza tajnego Shamir rozdzielonym między autoryzowanych opiekunów kluczy:

# Inicjalizacja Vault z 5 udziałami kluczy, progiem 3
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# Przykładowe wyjście (każdy udział trafia do osobnego opiekuna):
# 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 (użyj raz, następnie unieważnij)

# Odpieczętowanie przy użyciu 3 z 5 udziałów (ceremonia oddzielnych operatorów)
vault operator unseal  # wprowadź udział 1
vault operator unseal  # wprowadź udział 2
vault operator unseal  # wprowadź udział 3
            

Bootstrapping PKI w środowisku air-gapped używa wbudowanego silnika sekretów PKI Vault do zarządzania infrastrukturą certyfikatów programu. Proces: generowanie klucza CA roota i certyfikatu offline (na stacji roboczej air-gapped, nie wewnątrz Vault), przechowywanie klucza CA roota w sprzętowym HSM lub zaszyfrowanej kopii zapasowej offline zgodnie z planem zarządzania kluczami programu. Import certyfikatu CA roota do Vault. Wewnątrz silnika PKI Vault generowanie pary kluczy pośredniego CA i CSR, podpisanie CSR przez CA roota (krok offline), import podpisanego pośredniego certyfikatu do Vault. Od tego momentu Vault wydaje wszystkie krótkoterminowe certyfikaty TLS dla usług enklawy — serwera CI, rejestru artefaktów, rejestru kontenerów, samego menedżera sekretów — bez żadnej zewnętrznej zależności od CA.

Uwierzytelnianie agentów CI używa metody uwierzytelniania AppRole Vault. Każdy agent kompilacji jest inicjowany z role_id (nieupoważnionym, może znajdować się w konfiguracji agenta) i secret_id (krótkotrwałym, wstrzykniętym przez aprowizatora infrastruktury przy uruchomieniu agenta). Agent wymienia te dane na token Vault ograniczony tylko do sekretów wymaganych przez jego kompilacje. Tokeny są krótkotrwałe (domyślnie 1 godzina, odnawialne podczas kompilacji) i automatycznie wygasają po zakończeniu kompilacji. Ten wzorzec oznacza, że skompromitowany agent kompilacji nie ma trwałego dostępu do sekretów — posiada tylko token, który wygasa, nie dane uwierzytelniające, które przetrwają bezterminowo.

Rotacja sekretów bez dostępu do Internetu odbywa się według zaplanowanej ceremonii: kwartalna rotacja sekretów statycznych (klucze API, hasła kont usług), roczna rotacja kluczy podpisywania. Wbudowane polityki rotacji Vault obsługują taktowanie; wynik każdej rotacji jest rejestrowany w dzienniku audytu Vault, który jest przekazywany do SIEM enklawy. W przypadku sekretów dynamicznych — danych uwierzytelniających bazy danych, certyfikatów PKI — dynamiczne silniki sekretów Vault generują dane uwierzytelniające per-kompilacja z krótkimi TTL, co czyni rotację zdarzeniem niepowodującym problemów, ponieważ każde dane uwierzytelniające są już efemeryczne.

Dyscyplina operacyjna wymagana do obsługi tego stosu jest nietrywalna. Role kuratorów, procedury zatwierdzania transferów, ceremonie opiekunów kluczy i miesięczne cykle skanowania to zobowiązania organizacyjne, a nie jednorazowe decyzje inżynierskie. Programy inwestujące w dokumentowanie tych procedur jako części System Security Plan (SSP), a nie jako nieformalną wiedzę plemienną, są znacznie bardziej odporne na rotację personelu — co, biorąc pod uwagę wymagania dotyczące uprawnień i rynek pracy w sektorze obronnym, jest realistycznym ryzykiem operacyjnym w każdym długotrwałym programie.

Warstwę polityki łańcucha dostaw, która reguluje to, co wchodzi do potoku, można znaleźć w naszym artykule o egzekwowaniu SBOM w potokach obronnych. Opisany tutaj stos CI air-gapped to warstwa wykonawcza; egzekwowanie SBOM i szersze ramy DevSecOps dla potoków obronnych to warstwa polityki, która określa, co potok buduje, skanuje i zaświadcza.