Sikkerhetsfeilen i log4j «setter Internett i brann». Feilen retter oppmerksomheten mot en sentral problemstilling i moderne IT-porteføljer: Hvordan skal vi gjøre bruken av open source mer kontrollert?
Først er det viktig å merke seg at feilen i log4j like gjerne kunne inntruffet i et kommersielt produkt. Om det hadde skjedd der ville feilen lett kunne vært ukjent i lengre tid, med både de fordelene og risikoene det medfører. Feilen i seg selv lå i en feature som jeg må innrømme var pussig å inkludere i et loggebibliotek (og jeg ville aldri inkludert det i mitt eget lille bibliotek logevents.org)
Men det er et tankekors at et produkt som vedlikeholdes av frivillige på dugnadsbasis har så stor verdi at det brukes i et omfattende sett med produkter. I en ideell verden kunne vi sett for oss at viktige open source-produkter mottok inntekter basert på betaling fra organisasjoner som bruker produktet.
Fordeler ved å betale
I prinsippet er det mulig. Allerede for 15 år siden jobbet jeg i et prosjekt der vi erstattet applikasjonsserveren Websphere med open source-alternativet Jetty. Vi valgte da å kjøpe en supportavtale med utviklerne av Jetty.
Ikke at det egentlig hjelper så mye, men da hadde vi også i prinsippet noen å peke på om det ble avdekket en sårbarhet.
I tillegg til at vi da er med å sikre produktet vi bruker har en fremtid, så gjenspeiler det også at organisasjonen har et strukturert forhold til programvaren vi tar inn. Jeg vil oppfordre organisasjoner til å vurdere å kjøpe support på kritisk open source programvare de benytter, slik som Linux, PostgreSQL, Jetty, Tomcat, Elastic search og lignende.
Spesielt produkt
Du betaler for open source som din organisasjon er avhengig av. Om du ikke vil betale med supportavtaler, så betaler du med risikoen for sikkerhetsfeil som kan ramme deg
Log4j er et spesielt produkt fordi det ofte ikke benyttes direkte. Mange benytter log4j via det populære og meget omfattende Spring-prosjektet (da som et andrevalg etter et alternativt loggebibliotek). Mange vet derfor ikke at de er sårbare. Det er i dag vanlig for utviklingsprosjekter å ha mange open source-avhengigheter uten at man har kontroll på «avhengighetstreet» og sårbarhetene som kan ligge her.
I tillegg er det mange produkter man tar inn som hyllevare som inkluderer log4j, enten direkte eller via en annen avhengighet (som for eksempel Spring, nevnt over). Produkter så varierte som VMWare og Minecraft har denne problemstillingen, der mange brukere av disse produktene nå må oppgradere.
Ideelt sett burde for eksempel VMWare avsatt noe av de inntektene de får fra sine brukere til forvaltning av open source-bibliotek som de inkluderer.
For min egen del kommer jeg til å kartlegge open source-produkter som er kritiske for oss og spille inn innkjøpsforslag til supportavtaler på disse. Jeg kommer også til gå gjennom avhengighetene i mine prosjekter og fjerne de som jeg bare benytter marginalt. Og jeg forblir skeptisk til programvare som inkluderer mange avhengigheter.
Du betaler for open source som din organisasjon er avhengig av. Om du ikke vil betale med supportavtaler, så betaler du med risikoen for sikkerhetsfeil som kan ramme deg
