CI/CD-haavoittuvuusskannaus – näin aloitat DevSecOps-matkasi

DevSecOps on luonteva kehitysaskel

DevOps (Development ja Operations) on joukko käytäntöjä ja toimintamalleja, jotka automatisoivat ja integroivat kehityksen ja operoinnin välisiä prosesseja. Se on CI/CD:n tuomien toimintatapojen luonteva kehitysaskel.

DevSecOps (Development, Security ja Operations) on kulttuuriin, automaatioon ja alustasuunnitteluun liittyvä lähestymistapa, jossa tietoturva integroidaan yhteiseksi vastuuksi koko kehityssyklin ajan. Ei olekaan yllättävää, että se on seuraava askel ohjelmistokehityksen kehityksessä.

DevSecOps kattaa paljon

DevSecOps on paljon muutakin kuin haavoittuvuuksien skannausta. Tutustu alla olevaan SANS Instituten tuottamaan kuvaan.

Lähde: https://twitter.com/sanscloudsec/status/968590339371126784

Kuten näet, tietoturvallinen DevOps-työkaluketju kattaa kaiken staattisesta sovellustietoturvatestauksesta (SAST) dynaamiseen sovellustietoturvatestaukseen (DAST), tietoturva-auditointeihin ja monitorointiin sekä paljon, paljon muuhun. DevSecOps voi tuntua hieman haastavalta, sillä huomioitavaa ja katettavaa on paljon.

Automaation näkökulmasta hyvä lähtökohta on kuitenkin etsiä haavoittuvuuksia CI/CD-putkistasi.

Haavoittuvuuksien, virheiden ja heikkouksien etsiminen koodista on olennainen osa tehokasta ohjelmistotietoturvaa. Se on luonteva lähtökohta ja alue, johon voit vaikuttaa eniten jatkuvasti muuttuvassa uhkaympäristössä.

CI/CD-putket ovat kehitysprosessin varhaisessa vaiheessa. Ne ovat tärkeä portti Continuous Deliveryn varmistamiseen, eikä niiden käyttöönotto yleensä vaadi suuria investointeja. Ne voidaan toteuttaa useilla eri CI-palvelimilla. Jos saat ne toimimaan onnistuneesti putkessa, pystyt todennäköisesti integroimaan ne myöhemmin myös build-järjestelmääsi. Tämä tarkoittaa käytännössä siirtymistä mahdollisimman pitkälle vasemmalle.

Putket sopivat myös hyvin erilaisten työkalujen arviointiin ilman, että nykyiset kehitysprosessit tai kehittäjät häiriintyvät – ainakin siihen asti, kunnes olet löytänyt sopivat työkalut ja teknologiat.

Tämän blogin loppuosa käsittelee pääasiassa haavoittuvuuksien havaitsemisen automatisointia CI/CD-putkissa.

Pidä tavoite kirkkaana mielessä

Teknologiapinot vaihtelevat huomattavasti organisaatioittain. Kaikkia mahdollisia pinoja olisi mahdotonta käsitellä. Jos lähestymistapasi ohjelmistokehitykseen on kuitenkin edes jossain määrin moderni, haavoittuvuuksien skannauksen toteuttaminen putkissasi seuraaville alueille on todennäköisesti järkevää.

Lähdekoodin haavoittuvuuksien analysointi

Mistä muualta aloittaisit kuin turvallisista koodauskäytännöistä? Pull requestit, koodikatselmoinnit ja koodausohjeistukset auttavat luonnollisesti merkittävästi turvallisten koodauskäytäntöjen toteuttamisessa. Kehittäjät ovat kuitenkin ihmisiä, ja virheitä sattuu.

Lisäksi uhkaympäristö muuttuu jatkuvasti, eikä aiemmin turvalliseksi katsottu koodauskäytäntö välttämättä pysy sellaisena. Koodianalyysin automatisointi työkalulla tai teknologialla, joka pysyy ajan tasalla jatkuvasti muuttuvasta uhkaympäristöstä, on kestävämpi ja yhtenäisempi lähestymistapa.

Kolmannen osapuolen riippuvuuksien haavoittuvuuksien analysointi

Sovellusten riippuvuusgraafit ovat syvempiä kuin koskaan, ja avoimen lähdekoodin ohjelmistojen käyttö on kasvanut räjähdysmäisesti verrattuna jopa viiden vuoden takaiseen.

Luin vanhan, vuodelta 2014 olevan Contrast Securityn artikkelin, jonka mukaan komponenttilatausten määrä kaksinkertaistui kahdessa vuodessa 6 miljardista 13 miljardiin. Kasvu on huimaa, mutta täysin uskottavaa. Sanoisin jopa, että kolmannen osapuolen avoimen lähdekoodin riippuvuudet ovat nykyään ohjelmistoissa kaikkialla.

Viime aikoina on ollut useita laajasti uutisoituja ohjelmistojen toimitusketjuihin kohdistuneita hyökkäyksiä. On käynyt selväksi, että kolmannen osapuolen riippuvuuksiin liittyy merkittäviä haavoittuvuusriskejä, joten niiden tulisi olla osa kaikkea tekemääsi haavoittuvuuksien havaitsemista.

