Artikkelen er basert på Bjørn Hamres Lightning Talk på JavaZone 2019.
Følgende pressemelding ble sendt ut av det amerikanske selskapet Equifax i september 2017:
Dette er pressemeldingen du ikke har lyst til å sende ut til media, kunder, eiere og investorer. Historien til Equifax startet egentlig 7. mars da en sårbarhet i rammeverket Apache Struts ble offentliggjort (sammen med en ny, “tettet” versjon. Equifax ble faktisk kontaktet av Homeland Security men sikkerhetsavdelingen i Equifax klarte ikke å identifisere systemene som var påvirket av denne sårbarheten.
Systemene til Equifax kjørte på gammel versjon av Struts helt fram til 29. juli da “mistenkelig nettverkstrafikk” ble oppdaget. Da var det for sent. Høsten 2019 inngikk Equifax forlik hvor de skal sette av minst $575 (og opp til $700) millioner US dollar.
Datasikkerhet har fått mer og mer fokus i bedriftene de seneste årene - heldigvis. Men det er slik at å være sikkerhetsekspert er en helt egen spesialisering, så det er ikke lett for den «jevne» utvikler å være skikkelig god på alle aspekter av sikkerhet. Men noe kan vi alle gjøre!
En studie av Jeff Williams og Arshan Dabirsiaghi (Unfortunate Reality of Insecure Libraries) påstår at 80% av koden i applikasjonene kommer fra biblioteker og rammeverk vi bruker. Dette er sannsynligvis et for lavt estimat. Enda viktigere er at de fleste bruker bibliotek og rammeverk til nettopp sikkerhet, kommunikasjon og API-er som er fronten ut mot Internett og kundene. Å sikre seg mot sårbarheter i disse bibliotekene er derfor ekstra viktig. OWASP (Open Web Application Security Project) er kjent for sin topp 10 liste over sikkerhetsrisikoer i webapplikasjoner. På den listen har de lagt til “A9: Using Components with Known Vulnerabilities”, noe som understreker alvoret i situasjonen.
Rapporten sier noe om antall sårbarheter i hvert bibliotek og alvorlighetsgraden. Ved å klikke på en av sårbarhetene får en opp mer detaljer og lenke til den offisielle oppføringen i National Vulnerability Database (NVD).
Når du begynner å se på rapporten kan det være lurt å først luke ut falske positiver. Hvis det er en «ekte» positiv er det ikke alltid lett å finne ut om vår kode blir påvirket av sårbarheten eller ikke. På dette tidspunktet kan det være greit å diskutere med en kollega, eller hvis dere er usikker; oppgrader biblioteket evt. erstatt det med et annet.
Denne pluginen er gratis å bruke, lett å legge inn i prosjektfilene og kan også integreres med de fleste bygge- og integrasjonsserverne. Vurder å feile bygget dersom det finnes en sårbarhet eller definer en egen byggejobb som kjører hver natt uavhengig av om kodebasen har vært endret eller ikke. Husk: Nye sårbarheter offentliggjøres hver dag. Dersom den ikke fant noen kjente sårbarheter forrige uke, kan det ha kommet til noen nye denne uken. Pluginen sjekker også bare mot offentlig kjente sårbarheter og erstatter derfor ikke andre sikkerhetstiltak.
Å bruke OWASP sin dependency check plugin er sannsynligvis det billigste og enkleste sikkerhetstiltaket du kan gjøre i ditt prosjekt!