Ohjelmistokehityksen toimittajan valitseminen puolustusohjelmaan poikkeaa olennaisesti kaupallisten ohjelmistojen hankinnasta. Vikamekanismit ovat erilaisia, due diligence -vaatimukset ovat korkeammat ja väärän valinnan seuraukset ovat vaikeammin peruutettavissa. Aikataulustaan myöhästyvä kaupallinen ohjelmistoprojekti aiheuttaa liiketoiminnallista haittaa. Käyttöönotossa epäonnistuva puolustusohjelmistoprojekti luo operatiivisia aukkoja, jotka voivat suoraan vaikuttaa tehtävän tuloksiin.

Tässä artikkelissa käsitellään olennaisia arviointikriteerejä — ei yleisluonteista kyvykkyysarviointia, vaan niitä erityisiä merkkejä, jotka erottavat tuotantolaatuista puolustusohjelmistoa toimittamaan kykenevät toimittajat niistä, jotka eivät siihen pysty.

ISO 27001 ja laatusertifioinnit lähtötasona

ISO 27001 (tietoturvallisuuden hallinta) ja ISO 9001 (laadunhallinta) ovat välttämättömiä mutta eivät riittäviä. Toimittaja, jolla ei ole näitä sertifiointeja, tulisi sulkea pois harkinnasta ohjelmissa, joissa käsitellään luokiteltua tai arkaluonteista tietoa — ei siksi, että sertifikaatit itsessään takaisivat laadun, vaan koska muodollisten turvallisuuden ja laadun hallintajärjestelmien puuttuminen on luotettava osoitus siitä, että turvallisuus ja laatu eivät ole organisaation prioriteetteja.

Kohtele ISO 27001:tä lattiana, ei kattona. Pyydä sertifioinnin soveltamisala: kattaako se kehitysympäristön, jossa koodisi kirjoitetaan? Ohjelmaasi työskentelevät kehittäjät? DevOps-infrastruktuurin? Sertifiointi, joka kattaa vain pääkonttorin mutta ei kehitystiimiä, on rajallisesti merkityksellinen. Pyydä soveltuvuuslausunto (Statement of Applicability) — asiakirja, jossa luetellaan, mitkä kontrollit on toteutettu ja mitkä on jätetty pois. Pitkä lista poissulkemisia heikoin perusteluin on varoitusmerkki.

Ohjelmissa, joissa käsitellään NATO-luokiteltua tietoa, tarkista, onko toimittajalla asianomaisen kansallisen viranomaisen myöntämä teollisuusturvallisuusselvitys (Industrial Security Clearance, ISC). ISC-vaatimukset vaihtelevat maittain, mutta tyypillisesti ne edellyttävät toimitilojen turvallisuushyväksyntää, henkilöstön turvallisuusselvitystä ja dokumentoituja turvallisuusmenettelyjä luokitellun aineiston käsittelyyn.

NATO- ja STANAG-kokemus signaalina

Puolustusohjelmistot ovat kapea ala. Toimittaja, jolla on kymmenen vuotta kaupallista yritysohjelmistokokemusta mutta ei lainkaan puolustussektorin työtä, kohtaa jyrkän oppimiskäyrän ensimmäisessä puolustussopimuksessaan — ja tuo oppimiskäyrä rahoitetaan ohjelmasi budjetista. Aiempi NATO- tai STANAG-aiheinen työ on konkreettinen merkki siitä, että toimittaja ymmärtää koalition tiedonvaihdon, luokittelun käsittelyn ja sotilasverkkoympäristöjen erityiset rajoitteet.

Kysy nimenomaisesti: mitä STANAG-standardeja he ovat toteuttaneet? Mihin NATO-ohjelmiin he ovat toimittaneet? Ovatko he osallistuneet NATO-harjoituksiin tai yhteentoimivuustapahtumiin (kuten Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — CWIX)? Näiden kysymysten vastaukset ovat todennettavissa — CWIX-osallistuminen on dokumentoitua, ja NATO-ohjelmakokemus voidaan tarkistaa referensseistä.

Operatiivisten käyttöönottojen näyttöhistoria

Tärkein erottelu puolustusohjelmistoissa on järjestelmien välillä, joita on demonstroitu (kontrolloidussa testiympäristössä arviointiraadille), ja järjestelmien, joita on otettu käyttöön (operatiivisille käyttäjille, todellisessa ympäristössä, tekemään todellista työtä). Toimittaja, jonka portfolio koostuu kokonaan demonstraatioista ja prototyypeistä, ei ole läpäissyt operatiivisen todellisuuden testiä. Toimittaja, jonka järjestelmät ovat toimineet todellisissa operaatioissa, on sen läpäissyt.

Pyydä referenssejä operatiivisista käyttöönotoista — ei ohjelmapäälliköiltä, vaan operaattoreilta tai teknisiltä vastuuhenkilöiltä, jotka todella käyttivät järjestelmää. Kysy luotettavuudesta kentällä: mitä vikoja ilmeni? Miten ne käsiteltiin? Mikä oli tuen vasteaika? Toimittaja, joka on epämääräinen operatiivisen kokemuksen suhteen tai joka viittaa vain demonstraatioihin, on toimittaja, jonka ohjelmistoa ei ole käytetty tositoimissa.

Vuoden 2022 jälkeisessä Euroopassa operatiivisesta käyttöönotosta Ukrainan konfliktin kontekstissa on tullut erityisen vahva signaali. Tuon ympäristön vauhti, intensiteetti ja vastustajan kyvykkyys ovat rasitustestanneet puolustusohjelmistoja tavoilla, joita harjoitukset eivät voi jäljitellä. Järjestelmillä, jotka kehitettiin ja joita parannettiin tuossa kontekstissa, on eri luokan operatiivinen uskottavuus kuin niillä, joilla ei ole.

