Et sikkerhetsvarsel beskytter ikke bedriften i seg selv. Noen må finne ut om feilen er reell, hvilken programvare som er berørt, og hva som bør gjøres. Hvis nyttige meldinger kommer raskere enn fagfolkene rekker å vurdere dem, kan viktige saker bli liggende sammen med duplikater og feilaktige funn.
KI kan hjelpe oss å oppdage svakheter som ellers ville gått under radaren. Samtidig er det blitt enklere å lage lange rapporter som tar tid å kontrollere. Norske bedrifter bør forberede seg på begge deler: Sett av tid til faglig gjennomgang, og spør viktige programvareleverandører hvordan de håndterer flere meldinger.
Dette er et annet spørsmål enn hvor raskt bedriften installerer en tilgjengelig oppdatering. Her handler det om det som skjer før en rettelse er klar: Hvordan kommer leverandøren frem til om en rapportert feil må rettes?
Hva forteller utviklerne av åpen kildekode?
I en undersøkelse fra oktober 2026 spurte Linux Foundation Research 234 utviklere og vedlikeholdere av åpen kildekode om generativ KI. Deltakerne ble rekruttert gjennom stiftelsen og samarbeidspartnerne fra april til juni. Deltakerne ble ikke tilfeldig valgt blant alle utviklere eller norske bedrifter. Resultatene bygger på deltakernes egne vurderinger.
I spørsmålet om mengden bidrag svarte 59 prosent av de 111 vedlikeholderne at de hadde sett en økning knyttet til generativ KI. Dette er vurderinger av foreslåtte kodeendringer, ikke en opptelling av sikkerhetsfeil. Undersøkelsen viser også at noen vedlikeholdere bruker KI til å kontrollere kode og finne feil, mens andre ikke gjør det. Flere forslag og raskere utkast kan forekomme samtidig. Studien måler ikke hvor lang tid din leverandør bruker på å rette feil.
OpenSSFs omtale 30. oktober fremhever vedlikeholdernes anslag over bidrag med lav kvalitet. Dette tallet må leses med varsomhet. Det bygger på anslag, ikke en uavhengig gjennomgang av hvert forslag, og rapportens tekst og figur beskriver kategorien forskjellig. Andelen kan ikke overføres til all kode eller til en bestemt norsk bedrift.
Flere rapporter betyr ikke at kvaliteten er dårligere
Erfaringene fra curl, et prosjekt med åpen kildekode som brukes til dataoverføring, viser hvorfor vi må skille mellom kvalitet og mengde. I april 2026 fortalte prosjektleder Daniel Stenberg at prosjektet mottok flere sikkerhetsrapporter og at kvaliteten hadde blitt bedre. I en oppdatering 22. oktober skrev han at oppdiktede rapporter av lav kvalitet nesten hadde forsvunnet fra sikkerhetsarbeidet i curl. Utfordringen var fortsatt mengden nyttige og ofte lange rapporter.
Dette er prosjektlederens observasjoner om curl, ikke en måling av alle prosjekter. De gjelder sikkerhetsrapporter. Linux Foundation-undersøkelsen spør også om foreslåtte kodeendringer. Tallene kan ikke slås sammen til én andel. Lærdommen er at det kan være feil å avvise alt som er laget med KI. Samtidig gir det falsk trygghet å godta en KI-skrevet konklusjon uten å undersøke den.
Følg én rapport frem til en beslutning
Tenk deg en norsk bedrift med en kundeportal. Utviklingsleverandøren får et automatisk varsel om en mulig svakhet i et programbibliotek portalen bruker. Eksemplet er oppdiktet. Varslet kaller feilen kritisk, men biblioteket brukes kanskje ikke på måten varselet beskriver. En annen melding kan samtidig gjelde det samme problemet.
Leverandøren trenger tid og kompetanse til å sjekke versjonen, om funksjonen faktisk er tilgjengelig for angripere, og om meldingene beskriver samme feil. Hvis problemet er reelt, må leverandøren finne et egnet tiltak og forklare kunden hva som er kjent. Hvis funnet ikke er relevant, bør leverandøren kunne forklare hvorfor og hva vurderingen bygger på. En overbevisende KI-oppsummering er et utgangspunkt, ikke et bevis på at portalen er trygg.
Avtal en kort oversikt for viktige funn:
- Hva er berørt? Oppgi produkt, komponent og versjoner, og hvem som har ansvar for vurderingen.
- Hva vet vi? Skill mellom en feil som er gjenskapt, og en påstand som ennå ikke er kontrollert. Vis til grunnlaget.
- Hva skjer videre? Avklar hvem som undersøker saken, når kunden får en oppdatering, og hvilke beslutninger som må løftes videre.
- Hva beskytter tjenesten mens vi venter? La fagfolk vurdere om et midlertidig tiltak hjelper, og om det også har en kostnad for driften.
- Når kan saken avsluttes? Dokumenter om meldingen var et duplikat, ikke gjaldt dere, er håndtert midlertidig eller er rettet. Vis hva som bekrefter konklusjonen.
Dette er et forslag til arbeidsform, ikke et krav fra forskerne. Sensitive tekniske detaljer hører ikke hjemme i vanlige styrepapirer, og fungerende angrepskode bør ikke deles unødvendig. Bruk den avtalte sikre kanalen til informasjonen de ansvarlige faktisk trenger.
Sett av tid til kontroll, ikke bare til å finne feil
Bedriften kan be programvareleverandøren forklare hvordan den mottar, undersøker og prioriterer meldinger, også når feilen ligger i en komponent fra andre. Spør hva som skjer dersom leverandøren venter på at et prosjekt med åpen kildekode skal undersøke saken. En liten IT-leverandør kan ikke love når et uavhengig prosjekt gir ut en rettelse. Den kan likevel forklare hvordan den følger saken, informerer kunden og vurderer tiltak mens dere venter.
For bedrifter som utvikler programvare, må tid til gjennomgang planlegges. Ikke mål suksess bare i antall varsler som er laget eller lukket. Den som melder inn et funn, bør kontrollere hvilket produkt som er berørt, forklare grunnlaget og teste et forslag til rettelse før andre bes om å gjennomgå det. Dette er en anbefaling for arbeidet, ikke en garanti for at alle feilaktige meldinger blir fanget opp.
KI kan hjelpe med å samle duplikater, oppsummere rapporter eller foreslå tester. Sammenlign resultatet med kildematerialet, og sørg for at en feilaktig avvist melding kan hentes frem igjen. En modell kan gjøre feil også når den kontrollerer en annen modells svar. Test arbeidsformen på et utvalg avsluttede saker, og følg med på tiden fra mottak til en dokumentert beslutning, ikke bare antall behandlede varsler.
Muligheten er verdt å ta vare på. En god rapport kan avdekke en reell svakhet tidligere, og en godt kontrollert KI-assistert rettelse kan redusere rutinearbeid. Men noen må ha tid til å gjennomgå funnene, samarbeide med leverandører og teste resultatet. Uten den kapasiteten kan enda et verktøy for å finne feil gi en lengre kø uten å gjøre kundene tryggere.
Dette trenger ledelsen og styret å vite
Ledelsen bør vite hvilken programvare som holder viktige tjenester i gang, hvem som mottar og vurderer meldinger, og hvordan uløste funn når frem til dem som har ansvar for driften. En liten bedrift kan begynne med sin vanlige IT-leverandør og én tjeneste som må være tilgjengelig.
Når cyberrisikoen er vesentlig, bør styret spørre om ledelsen kan vise at viktige meldinger blir undersøkt, om avhengigheter til leverandører er synlige, og om det er satt av nok kapasitet til å handle. Styret skal ikke fastsette alvorlighetsgraden for hvert tekniske funn.
Artikkelen om å prioritere sikkerhetsoppdateringer tar for seg neste trinn, når en rettelse er tilgjengelig. Artikkelen om feilrettinger og angrepskode forklarer en annen risiko hos programvareprodusenten. Begge deler må følges opp for at et funn skal bli til beskyttelse.
Kildene ble kontrollert 2. november 2026. Kundeportalen og arbeidsformen er oppdiktede eksempler. Rådene er forfatterens vurderinger, ikke lovkrav. Illustrasjonen er KI-generert.