DevSecOps — turvallisuuskäytäntöjen integrointi ohjelmistokehityksen ja -toimintojen elinkaareen — ei ole uusi käsite kaupallisessa ohjelmistokehityksessä. Puolustusohjelmistoohjelmissa se on kuitenkin edelleen alue, jossa kuilu pyrkimysten ja käytännön välillä on leveä. Monet puolustusohjelmat toimittavat turvallisuuden edelleen portina kehityssyklin lopussa: tunkeutumistesti, tietoturvatarkistus, akkreditointiprosessi, kaikki tapahtuvat sen jälkeen, kun koodi on toiminnallisesti valmis. Tämä malli on kallis, hidas ja tuottaa ohjelmistoja, joissa on toimituksen jälkeen korjaamiseen kalliita tietoturvapuutteita.
DevSecOps-lähestymistapa siirtää turvallisuuden vasemmalle — integroimalla sen jokaiseen sprinttiin sen sijaan, että se käsitellään julkaisuportina. Tässä artikkelissa selitetään, miksi sprintin lopun tietoturva epäonnistuu puolustuksessa, kuinka integroida SAST, DAST ja SCA automatisoituun putkilinjaan, kuinka käsitellä salaisuuksia ja salaisuudenhallinttaa sekä kuinka ylläpitää STIG-vaatimustenmukaisuutta jatkuvana putkilinjan tuotoksena eikä pistemääräisenä auditointina.
Miksi sprintin lopun tietoturvatarkistus epäonnistuu puolustuksessa
Perinteinen puolustusohjelmiston tietoturvamalli luo rakenteellisen epäyhteensopivuuden: kehittäjät käyttävät kuukausia toiminnallisuuden rakentamiseen, sitten tietoturvatiimi käyttää viikkoja haavoittuvuuksien löytämiseen valmiissa koodissa. Korjaamiskustannus on korkea, koska tietoturvahaavoittuvuuden korjaaminen käyttöönotetussa tai lähes käyttöönotetussa koodissa vaatii regressiotestausta, uudelleentarkistusta ja mahdollisesti useiden riippuvaisten komponenttien uudelleentyöstämistä. NIST:n tutkimus (viitattu SP 800-64:ssä) arvioi, että suunnittelussa löydetyn tietoturvahaavoittuvuuden korjaamisen kustannus on 1x; sama haavoittuvuus testauksessa löydettynä on 15x; ja käyttöönotossa löydettynä 30x tai enemmän.
Puolustusohjelmissa akkreditointiaikataulu vahvistaa tätä ongelmaa. Authority to Operate (ATO) -prosessi — vaatii ennen kuin DoD-järjestelmä voi käsitellä operatiivista dataa — kestää tyypillisesti 6–18 kuukautta uudelle järjestelmälle. Jos tietoturvalöydöksiä ilmenee myöhään kehityksessä, ne pidentävät jo pitkää akkreditointiaikataulua. Yksittäinen korkeavakavuuksinen löydös lopullisen tietoturva-arvioinnin aikana voi viivästyttää ohjelmaa kuukausilla haavoittuvuuden korjaamisen ja arvioinnin toistamisen aikana.
DevSecOps-vaihtoehto: tietoturvatyökalut ajetaan jokaisessa koodicommitissa ja jokaisessa pull requestissa. Kehittäjät saavat tietoturvapalautteen minuuteissa, samassa kehitystyönkulussa, jota he jo käyttävät. Tietoturvavelka poistetaan sprintti kerrallaan sen sijaan, että se kertyy ja maksetaan yhdessä tuskallisessa erässä ohjelman lopussa.
SAST, DAST ja SCA automatisoidussa putkilinjassa
Static Application Security Testing (SAST) analysoi lähdekoodia suorittamatta sitä, etsien malleja, jotka liittyvät tietoturvahaavoittuvuuksiin: SQL-injektio, komentoinjektio, puskurin ylivuoto, kovakoodatut tunnukset, turvattomat kryptografiset funktiokutsut ja satoja muita heikkousmalleja. SAST ajetaan jokaisessa commitissa ja pull requestissa osana CI-putkilinjaa.
Semgrep on avoimen lähdekoodin SAST-työkalu, josta on tullut standardi moderneissa DevSecOps-putkilinjoissa. Sen sääntöpohjainen lähestymistapa mahdollistaa räätälöityjen sääntöjen kirjoittamisen organisaatiokohtaisille tietoturvakäytännöille, ja sen nopeus (tyypillisesti alle 30 sekuntia keskikokoiselle koodikannalle) tekee siitä sopivan pull request -palautteeseen. Semgrep ylläpitää kuratoitua sääntöjoukkoa yleisille haavoittuvuusluokille ja tukee sääntöjä DoD-kohtaisille tietoturvahuolille (esim. CNSA-käytäntöjen kieltämät turvattomat krypto-primitiivit).
Dynamic Application Security Testing (DAST) testaa toimivaa sovellusta simuloimalla hyökkääjän käyttäytymistä: lähettää räätälöityjä HTTP-pyyntöjä, yrittää injektiohyökkäyksiä, testaa todennusmekanismeja. OWASP ZAP (Zed Attack Proxy) on standardi avoimen lähdekoodin DAST-työkalu. CI/CD-putkilinjassa ZAP ajetaan "headless"-tilassa käyttöön otettua testiinstanssia vastaan, tuottaen löydösraportin, joka julkaistaan tietoturvakojelautaan.
Software Composition Analysis (SCA) tunnistaa tunnettuja haavoittuvuuksia kolmansien osapuolten kirjastoissa ja avoimen lähdekoodin riippuvuuksissa. Koska modernit sovellukset koostuvat tyypillisesti 70–90-prosenttisesti kolmannen osapuolen koodista komponenttimäärän perusteella, SCA on kriittinen puolustusohjelmille, joissa on toimitusketjun tietoturvahuolia. Grype (Anchorelta) ja Trivy (Aqua Securityltä) ovat kaksi johtavaa avoimen lähdekoodin SCA-työkalua.
Salaisuuksien havaitseminen: tunnusvuotojen estäminen puolustusputkilinjoissa
Kovakoodatut salaisuudet — API-avaimet, tietokantasalasanat, yksityiset avaimet, käyttöoikeustokenit — lähdekoodivarastoissa ovat toistuva tietoturvaongelma. Puolustusohjelmistolle seuraukset ovat vakavia: luokitellun järjestelmän taustapään vuotanut API-avain voi antaa vastustajalle suoran pääsyn kyseiseen järjestelmään ilman sovelluskerroksen hyväksikäyttöä.
Pre-commit-koukut ovat ensimmäinen puolustusmuuri: git-koukut, jotka ajetaan ennen kuin commit hyväksytään, skannaten vaiheistetut muutokset tunnettujen salaisuusformaattien malleille. Kaksi työkalua hallitsee tätä tilaa: detect-secrets (Yelpiltä, laajalti käytetty yrityksen DevSecOps:ssä) ja Gitleaks (tarkoitettu git-historian ja pre-commit-skannauksen). Molemmat ylläpitävät mallicikirjastoja sadoille salaisuustyypeille.
HashiCorp Vault tarjoaa positiivisen vaihtoehdon kovakoodatuille salaisuuksille: keskitetty salaisuudenhallintajärjestelmä, jota sovellukset kyselevät ajonaikana tunnusten hakemiseen sen sijaan, että ne tallennetaan konfiguraatiotiedostoihin tai ympäristömuuttujiin. Vaultin dynaamisten salaisuuksien ominaisuus tuottaa lyhytaikaisia, automaattisesti vanhentuvia tunnuksia jokaiselle sovelluspyynnölle. Puolustusputkilinjoissa Vault otetaan tyypillisesti käyttöön on-premises (ei Vault-pilvipalvelua).
Konttikuvaskannaus puolustusrekistereissä
Konttiympäristöistä on tullut standardi puolustusohjelmistoohjelmissa — Kubernetes-käyttöönotot DoD-alustoilla, kuten Platform One (P1), käyttävät konttikuvia käyttöönottoyksikköinä. Konttikuvat voivat kantaa haavoittuvuuksia perusimageistaan ja kuvien rakennusprosessin aikana asennetuista paketeista. Konttikuvaskannaus integroi haavoittuvuushavaitsemisen konttien rakentamis- ja rekisteritiönkulkuun.
Harbor on CNCF-graduated avoimen lähdekoodin konttisäilö, jossa on sisäänrakennettu tietoturvaskannaus. Puolustuksen DevSecOps-putkilinjassa Harbor toimii organisaation konttikuvien rekisterinä ja skannaa kuvat automaattisesti Trivyllä skannerin taustana. Skannauksen tulokset liitetään kuhunkin kuvaan rekisterissä.
Käyttöönottokontrollikäytännöt pakottavat tietoturvavalvonnan Kubernetes API -tasolla: kaikki yritykset ottaa käyttöön pod arvioidaan käytäntöjoukkoa vastaan ennen sen pääsyä klusteriin. Puolustusympäristöissä käytännöt pakottavat: ei kuvia varmentamattomista rekistereistä, ei kontteja root-käyttöoikeuksilla, ei privileged-kontteja. OPA/Gatekeeper ja Kyverno ovat standardit käyttöönottokontrolliviitekehykset.
Akkreditointitietoinen CI/CD: STIG-vaatimustenmukaisuuden ylläpito
Security Technical Implementation Guides (STIG:t) ovat DISA:n (Defense Information Systems Agency) julkaisemia konfiguraatiostandardeja, jotka määrittelevät tietoturvakonfiguraatiovaatimukset jokaiselle DoD-järjestelmissä käytetylle teknologiakategorialle. STIG-vaatimustenmukaisuus on kova vaatimus DoD ATO:lle, ei suositeltu parhaita käytäntöjä.
Perinteinen STIG-vaatimustenmukaisuuden validointi suoritetaan manuaalisesti auditointiaikana. Akkreditointitietoinen CI/CD-putkilinja käsittelee STIG-vaatimustenmukaisuuden jatkuvana tuotoksena. InSpec (Chefiltä) STIG-profiileilla tai OpenSCAP tarjoaa ohjelmallisen STIG-vaatimustenmukaisuustarkistuksen, joka voidaan ajaa putkilinjavaiheen. Konttikuvat rakennetaan STIG-kovennuista perusalustoista (DISA:n julkaisemista STIG-kovennuista perusimageista), ja vaatimustenmukaisuus tarkistetaan rakennusaikana.
Keskeinen oivallus: Organisaatiohaaste puolustuksen DevSecOps:ssa ei ole tekninen — työkalut ovat saatavilla, kypsiä ja todistettuja. Haaste on kulttuurinen ja prosessuaalinen integraatio: tietoturvatiimien on siirryttävä tarkastajista, jotka arvioivat valmistuneen työn, kumppaneiksi, jotka tarjoavat työkaluja ja standardeja, joita kehitystiimit käyttävät jatkuvasti. Kehitystiimien on hyväksyttävä tietoturvapalaute normaalina osana työnkulkuaan, ei ulkoisena auditointina. Ohjelmat, jotka saavuttavat tämän integraation, toimittavat johdonmukaisesti turvallisemman ohjelmiston nopeammin kuin ohjelmat, jotka ylläpitävät perinteistä erottelua.