Tiimin turvallisuusselvityksiin liittyvät näkökohdat

Jos ohjelmaasi liittyy luokiteltua tietoa, kehitystiimillä on oltava asianmukaisen tason turvallisuusselvitys. Tämä ei ole muodollisuus — se rajoittaa suoraan sitä, kuka voi työskennellä ohjelmassa ja miten kehitys voidaan rakentaa. Toimittaja, joka ehdottaa Secret-tason ohjelman miehittämistä turvallisuusselvittämättömillä ulkomaisilla kehittäjillä, ei joko ole lukenut luokitteluvaatimuksia tai ei suhtaudu niihin vakavasti.

Kysy, ketkä kehittäjät ovat turvallisuusselvitettyjä ja millä tasoilla. Tiukan turvallisuusvaatimusten ohjelmissa pyydä yksittäisten turvallisuusselvitysten vahvistukset (yhteenveto, ei täysiä taustaselvitystietoja) ehdotetuille tiimin jäsenille. Jos toimittajan on hankittava turvallisuusselvitykset ohjelmaa varten, kysy aikataulusta ja heidän kokemuksestaan kansallisesta turvallisuusarviointiprosessista. Turvallisuusselvitysprosessit kestävät useimmissa NATO-maissa 6–18 kuukautta; toimittaja, joka ei ole aloittanut tätä prosessia, ei voi miehittää luokiteltua ohjelmaa aikataulussa.

IP-omistus ja lähdekoodin escrow

Puolustusohjelmistohankkeiden on määriteltävä selkeä IP-omistus alusta alkaen. Jos ohjelmisto on räätälöity ohjelmaasi varten, tarvitset omistuksen tai peruuttamattoman lisenssin. Jos se rakennetaan kaupallisen alustan tai kehyksen päälle, sinun on ymmärrettävä lisenssiehdot operatiivista ja luokiteltua käyttöönottoa varten — mukaan lukien se, liittyykö siihen avoimen lähdekoodin komponentteja. Kaupallinen ohjelmistolisenssi, joka kieltää asennuksen luokitelluille verkoille — kuten jotkin tekevät — on yhteensopimaton ohjelmasi kanssa riippumatta toimittajan muista kyvyistä.

Lähdekoodin escrow on vakiokäytäntö tehtäväkriittisille puolustusohjelmistoille: lähdekoodi, build-skriptit ja käyttöönottodokumentaatio talletetaan kolmannen osapuolen escrow-agentille varmistaen, että voit rakentaa ja ylläpitää järjestelmää, jos toimittaja ostetaan, lopettaa toimintansa tai päättää suhteen. Mikä tahansa toimittaja, joka vastustaa lähdekoodin escrowta tehtäväkriittisessä ohjelmassa, on toimittaja, joka ei ole sitoutunut ohjelman pitkän aikavälin menestykseen.

Keskeinen oivallus: Luotettavin puolustusohjelmistotoimittajan laadun ennustaja ei ole heidän kyvykkyysesityksensä — se on heidän referenssitarkistuksensa. Soita referensseille. Esitä vaikeita kysymyksiä toimitusepäonnistumisista, turvallisuuspoikkeamista ja siitä, miten toimittaja reagoi paineen alla. Vastaukset kertovat sinulle enemmän kuin mikään tarjouspyyntövastaus.

Tuen SLA operatiivisissa ympäristöissä

Puolustusohjelmistojen tukivaatimukset poikkeavat kaupallisesta yritystuesta. Toimistoaikana kaatuva ERP-järjestelmä on merkittävä ongelma, joka voidaan ratkaista tunneissa. Operaation aikana kaatuva C2-järjestelmä on eri luokan ongelma, joka vaatii eri luokan vastauksen. Ennen allekirjoittamista määrittele tuen SLA nimenomaisesti: maksimivasteaika (ei kuittausaika — todellinen vaste), maksimiaika tilapäiseen kiertoratkaisuun, maksimiaika täydelliseen ratkaisuun ja eskalaatiopolku operatiivisia hätätilanteita varten.

Operatiivisten järjestelmien osalta harkitse vaatimusta, että toimittaja ylläpitää turvallisuusselvitettyä tukitiimiä, joka on saatavilla 24/7, ja dokumentoituja toimintaohjeita todennäköisimpiä vikaskenaarioita varten. Tämän kyvyn kustannus on todellinen; toimittaja, joka tarjoaa sitä halvalla, ei joko pysty ylläpitämään sitä tai ei ole rehellinen kustannusmallinsa suhteen.

Varoitusmerkit, joita kannattaa tarkkailla

Kyvyttömyys nimetä tiettyjä operatiivisia käyttöönottoja — ei ohjelmia, vaan todellisia kentällä olevia järjestelmiä. Kehitystiimin omistuksen epäselvyys (body-shopping, julkistamaton alihankinta). Vastustus kehitysinfrastruktuurin turvallisuustarkastuksia kohtaan. Kuilu myyntitiimin senioriteetin ja ehdotetun toimitustiimin senioriteetin välillä. Haluttomuus sitoutua kiinteään turvallisuusarkkitehtuuriin ennen sopimuksen allekirjoittamista. Nämä ovat johdonmukaisia merkkejä toimittajasta, joka on parempi voittamaan sopimuksia kuin toimittamaan niitä.