CI/CD-putki puolustusohjelmistoille: automatisoitu testaus ja käyttöönotto sotilasluokan järjestelmissä

Kaupallinen ohjelmistotiimi voi toimittaa uuden ominaisuuden tuotantoon muutamassa minuutissa: pull request läpäisee automaattiset testit, arvioija hyväksyy, CI-putki rakentaa ja ottaa käyttöön. Puolustusohjelmistotiimeille sama toimituspolku joutuu navigoimaan täysin erilaisessa rajoitusten kentässä: ITAR-vientiasetus rajoittaa pääsyä koonteartefakteihin, STIG-vaatimustenmukaisuusvaatimukset määrittävät jokaisen pinokerroksen konfiguraation, SBOM-velvoitteet vaativat koneluettavan inventaarion jokaisesta riippuvuudesta ja käyttöönottoympäristöissä ei välttämättä ole lainkaan internet-yhteyttä. Tuloksena monet puolustusohjelmat joko luopuvat CI/CD:stä kokonaan manuaalisten, porrastettujen julkaisuprosessien hyväksi — tai ottavat käyttöön kaupalliset CI/CD-työkalut ilman vaatimustenmukaisuuskytkentää ja luovat auditointivelvoitteita.

Kumpikaan näistä tuloksista ei ole välttämätön. Puolustusohjelmiston CI/CD-putki, joka täyttää ITAR-hallinnot, tuottaa STIG-yhteensopivia artefakteja, generoi allekirjoitettuja SBOM-dokumentteja ja ottaa käyttöön air gap -ympäristöissä, on saavutettavissa saatavilla olevilla avoimen lähdekoodin työkaluilla ja selkeällä arkkitehtuurimallilla. Tässä artikkelissa kuvataan tuo malli kattaen putkiinfrastruktuurin valinnat, automatisoidut testausvaiheet, SBOM-generoinnin, kontainerien kovennuksen, air gap -käyttöönoton, palautusproseduurit ja auditointipolun vaatimukset.

Puolustusohjelmiston rajoitukset: ITAR, STIG ja luokitustietojen käsittely CI:ssä

International Traffic in Arms Regulations (ITAR) valvoo puolustusartikkelien ja -palveluiden vientiä, mukaan lukien puolustusjärjestelmiin liittyvät tekniset tiedot. CI/CD-kontekstissa lähdekoodi, koonteartefaktit ja testitulokset voivat kaikki olla vientivalvonnan alaisia, ja pääsy on rajoitettava yhdysvaltalaisiin henkilöihin. ITAR-valvottua koodia käsittelevien koontejuoksijoiden on toimittava järjestelmissä, joissa pääsy on pakotettu infrastruktuuritasolla — omahallintaiset juoksijat paikallisessa laitteistossa tai juoksijat FedRAMP High- tai DoD IL4/IL5 -pilvienklaavin dokumentoiduilla pääsynhallintakontrolleilla.

Ohjelman Technology Control Plan (TCP) on sisällytettävä CI/CD-infrastruktuuri soveltamisalaansa. Luokitustietojen käsittely lisää lisärajoituksen: CI/CD-putki itsessään toimii korkeimmalla luokitustasolla, jonka mikä tahansa sen tuottama artefakti edellyttää.

Putkiarkkitehtuuri: paikallinen GitLab vs. SaaS, air gap -näkökohdat

GitLab omahallintaisena on hallitseva CI/CD-alustavaihtoehto arkaluonteisille puolustusohjelmille. Se toimii kokonaan sinun hallitsemassasi infrastruktuurissa, tukee täysin offline-asennusta, integroituu Active Directoryn ja LDAP:n kanssa pääsynhallintaa varten ja sillä on laaja asennuspohja DoD-ohjelmissa. Artefaktirekisterin on myös toimittava sinun hallitsemassasi infrastruktuurissa — Harbor kontainereille, Artifactory tai Nexus kieliekosysteemin riippuvuuksille. Air gap -käyttöönotossa peilipäivitysprosessi siirtää ulkoista sisältöä air gapin yli dokumentoidun aikataulun mukaan.

Automatisoidut testausvaiheet: yksikkötesteistä STIG-vaatimustenmukaisuusskannaukseen

