En bedrift kan ha installert den nyeste tilgjengelige programvaren og likevel være utsatt: En sikkerhetsrettelse er synlig for angripere før leverandøren har levert den som en oppdatering. Raskere oppdateringsrutiner i bedriften løser ikke forsinkelsen hos leverandøren.
KI gjør tidsrommet farligere. Norske bedrifter må derfor undersøke hvordan programvareleverandøren får en oppdaget svakhet rettet på kundenes systemer. Et løfte om å finne flere feil er ufullstendig uten en troverdig plan for å få rettelsene trygt i drift.
Dette viser den nye Firefox-studien
29. oktober 2026 rapporterte Epoch AI at GLM 5.3 laget nettsider som stjal filer fra seks Firefox-utgaver i tester uten internettilgang på Ubuntu 26.04. Å besøke siden var nok. Modellen kombinerte offentlige rettelser med en annen, upublisert sårbarhet. Forskerne oppga versjoner og stilte med ressurser. Dette var ikke en observert angrepskampanje. De oppnådde ikke et tilsvarende resultat mot Chrome og hadde ikke avklart om angrepet virket mot Firefox 159.0. Ifølge forskerne er den upubliserte feilen rettet i 159.0.
Mozilla lanserte Firefox 159.0 27. oktober. Sikkerhetsvarselet beskriver feilene som er rettet. Kontroller leverandørens oppdaterte varsel for produktet, plattformen og utgivelseskanalen dere bruker, også eventuelle støttede bedriftsutgaver. Ett versjonsnummer fra én kanal er ikke nødvendigvis riktig oppdatering for alle installasjoner.
Studien styrker argumentet for å installere tilgjengelige oppdateringer. Den viser også begrensningen i den beroligende beskjeden «vi er helt oppdatert». Det beskriver kundens installasjon, ikke alt leverandøren har oppdaget eller arbeider med å rette.
To forsinkelser med ulike ansvarlige
Undersøk to tidsrom. Først blir en rettelse synlig før den er tilgjengelig som en oppdatering leverandøren støtter. Deretter kan en tilgjengelig oppdatering bli liggende før kunden installerer og aktiverer den. Sikkerhetsteamet bak Google Chrome beskrev både forsinkelser ved utgivelse og venting på omstart i juli.
Programvareleverandøren styrer utviklingen og utgivelsene. Ledelsen styrer bedriftens utrulling og avtalen med IT-leverandøren. En ekstern driftsleverandør kan ha ansvar for installasjonen uten å bestemme når programvareprodusenten leverer en rettelse.
Ikke slå dette sammen til ett løfte om responstid. Et raskt svar på en henvendelse forteller ikke når en oppdatering er klar. Samtidig hjelper det lite at produsenten leverer raskt hvis maskinen fortsatt kjører den gamle versjonen.
Be om et eksempel på en sikkerhetsoppdatering som er gjennomført for produktet og utgivelseskanalen dere bruker. Hvilke trinn styrer produsenten, hvilke styrer driftsleverandøren, og når må bedriften selv gjøre noe? Målet er å avklare ansvaret mellom partene. En liten norsk IT-leverandør skal ikke måtte garantere en annen bedrifts utviklingstempo.
Mozilla endrer måten rettelser blir levert på
I sitt svar 29. oktober beskriver Mozilla ukentlige utgivelser og at tester som viser hvordan en feil utløses, holdes tilbake til rettelsen er levert. Selskapet planlegger også å gjøre rettelser i ulike sikkerhetslag synlige på ulike tidspunkter. Målet er å hindre at angripere får alle delene til et sammensatt angrep fra rettelser som er synlige samtidig før de er levert. Gjennomføringen krever samordning. Dette er et planlagt teknisk tiltak, ikke en garanti for at risikoen er borte.
Prinsippet er nyttig også uten de tekniske detaljene: Beskyttelsen bør ikke være avhengig av at alle barrierer alltid virker perfekt. Et godt system gjør at én svikt ikke er nok til et alvorlig innbrudd. Denne uavhengigheten må også ivaretas når nye versjoner blir levert.
Tenk på å reparere én av to sikkerhetsdører mens den andre holdes lukket. Dette er en illustrasjon av prinsippet, ikke en bokstavelig beskrivelse av nettlesersikkerhet. Programvareleverandøren må dokumentere hvilke barrierer som finnes, og hvordan de beskytter mens endringene blir levert.
Dette er en oppgave for leverandørens utviklere. Det er ingen grunn til at kundene skal utsette tilgjengelige oppdateringer eller velge sin egen rekkefølge på enkeltrettelser.
Tre spørsmål til programvareleverandøren
Ta med tre spørsmål i neste gjennomgang med leverandøren av viktig programvare:
- Hvordan sørger dere for at vår versjon raskt får sikkerhetsrettelsene? Spør hvordan sikkerhetsrettelser blir testet, og hvordan hasteoppdateringer når støttede versjoner. Leverandøren trenger ikke røpe detaljer som gjør feilen enklere å utnytte, for å forklare arbeidsmåten.
- Hva begrenser skaden hvis ett beskyttelseslag svikter? Spør hvilken separat barriere som beskytter viktige data eller administratorfunksjoner, og hvilke tester som underbygger svaret. En ekstra funksjon er ikke nødvendigvis en uavhengig barriere.
- Hvordan vet vi at oppdateringen er aktiv? Avtal hva driftsleverandøren skal rapportere om installerte versjoner, nødvendige omstarter, mislykkede installasjoner og unntak som faller utenfor det vanlige ansvaret.
Dette er forslag til spørsmål ved innkjøp og leverandøroppfølging, ikke en sertifiseringsordning eller nye lovkrav. Tilpass omfanget. Et lite AS kan begynne med nettleseren og ett viktig forretningssystem gjennom sin eksisterende IT-leverandør. En bedrift som kjøper en spesialutviklet plattform, bør undersøke hvordan utvikleren leverer oppdateringer, og hvilke andre komponenter plattformen er avhengig av.
En ærlig begrensning er nyttig informasjon. En driftsleverandør kan forklare at den ikke har innsyn i et bestemt tidsrom hos produsenten, og samtidig dokumentere en pålitelig utrulling hos kunden. Registrer begge deler. En generell forsikring om at «vi bruker den kraftigste KI-en», besvarer ingen av spørsmålene.
Et norsk eksempel: Oppdateringen er klar, men omstarten venter
Tenk deg et hypotetisk norsk ingeniørfirma. De ansatte bruker nettbaserte kundeportaler og et eget kalkulasjonsverktøy. IT-leverandøren opplyser at oppdateringer lastes ned automatisk. De ansatte lar likevel nettleseren stå åpen i flere dager for å unngå å avbryte arbeid de ikke er ferdige med.
Ledelsen bør be leverandøren vise at den rettede versjonen faktisk kjører, fremfor å godta at nedlastingen er fullført. Avtal en rutine for omstart med de ansatte, test de viktige kundeoppgavene og følg opp maskiner som er frakoblet eller holdt utenfor. Planlegg rundt arbeidet som skal gjøres, slik at de ansatte får lagret det de trenger og kommet trygt i gang igjen.
NSM anbefaler raske, sentralt styrte og mest mulig automatiske sikkerhetsoppdateringer, særlig av operativsystemer og programmer som behandler eksternt innhold, blant annet nettlesere. Pålitelige rutineoppdateringer er fortsatt grunnlaget.
For kalkulasjonsverktøyet bør driftsleverandøren avklare hvem som leverer sikkerhetsrettelser, hvilken versjon som støttes, og hvordan hasteoppdateringer blir testet uten å vente på et større endringsprosjekt. Hvis ingen rettelse er tilgjengelig, bruk den egne guiden til respons før en sikkerhetsoppdatering finnes til å forberede tiltak som begrenser eksponeringen og opprettholder driften, tilpasset risikoen og behovene.
Eksemplet skiller mellom det bedriften selv kan kontrollere, og det produsenten må levere. Ledelsen trenger oversikt over begge deler.
Dette bør styret be ledelsen følge opp
Når avhengigheten av programvaren er vesentlig, bør styret be ledelsen peke ut noen få viktige produkter, hvem som leverer og installerer rettelsene, og hva som dokumenterer at ordningen fungerer. Ledelsen bør forklare uavklarte avhengigheter og hvilke ressurser som trengs for å forbedre situasjonen. Styret bør vurdere om risikoen er akseptabel og prioriteringene riktige. Det skal ikke velge utgivelseskanaler eller tidspunkter for omstart.
KI er også en grunn til å investere i bedre sikkerhetsarbeid hos utviklerne. Kjøpere bør verdsette leverandører som finner svakheter og forklarer hvordan rettelsene når kundene. Å avvise et produkt bare fordi leverandøren offentliggjør flere rettede feil, belønner taushet fremfor nyttig arbeid. Vurder håndteringen, risikoen som gjenstår og dokumentasjonen, ikke bare antallet feil.
Bruk guiden til styrets cyberrapport til å gjøre dette skillet synlig. Det neste nyttige spørsmålet er: Hvor på veien fra et sikkerhetsfunn til beskyttelse på våre systemer bygger vi fortsatt på en antakelse, og hvem skal kontrollere den?
Kildene er kontrollert 31. oktober 2026. Ingeniørfirmaet og dørmetaforen er hypotetiske. Leverandørspørsmålene og ledelsesrådene er forfatterens vurderinger. Studien dokumenterer verken omfattende innbrudd, en universell tidsfrist før angrep eller at noen nettleser er varig sikker. Illustrasjonen er KI-generert.