Kontti-imagien haavoittuvuuksien analysointi

Oletko koskaan kuullut ilmaisua ”software is eating the world”? Joskus tuntuu, että kontit syövät ohjelmistokehityksen. Ja hyvästä syystä.

Mahdollisuus käyttää standardoitua paketointimuotoa ja samalla tarjota muuttumaton ympäristö ohjelmistomme suorittamiseen on monella tavalla merkittävä edistysaskel. Mutta kuten kaikissa edistysaskelissa, myös tässä on huomioitavaa:

• Haavoittuvia kirjastoja voidaan lisätä imageen build-vaiheessa.

• Imagejen rakentaminen kerroksittain voi peittää haavoittuvuuksia, jolloin niitä ei ole helppo havaita.

• Imagen pohjalla on käyttöjärjestelmää edustava base image. Kuten kaikissa käyttöjärjestelmissä, myös siinä voi olla haavoittuvuuksia.

• Kontissa käynnissä olevalla prosessilla voi olla tarpeettoman laajat oikeudet.

Tämä ei tarkoita, että kontteja ei kannattaisi käyttää, vaan että imaget kannattaa skannata. Näin voit tunnistaa haavoittuvuudet ohjelmistostasi ja ympäristöstä, jossa se toimii, kun toimitat kokonaisuuden yhtenä pakettina.

Infrastructure as Code (IaC) -määritysten haavoittuvuuksien analysointi

DevOps-käytäntöjen ja -kulttuurin yleistyessä infrastruktuurin määrittely koodina on yhä tavallisempaa.

Mutta koodi on koodia riippumatta siitä, käytetäänkö sitä infrastruktuuriin vai ei. Mahdollisuus ottaa infrastruktuuriresursseja nopeasti käyttöön ja skaalata niitä tarkoittaa myös sitä, että virheelliset konfiguraatiot voivat aiheuttaa tietoturvaongelmia nopeammin ja laajemmassa mittakaavassa.

Siksi IaC:n virheellisten konfiguraatioiden ja tietoturvaongelmien havaitseminen on olennaista, ja sen tulisi olla vakio-osa haavoittuvuuksien skannausprosessia.

Kokemuksia käytännöstä

Haavoittuvuuksien skannauksen toteuttamisesta putkissa kertyneiden kokemusteni perusteella suosittelen ottamaan huomioon seuraavat tekijät, kun aloitat DevSecOpsin käytön CI/CD-putkissa.

Huomioi yhteensopivuus ja helppokäyttöisyys

Etsi teknologia tai työkalu, joka kattaa mahdollisimman paljon tarpeita. Vaikka nykyinen työkaluketjusi koostuisi vain node.js:stä ja .Netistä, se ei tarkoita, että se pysyisi aina yhtä rajallisena tai muuttumattomana. Esimerkiksi `npm audit` tai `yarn audit` voi auttaa pääsemään nopeasti alkuun, mutta ne eivät todennäköisesti kestä ajan mittaan.

Kannattaa toki myös arvioida, kuinka hyvin teknologia tai työkalu integroituu CI/CD-toimintatapaasi. Siinähän on loppujen lopuksi pääasia. Pohdi esimerkiksi seuraavia kysymyksiä:

• Palauttaako se järkevät exit-koodit, jotka sopivat hyvin automaatioon?

• Kuinka hyvin se integroituu nykyisiin lukuisiin CI-palvelimiin?

• Tarvitsenko kiertoratkaisuja tai wrapper-ohjelmia, jotta se toimisi hyvin pipeline-virrassani?

Ymmärrät idean. Tärkeintä on mahdollisimman laaja tuki kielille ja CI-palvelimille sekä helppokäyttöisyys.

Konfiguroitavuus ratkaisee

Kokemukseni mukaan kohtaat hyvin todennäköisesti vääriä positiivisia löydöksiä. Kaikki tietoturvaongelmat eivät ole yhtä kriittisiä kaikille koodikannoille, ja löydöksissä on väistämättä myös epäolennaisia tapauksia.

Siksi on olennaista voida määritellä konfiguraatiolla, mikä koskee tiettyä koodikantaa, mieluiten tavalla, jota voidaan seurata ja auditoida koodikannan rinnalla. Esimerkiksi konfiguraatiotiedoston tai koodikannassa olevien annotaatioiden avulla.

Ongelmien määrä voi olla huomattava etenkin legacy-sovelluksissa, joten niiden lieventämiseen tarvitaan usein asteittaista lähestymistapaa. Tällöin on voitava asettaa kynnysarvot, joiden ylittyessä pipeline keskeytyy.

• Sinun pitäisi voida määrittää vakavuustaso, jolla pipeline epäonnistuu, jos löytyy kriittisiä havaintoja.

• Sinun pitäisi pystyä määrittämään vakavuustasoon perustuva kynnysarvo, jonka ylittyessä pipeline epäonnistuu. Esimerkiksi minulla on nyt kolme (3) korkean vakavuustason löydöstä. Pipeline epäonnistuu, jos korkean vakavuustason löydösten määrä ylittää tämän kolmen (3) kynnysarvon.