Puolustuksen CI/CD-putki vaatii: yksikkö- ja integraatiotestit jokaisessa commitissa; SAST (Semgrep tai SonarQube) jokaisessa pull requestissa; DAST (OWASP ZAP) käyttöönotettua testiinstanssia vastaan; ohjelmistokoostumusanalyysi (Grype tai Trivy) sisäistä haavoittuvuuspeiliä vastaan; STIG-vaatimustenmukaisuusskannaus (InSpec DISA-profiileilla tai OpenSCAP); salaisuuksien tunnistus; ja lisenssivaatimustenmukaisuus. Jokainen vaihe pysäyttää putken käytäntörikkomuksissa ilman manuaalista ohitusmahdollisuutta.

SBOM-generointi: CycloneDX/SPDX, Grype/Trivy, lisenssivaatimustenmukaisuus

NDAA:n pykälä 1655 (FY2023) ohjasi DoD:ia kehittämään ohjeistusta, joka edellyttää SBOM-dokumentteja ohjelmistotoimittajilta. SBOM:t generoidaan koontaikahetkellä Syftillä tai cdxgenillä CycloneDX- tai SPDX-formaatissa, allekirjoitetaan koonteartefaktin yhteydessä Cosignilla ja tallennetaan artefaktirekisteriin ensimmäisen luokan artefakteina. Grype tai Trivy ristiinviittaavat SBOM-komponentit CVE-tietokantoihin ja tuottavat VEX-annotaatioita. Lisenssivaatimustenmukaisuus pakotetaan rinnakkaisena portina.

Kontainerien kovennus: distroless-perusimaget, non-root-suoritus, seccomp, imagin allekirjoitus

Puolustuksen kontainerikuvat käyttävät distroless- tai DISA STIG-kovennettuja perusimageita, toimivat non-root-käyttäjinä, käyttävät vain luku -juuritiedostojärjestelmiä, soveltavat RuntimeDefault- tai mukautettuja seccomp-profiileita ja allekirjoitetaan Cosignilla tai Notary v2:lla. Pääsynvalvontakontrollerit (OPA/Gatekeeper tai Kyverno) pakostavat nämä vaatimukset podin aikataulutushetkellä kaikissa klustereissa.

Käyttöönotto luokiteltuihin ympäristöihin: sneakernet-siirto, hash-varmistus, manifestin allekirjoitus

Putki tuottaa allekirjoitetun käyttöönottopaketin, joka sisältää: allekirjoitetut binaarit tai kontainerikuvat, SBOM:n, haavoittuvuusskannauksen tulokset, SLSA-provenienssiattestoinnin, käyttöönottomanifesin ja SHA-256-hash-tiedoston. Siirto kulkee air gapin yli akkreditoidun cross-domain-ratkaisun tai dokumentoitujen sneakernet-menettelyjen kautta. Luokitellussa ympäristössä asennusskripti varmistaa hashin ja allekirjoituksen ennen jatkamista.

Palautusproseduurit: blue-green palveluille, SQLite-tilannekuvat sulautetuille järjestelmille

Verkkopalvelut käyttävät blue-green-käyttöönottoja — palautus on liikenteen vaihto, ei uudelleenkäyttöönotto. Sulautetut järjestelmät ja SQLite-pohjaiset sovellukset käyttävät versioituja ennen-päivitystä-tilannekuvia. CI-putki testaa tilannekuva/palautus-polun integraatiotesteissä. Kaikki palautustapahtumat kirjataan muuttumattomaan auditointipolkuun.

Auditointipolun vaatimukset: muuttumattomat lokit, muutoshyväksynnät, vaatimusten jäljitettävyys

Putkilokit tallennetaan kertaluontoiseen SIEM-järjestelmään tai objektisäilöön objektilukituksella. Jokainen käyttöönotto viittaa hyväksyttyyn muutosticketiin. Jäljitettävyys yhdistää kehitystyöelementit vaatimuselementteihin, testitulokset liitettyinä työelementteihin. Putki liittää testitulostivistelmät ja artefaktihashit asianomaiseen issueen käyttöönoton valmistuttua.