Kysymys siitä, sopiiko avoimen lähdekoodin ohjelmisto (OSS) puolustusjärjestelmiin, ratkaistiin pitkälti 2000- ja 2010-luvuilla: vastaus on kyllä, asianmukaisen hallinnan kanssa. Yhdysvaltain puolustusministeriön vuoden 2009 politiikkamuistio avoimen lähdekoodin ohjelmistosta oli yksi ensimmäisistä muodollisista lausumista, jonka mukaan OSS:ää on arvioitava samoilla kriteereillä kuin omistusoikeudellista ohjelmistoa — ei yleistä kieltoa, ei yleistä etusijaa, mutta tapauskohtainen arviointi. Tämä salliva-mutta-hallittu-kanta on nyt käytännössä yleismaailmallinen demokratioiden puolustushankintakehyksissä.
Nykyinen haaste ei ole se, käytetäänkö OSS:ää, vaan miten sitä hallitaan tiukasti. Nykyaikaiset puolustusohjelmistot sisältävät tyypillisesti satoja avoimen lähdekoodin komponentteja — käyttöjärjestelmäkirjastoja, kryptografiakirjastoja, verkkopinoja, datankäsittelykehyksiä. Vuoden 2024 XZ Utils -takaovitapaus, jossa vihamielinen toimija käytti kaksi vuotta uskottavuuden rakentamiseen avoimen lähdekoodin projektissa ennen kehittyneen takaoven lisäämistä, osoitti, että OSS-toimitusketjuriskit eivät ole teoreettisia. Tässä artikkelissa tarkastellaan nykyistä politiikkamaisemaa, todellisia riskiluokkia ja hallintokäytäntöjä, joita tehokkaat ohjelmat soveltavat.
DoD:n ja liittolaisten OSS-politiikka: nykyinen salliva-mutta-hallittu-kanta
Yhdysvaltain DoD:n nykyinen kanta OSS:ään on kuvattu useissa politiikka-asiakirjoissa: vuoden 2009 CIO-muistio, vuoden 2016 Defense Innovation Board -ohjelmistohankintakäytäntöjen suositukset ja vuoden 2022 DoD-ohjelmiston modernisointistrategia. Johdonmukainen lanka on se, että OSS ei ole luonnostaan enemmän tai vähemmän turvallinen kuin omistusoikeudellinen ohjelmisto — turvallisuus riippuu tietystä komponentista, sen yhteisön kehityskäytännöistä ja kuluttavan organisaation soveltamasta hallinnosta.
DoD-ohjelmat saavat yleensä käyttää OSS:ää seuraavilla ehdoilla: lisenssikatselmus sen varmistamiseksi, että lisenssiehdot ovat yhteensopivia ohjelman jakeluvaatimusten kanssa; haavoittuvuusarviointi sisällytettävästä tietystä versiosta; ja jatkuva seuranta uusille haavoittuvuuksille sisällytetyissä komponenteissa. Joitakin ohjelmia koskevat lisärajoitukset luokitustason, käsitellyn tiedon arkaluonteisuuden tai tiettyjen sopimusvaatimusten perusteella.
Liittolaisten puolustusorganisaatiot heijastavat yleensä tätä lähestymistapaa. Iso-Britannian puolustusministeriön teknologiaohjeet sallivat OSS:n käytön aineettomien oikeuksien selvityksen ja turvallisuusarvioinnin ehdoilla. Saksan Bundeswehrin ohjelmat käyttävät avoimen lähdekoodin komponentteja laajasti, erityisesti infrastruktuuritason ohjelmistoissa, BSI:n avoimen lähdekoodin turvallisuusarviointiohjeiden mukaisesti. Liittolaisten välinen yhdenmukaistaminen on riittävän laajaa, jotta kansainväliset ohjelmat eivät tyypillisesti kohtaa OSS-politiikkaristiriitoja kumppaneiden välillä.
Toimitusketjuriskit: typosquatting, haitalliset päivitykset ja hylätyt kirjastot
OSS-toimitusketjun hyökkäyspinta kattaa useita erillisiä riskiluokkia, joista kukin vaatii erilaisia lieventämismenetelmiä.
Typosquatting. Hyökkääjät rekisteröivät pakettinimiä, jotka ovat lähellä suosittuja laillisia paketteja — transitiivisia kirjoitusvirheitä, vaihtoehtoisia kirjoitusasuja tai yleisiä kirjoitusvirheitä. Kehittäjä, joka kirjoittaa paketinimen väärin, asentaa haitallisen koodin tarkoitetun kirjaston sijaan. Typosquatting-hyökkäyksiä on havaittu npmissä, PyPI:ssä ja RubyGemsissa, ja ne ovat kohdistuneet kehittäjätunnuksiin, ympäristömuuttujiin ja käyttöönottosalaisuuksiin. Lieventäminen vaatii pakettinimen vahvistamista asennushetkellä ja riippuvuuksien lukitustiedostoja, jotka kiinnittävät tarkat pakettinimet ja versiot.
Haitalliset päivitykset. Laillisesta, laajalti käytetystä paketista voi tulla haittaohjelmien väline, jos sen ylläpitäjät vaarantuvat, pakotetaan tai korvataan vihamielisillä toimijoilla. XZ Utils -tapaus on kehittynein esimerkki, mutta yksinkertaisempia tapauksia — ylläpitäjätilin vaarantuminen, joka johtaa haitallisen version lataamiseen — tapahtuu säännöllisesti. Lieventäminen vaatii tiettyjen versioiden kiinnittämistä sen sijaan, että hyväksyttäisiin automaattisesti uusimman version päivitykset, pakettien allekirjoitusten vahvistamista saatavilla olevissa tapauksissa ja epänormaalien muutosten seurantaa pakettikäyttäytymisessä versioiden välillä.
Hylätyt kirjastot. Avoimen lähdekoodin projekteja ylläpitävät usein yksittäiset vapaaehtoiset tai pienet ryhmät. Kun ylläpitäjät lopettavat aktiivisen kehityksen, projektia saatetaan edelleen käyttää alajärjestelmien ohjelmistoissa samalla kun se kerää korjaamattomia haavoittuvuuksia. Log4Shell-haavoittuvuus vaikutti projektiin, jolla oli aktiivinen ylläpito; monet todellismaailman haavoittuvuudet vaikuttavat komponentteihin, jotka ovat olleet käytännössä ylläpitämättömiä vuosien ajan. Lieventäminen vaatii riippuvuuksien ylläpitotilan seurantaa ja politiikan käyttöönottoa ylläpitämättömien, turvallisuuskriittisiä funktioita käsittelevien komponenttien korvaamiseen tai haarukkaan.
Lisenssinmääräystenmukaisuus. Avoimen lähdekoodin lisenssit asettavat velvoitteita kuluttajille. Copyleft-lisenssit (GPL, AGPL) voivat vaatia johdetun lähdekoodin julkistamista — luoden oikeudellisia ja turvallisuusriskejä puolustusohjelmille, jotka eivät voi julkistaa lähdekoodia luokituksen tai kilpailullisten huolien vuoksi. Lisenssien yhteensopimattomuus voi myös vaikuttaa jakeluun liittolaisille tai urakoitsijoille. Lisenssikatselmuksen on oltava järjestelmällistä, ei ad hoc -pohjaista.
OSS-hyväksymisprosessi: lisenssikatselmus, haavoittuvuusskannaus ja alkuperä
Tehokas OSS-hallinto puolustusohjelmissa vaatii määritellyn hyväksymisprosessin, jonka jokainen uusi riippuvuus käy läpi ennen koodikantaan lisäämistä. Prosessin tulisi kattaa kolme aluetta.
Lisenssikatselmus määrittää, sopiiko komponentin lisenssi ohjelman aiottuun käyttöön. Tämä vaatii ohjelman jakelumallin ymmärtämistä (sisäinen käyttö, toimitus tietylle asiakkaalle, kaupallinen jakelu), jokaisen ehdokaskomponentin asettamien lisenssivelvoitteiden ymmärtämistä ja sen arvioimista, luovatko nämä velvoitteet ristiriitoja. Ohjelmat, jotka käyttävät yhteensopimattomien lisenssien komponentteja, löytävät ongelman sopimustoimituksen tai laillisen katselmuksen yhteydessä — molemmat ovat kalliita ja aikatauluun vaikuttavia ratkaisuajankohtia.
Haavoittuvuusskannaus arvioi harkittavan komponentin tietyn version tunnettujen haavoittuvuustietokantojen (NVD, OSV.dev, GitHub Advisory Database) suhteen. Arvioinnin tulisi kattaa paitsi itse komponentti myös sen transitiiviset riippuvuudet — koska transitiivisissa riippuvuuksissa olevat haavoittuvuudet vaikuttavat sisällyttävään järjestelmään yhtä paljon kuin suorat. Sisällyttämishetken haavoittuvuusskannaus on välttämätöntä mutta ei riittävää; se on toistettava jatkuvasti uusien haavoittuvuuksien julkistamisen yhteydessä.
Alkuperäarviointi arvioi komponentin kehityksen ja jakelun luotettavuutta. Tähän sisältyy: ylläpitäjien identiteetti ja kokemus; onko projektilla tietoturvailmoitusprosessi; allekirjoitetaanko julkaisut; tarjoavatko projektin kehityskäytännöt (koodin katselmointi, testaus, CI) kohtuullista takuuta tahallisesta laadusta. Komponentti, jolla on vahvat tekniset turvallisuusominaisuudet mutta jonka ovat kehittäneet tuntemattomat osapuolet ilman tietoturvailmoitusprosessia, esittää erilaisen riskiprofiilin kuin komponentti, jolla on vastaavat ominaisuudet ja jonka on kehittänyt tunnettu säätiö läpinäkyvällä hallinnolla.
Kriittinen ero: Haavoittuvuusskannaus tunnistaa tunnetut haavoittuvuudet. Se ei tarjoa suojaa tuntemattomia haavoittuvuuksia tai tahallisia takaovia vastaan. Alkuperäarviointi ja projektin laajempi toimitusketjun turvallisuusasento käsittelevät riskiluokkaa, johon haavoittuvuusskannaus ei ulotu.
SBOM OSS-riippuvuuksien hallintavälineenä
Ohjelmiston materiaalilista (SBOM) on muodollinen, koneluettava inventaari kaikista järjestelmän ohjelmistokomponenteista — mukaan lukien avoimen lähdekoodin kirjastot, kaupalliset hyllytuotteet ja sisäisesti kehitetyt moduulit — niiden versioilla, lisensseillä ja riippuvuussuhteilla. SBOM on yhä enemmän velvoitettu puolustusohjelmistolle: Yhdysvaltain toimeenpanomääräys 14028 (2021) vaatii SBOM:n liittovaltiovirastoille myytävälle ohjelmistolle, ja liittolaismaissa toteutetaan vastaavia vaatimuksia.
OSS-hallinnan osalta SBOM tarjoaa kaksi kykyä, jotka ovat muuten vaikea saavuttaa laajassa mittakaavassa. Ensinnäkin se mahdollistaa automaattisen haavoittuvuuskorrelaation: uuden haavoittuvuuden julkistamisen yhteydessä (esim. tietyn OpenSSL-version CVE julkaistaan) se voidaan automaattisesti korreloida SBOM:in kanssa tunnistamaan kaikki ohjelmat, jotka sisältävät kyseessä olevan version. Ilman SBOM:ia tämä korrelaatio vaatii manuaalista inventaaria — mikä on hidasta, virhealtista ja epätodennäköisesti johdonmukaisesti suoritettua.
Toiseksi SBOM mahdollistaa lisenssinmääräystenmukaisuuden seurannan koko riippuvuuspuun läpi, mukaan lukien transitiiviset riippuvuudet. Lisenssien manuaalinen seuranta sadojen riippuvuuksien ja niiden transitiivisten riippuvuuksien läpi ei ole toteutettavissa; automatisoitu SBOM-työkalutus tekee siitä hallittavaa.
Tehokkaat SBOM-ohjelmat integroivat SBOM-generoinnin CI/CD-putkeen, jotta SBOM on aina ajan tasalla todellisen käyttöönotetun koodin kanssa mieluummin kuin piste-aika-asiakirja, joka ajautuu todellisuudesta komponenttien päivitytyessä. SBOM-formaattistandardit (CycloneDX, SPDX) ovat kypsiä ja työkalujen tuki on laaja. SBOM:n käyttöönotolle ei enää ole teknistä estettä — jäljellä olevat esteet ovat organisatorisia: SBOM:n priorisointi ohjelmavaatimuksena ja insinöörityökapasiteetin allokoiminen työkaluston toteuttamiseen ja ylläpitoon.