Sist fredag smalt det igjen. Synderen denne gangen var en sårbarhet i Log4j, et av verdens mest brukte loggebiblioteker. Dette er ingen perifer enkeltkomponent. Første gang jeg brukte Log4j var for over 20 år siden. Den løser et grunnleggende behov for strukturert logging, og har derfor blitt tatt i bruk av veldig mange.
Er åpen kildekode problemet?
Tidligere i år ble Stortinget offer for en sårbarhet i det kommersielle produktet Microsoft Exchange. Et annet eksempel er forsyningskjedeangrepet mot SolarWinds, som traff store deler av amerikansk offentlig forvaltning. Alle datasystemer har sårbarheter, uavhengig av om kildekoden er åpen eller lukket. Selskaper som Microsoft og SolarWinds, med sine tusenvis av ansatte, leverer systemer med kritiske feil.
Virkeligheten er at store deler av verdens programvare – inkludert mange kommersielle produkter – bygger på en plattform av åpen kildekode. Økosystemet er så omfattende og allestedsnærværende at det er vanskelig å tenke seg alternativet. Log4j er bare et av enormt mange eksempler i denne sammenhengen.
Problemperspektivet med åpen kildekode og frivillig forvaltning er relevant. Men industrien gjør seg en bjørnetjeneste ved å peke på dette som årsak til Log4Shell. Log4j har trolig spart oss for mange feil i sin levetid, framfor drøssevis av egenproduserte loggekomponenter. Kombinasjonen av åpen kildekode og stor utbredelse har sannsynligvis avslørt og eliminert andre sårbarheter tidlig. Imidlertid finnes det ingen garantier, verken i åpen eller lukket kildekode.
En realitetsorientering
Rotproblemet er at vi belønner kortsiktige gevinster framfor å investere i kvalitet og vedlikehold i hele livssyklusen til systemene våre. Dette er et gjennomgående problem, helt parallelt med etterslepet vi kjenner fra eksempelvis infrastruktur og bygg. Åpen kildekode er en integrert del av industrien, og har bidratt mye til kvalitetsøkning og digitalisering. Men all kode kommer med en vedlikeholdskostnad.
Reaktiv hendelseshåndtering er nødvendig beredskap. Log4Shell er garantert ikke siste gang dette skjer. Våre systemer blir stadig mer komplekse og virksomhetskritiske. Kontinuerlig leveranse, å sørge for at software-produkter alltid kan rulles ut til produksjon raskt og trygt, anbefales på det sterkeste for å redusere risiko og reagere raskt når hendelser inntreffer. Log4j-utviklerne bør dessuten få mye skryt for måten de har håndtert denne hendelsen.
Datamaskiner tenker kjappere sammen: – Beregning som før tok ett år, kan vi nå gjøre på ti dager
Helhetsansvar for egne systemer
Beslutningen om å benytte et tredjepartsbibliotek kommer med et ansvar. Hvis man har en supportavtale, kan man forvente at leverandøren tar tak i problemer innenfor de avtalte rammene. Det er imidlertid ikke en garanti mot sårbarheter eller at leverandøren er i stand til å fikse dem fort nok.
Med åpen kildekode, uten supportavtale, tar man i utgangspunktet dette ansvaret på egne skuldre. Log4Shell viser imidlertid at utviklermiljøet gjerne retter feil like raskt som en leverandør. I alle tilfeller må man selv sørge for oppgradere komponenten i egne systemer. Det finnes eksempler på supportmuligheter for åpen kildekode, men det er ikke spesielt utbredt for komponenter som Log4j. En bevisstgjøring av ansvaret det medfører å ta i bruk tredjepartsbiblioteker bør være en åpenbar læring av denne hendelsen:
- Bruk av tredjepartskomponenter er en kost/nytte-øvelse. Gjør en reell vurdering.
- Foretrekk komponenter som har få avhengigheter. Du har ansvaret for dem også.
- Vurder community, modenhet, aktivitet og kvalitet.
- Hold avhengighetene oppdatert til enhver tid.
- Sørg for innebygd avhengighetssjekk i verdikjeden din med hensyn til utdaterte versjoner og eventuelle sårbarheter, som for eksempel verktøyene Dependabot og Snyk.
Hvordan kan vi bidra?
Virksomheter som benytter åpen kildekode, burde åpenbart bidra tilbake i mye større grad. De enkleste mulighetene er donasjoner til utviklerne og supportavtaler der de finnes. Enda mer verdifullt ville det være å engasjere seg i utviklingen. Hva om eksempelvis Telenor og NAV satte av 2 prosent av all utviklingstid til å forvalte noen av åpen kildekodekomponentene de benytter?
En annen modell som har vist seg effektiv er bug bounty programmer, der man kan rapportere om sårbarheter og feil. Kanskje kan virksomhetene som benytter åpen kildekode-komponenter bidra til slike programmer, og på den måten betale for bruk?
Diskusjonen om bruk, forvaltning og kompensasjon for åpen kildekode er betimelig. La oss løfte blikket, og se på hvordan vi kan forbedre kvalitet og investere i forvaltning av produktene våre fra vugge til grav. Jeg har ingen illusjoner om store omveltninger på kort sikt, men Log4Shell kan kanskje være startskuddet for en dreining i riktig retning?
Sikkerhetsselskap: Dette er de viktigste KI-truslene