Raportointi on ratkaisevan tärkeää

Koska useimmat kehittäjät ja DevOps-ammattilaiset eivät ole tietoturva-asiantuntijoita, valitun teknologian tai työkalun tulosten ja raportoinnin tulisi auttaa heitä ymmärtämään löydökset, niiden syntytapa sekä se, mitä niille käytännössä pitää tehdä. Pidä mielessä ainakin seuraavat asiat:

• Raportin tulisi antaa kattavat ohjeet siitä, miten ja missä löydökset ovat syntyneet. Esimerkiksi ilmoittaa tarkka tiedosto ja rivi sekä koko riippuvuusketju, jos löydös on syntynyt tietyn moduulin ja version käytöstä.

• Raportin tulisi sisältää selkeä, ytimekäs ja ymmärrettävä kuvaus löydöksestä.

• Raportin tulisi tarjota erinomaiset ohjeet löydösten korjaamiseen. Esimerkiksi päivitä riippuvuuden Y versio 3 versioon 4.

• Raportin tulisi sisältää vain olennaiset löydökset. Sen ei tulisi raportoida löydöksiä, jotka olet määrittänyt koodikannan kannalta merkityksettömiksi.

• Teknologian tai työkalun tulisi luoda raportti. Sinun ei pitäisi joutua käyttämään raportin luomiseen muuta työkalua, sillä se ei todennäköisesti vastaa tarpeitasi.

OWASP on ystäväsi

Open Web Application Security Project (OWASP) on voittoa tavoittelematon säätiö, joka pyrkii parantamaan ohjelmistojen tietoturvaa. OWASPin tavoitteena on: "Auttaa organisaatioita suunnittelemaan, kehittämään, hankkimaan, käyttämään ja ylläpitämään luotettavia sovelluksia."

OWASP tarjoaa runsaasti arvokasta tietoa sekä projekteja ja työkaluja, jotka auttavat saavuttamaan tietoturvatavoitteesi. Jos käytössäsi on vain avoimen lähdekoodin ohjelmistoja, tutustu asiaankuuluviin projekteihin.

Jos kehität verkkosovelluksia, sinun on ehdottomasti tunnettava OWASP Top Ten. Se on käytännössä kooste verkkosovellusten kymmenestä yleisimmästä ja kriittisimmästä tietoturvariskistä. Uskallan jopa sanoa, että käyttämäsi teknologian tai työkalun tulisi tukea OWASP Top Teniä.

Haavoittuvuudet on korjattava

Haavoittuvuuksien tunnistaminen pipelinessasi on hyvä tapa aloittaa DevSecOps-matkasi. Mutta työ ei lopu siihen. Niille pitää tehdä jotain.

Määritä haavoittuvuuksien käsittelystrategia:

• Määritä korjausten prioriteetit. Esimerkiksi tyypin X kriittiset löydökset on korjattava välittömästi.

• Määritä prosessi, jolla haavoittuvuus todetaan merkityksettömäksi.

• Ota haavoittuvuudet huomioon koodikatselmointien kriteereinä ja varmista, että ne ovat näkyvissä katselmointiprosessin aikana.

• Ja monia muita asioita tapauksestasi riippuen…

Yhteenveto

Pelkkien avoimen lähdekoodin työkalujen ja teknologioiden käyttö johtaa todennäköisesti hajanaiseen kokonaisuuteen. Vaikka nämä työkalut ja teknologiat tuovat selvästi arvoa, jokaisella on omat erityispiirteensä, eikä aina ole helppoa nähdä, mitä ne kattavat ja kuinka hyvin ne siinä onnistuvat. Niiden tulostusmuodotkin vaihtelevat, mikä vaikeuttaa kokonaiskuvan saamista tietoturvan tilasta.

Haavoittuvuusskannauksen käyttöönotto pipelineissasi on hyvä lähtökohta, mutta se ei yksin riitä. Sen avulla tulisi estää uusien haavoittuvuuksien päätyminen koodiisi. Haavoittuvuuksia löytyy kuitenkin vain pipelinejen suorituksen aikana. Pipelinejen suoritusten välillä voidaan löytää uusia haavoittuvuuksia, jolloin ohjelmistosi voi olla jonkin aikaa haavoittuva. Tämä korostuu erityisesti vakaissa koodikannoissa, jotka muuttuvat harvoin.

Suosittelen tarkastelemaan maksullisia teknologioita ja alustoja sen sijaan, että valitsisit pelkästään avoimeen lähdekoodiin perustuvan lähestymistavan. Pidän Snykistä, koska se integroituu hyvin CI/CD-lähestymistapaan ja moniin CI-palvelimiin ja kattaa siten tärkeimmät painopistealueeni. Se tarjoaa myös erinomaiset raportit ja hyvät ohjeet sekä mahdollistaa koodikantasi monitoroinnin, jotta voit löytää uusia haavoittuvuuksia pipelinejen suoritusten välillä. Pidän myös siitä, miten Snyk kokoaa löydökset yhteen dashboardiin, mikä auttaa ymmärtämään tietoturvasi kokonaistilannetta paremmin.