IBM og Red Hat setter 5 milliarder dollar på sikker open source

IBM og Red Hat lover 5 milliarder dollar til Project Lightwell, en ny satsing som skal sikre open source-komponenter med en kombinasjon av AI, et kommersielt clearinghouse og mer enn 20.000 ingeniører.

Selskapene beskriver prosjektet som en modell for hvordan virksomheter skal bruke open source fra upstream-utvikling til produksjon. Kjernen er et sikkerhetslag som skal identifisere sårbarheter, validere rettelser og levere produksjonsklare patcher inn i kundenes egne programvarekjeder.

Det er ikke en liten produktnyhet. Det er et forsøk på å gjøre open source-sikkerhet til en betalt kontrollflate.

IBM peker på at mer enn 90 prosent av Fortune 500-selskapene er avhengige av open source. Samtidig blir AI brukt til å finne svakheter raskere enn vanlige sikkerhetsteam klarer å håndtere dem. I meldingen viser IBM til at Anthropics Mythos Preview-modell fant nær 3.900 sårbarheter med høy eller kritisk alvorlighetsgrad i open source-programvare.

Den kombinasjonen endrer økonomien i forsyningskjeden. Det holder ikke lenger å vite hvilke pakker som ligger i en applikasjon. Virksomheter må vite hvem som validerer rettelser, hvor raskt de kommer, hvilke versjoner som faktisk er i drift, og om endringen kan dokumenteres når revisor, kunde eller regulator spør.

Fra dugnad til kritisk infrastruktur

Open source har lenge vært behandlet som gratis råvare i enterprise-IT. Den tiden er i praksis over. Pakker, containere, rammeverk og språkmoduler er blitt en del av den kritiske infrastrukturen i banker, industri, helse, offentlig sektor og AI-plattformer.

Project Lightwell er et tydelig signal om at de store leverandørene ser et nytt marked mellom community-kode og intern sikkerhetsdrift. IBM og Red Hat vil tilby et mellomledd som både kan koordinere sårbarhetsrapportering, validere patcher og bidra til ansvarlig upstream-disclosure.

Det er attraktivt for store virksomheter. Mange har SBOM, Dependabot-varsler og container-scanning. Færre har kapasitet til å vurdere om en rettelse er trygg nok for produksjon, om den bryter interne avhengigheter, eller om en kritisk svakhet bør håndteres internt før den blir offentlig kjent.

IBM sier at tidlige brukere omfatter Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa og Wells Fargo. Listen viser hvor problemet er mest akutt: finans, betaling og regulerte virksomheter med store gamle systemer, strenge kontrollkrav og høy eksponering mot tredjepartsprogramvare.

For CIO og CISO i Norge er spørsmålet ikke om man bruker open source. Svaret er ja. Spørsmålet er hvor mye av sikkerhetsarbeidet som er synlig nok til å styres.

AI gjør begge sider raskere

IBM vinkler Lightwell som forsvar. Det er riktig, men bare halve bildet.

AI gjør også angrepssiden raskere. Modeller kan lese kode, identifisere mønstre, foreslå exploits og prioritere svakheter som gir høyest effekt. Når defensive team får bedre verktøy, får angripere det samme. Forskjellen ligger i kvaliteten på prosessen rundt funn, prioritering og utrulling.

Derfor er den viktigste delen av Lightwell ikke selve AI-en. Det er løftet om validerte patcher, lifecycle management og en kommersiell ansvarskjede. Virksomheter kjøper ikke bare sårbarhetsfunn. De kjøper en måte å gjøre funnene håndterbare på.

Det er også her risikoen ligger. Et slikt clearinghouse kan redusere kaos, men det kan også bli enda et kritisk leverandørledd. Kunder må forstå hvilke komponenter som dekkes, hvilke SLA-er som gjelder, hvordan rettelser testes, hvordan sensitive sårbarheter deles, og hvordan IBM og Red Hat håndterer konflikter mellom kundebehov og upstream-miljøer.

Dette er særlig viktig for virksomheter som bygger egne AI-løsninger. Moderne AI-stacker er fulle av open source: Python-biblioteker, vektorindekser, orkestrering, eval-verktøy, inference-servere, agentrammeverk og container-runtime. En svakhet i et lite bibliotek kan få større effekt når agenten har tilgang til interne systemer, data og verktøykall.

Hva norske ledere bør gjøre

Første tiltak er å koble open source-risiko til reell drift, ikke bare til utviklerverktøy. Det betyr oversikt over hvilke komponenter som finnes i produksjon, hvilke som er eksponert mot internett, hvilke som ligger i AI- og dataflyter, og hvilke som støtter forretningskritiske prosesser.

Andre tiltak er å skjerpe innkjøpsspørsmålene. Leverandører som selger AI-plattformer, SaaS og managed services bør kunne forklare hvordan de håndterer sårbarheter i open source-avhengigheter. De bør også kunne dokumentere patch-tid, testregime, backporting og ansvar ved kritiske null-dagersfeil.

Tredje tiltak er å ikke la et kommersielt sikkerhetslag bli en sovepute. SBOM, tilgangsstyring, secrets-hygiene, segmentering og beredskapsplaner må fortsatt ligge internt. DORA, NIS2 og norske tilsyn vil ikke godta at ansvaret er outsourcet fordi en leverandør har et fint navn på programmet.

Lightwell kan bli en nyttig modell hvis den gjør open source-sikkerhet mer målbar og revisjonsklar. Den kan også bli en dyr forsikring uten effekt hvis kundene ikke vet hva de kjøper.

Det avgjørende er om virksomheter klarer å gå fra passiv avhengighet til aktiv styring. Open source er ikke lenger bakgrunnsstøy i IT-budsjettet. Det er en del av risikobildet styret bør forstå.

Kilder og medier

Kilde: IBM, pressemelding om Project Lightwell og IBM/Red Hat-satsingen på open source-sikkerhet, publisert 28. mai 2026: https://newsroom.ibm.com/2026-05-28-ibm-and-red-hat-commit-5-billion-to-redefine-the-future-of-open-source-in-the-ai-era

Kildekreditering: IBM.

Thumbnail: OpenAI Image 2 / hogby.ai