400 varsler i Dependabot. Hvor starter dere?

Dagen alarmen ble teipet over

Tenk deg et team som skrur på dependency scanning. Tallene her er et eksempel, ikke en måling fra et prosjekt. Det starter med godt håndverk: endelig synlighet!

Så kommer rapporten. 400 funn. Rødt, oransje, gult i alle retninger.

De første ukene prøver noen å ta unna. Så kommer sprint-presset, og listen vokser. Etter tre måneder er varslene bakgrunnsstøy: en kanal alle har mutet, et tall ingen nevner.

Dette er varseltretthet. Skanningen finner fortsatt svakheter, men uten noen som vurderer og følger opp funnene, gir den lite hjelp til å avgjøre hva teamet bør gjøre først.

400 er ikke ett tall. Det er fire.

Feilen ligger i å behandle listen som én kø. Begynn med å finne det som haster. Deretter kan resten fordeles etter hvordan det skal håndteres:

1. Funn som krever rask handling. En kjent utnyttet sårbarhet som angriperen kan nå i deres system, skal høyt i køen. Det samme kan gjelde en alvorlig svakhet med en realistisk angrepsvei selv om utnyttelse ennå ikke er observert. Veien kan gå gjennom en intern tjeneste eller et byggverktøy; internetteksponering er ikke et krav.

Sett en ansvarlig og en kort frist for retting eller risikoreduserende tiltak. Er angrepsveien uavklart, gi undersøkelsen en frist også. I eksempelet antar vi at tolv av de opprinnelige 400 funnene havner her. Hos dere kan tallet være et annet.

2. Funn som vurderes som mindre utsatt i deres bruk. Biblioteket er sårbart, men dere har undersøkt at den berørte funksjonen ikke brukes, eller at et konkret tiltak begrenser angrepsveien. Da kan oppgraderingen planlegges inn i vanlig vedlikehold. Noter hvorfor det ble nedprioritert, hvem som følger opp, og når vurderingen skal gjøres på nytt. Antagelsen «vi bruker ikke den funksjonen» må etterprøves når kode, konfigurasjon eller kunnskapen om sårbarheten endres.

3. Funn som kan oppgraderes samlet. De gjenværende funnene med lavere vurdert risiko kan ofte tas i bolker ved rutinemessige oppgraderinger. Men «transitiv» betyr bare at pakken kommer inn via en annen avhengighet. Og et byggverktøy kan ha tilgang til kildekode, nøkler og det som skal publiseres, selv om det aldri havner i produksjon. GitHub beskriver hvordan en kompromittert runner kan gi tilgang til hemmeligheter og repoet. Vurder hvor verktøyet kjører og hva det får tilgang til før dere legger funnet i vedlikeholdskøen.

4. Zombie-avhengigheter. Pakker ingen husker hvorfor er der. Undersøk om de fortsatt brukes, også i bygg og tester. Er de overflødige, fjern dem og sjekk at systemet fortsatt fungerer. Da slipper dere både sårbarheten og fremtidige oppgraderinger av pakken.

Sorteringskriteriet er altså ikke CVSS-scoren alene. Spør om det finnes kjent eller sannsynlig utnyttelse, om angriperen kan nå den sårbare koden, og hva konsekvensen vil være. Dette er spørsmål som må vurderes sammen, ikke en formel der tre tall skal ganges. Alvorlighetsgraden trenger kontekst for å bli en arbeidsrekkefølge.

To gratis kilder hjelper dere med spørsmålet om utnyttelse:

• EPSS (Exploit Prediction Scoring System, fra FIRST) anslår sannsynligheten for observert utnyttelse av en CVE i felt de neste 30 dagene. Scoren oppdateres daglig og er fritt tilgjengelig via API. Dependabot lar dere filtrere på den. FIRST oppgir at partnerne observerer utnyttelsesaktivitet for rundt 2,5–3 prosent av publiserte CVE-er i et 30-dagersvindu. Det er et bilde av observert aktivitet på tvers av systemer, ikke sannsynligheten for at akkurat dere blir rammet. En lav score er ikke et fritak fra å vurdere konsekvensen hos dere.
• CISA KEV (Known Exploited Vulnerabilities Catalog) lister sårbarheter med bekreftet utnyttelse i felt. Den hadde 1 733 oppføringer 2. oktober 2026. Et treff er et sterkt signal om å undersøke og handle raskt, også når EPSS er lav. Sjekk berørte versjoner, angrepsvei og tiltak hos dere; katalogen kjenner ikke deres konfigurasjon.

Et konkret eksempel på slik prioritering er CISA BOD 26-04, utstedt 10. juni 2026 for amerikanske føderale sivile virksomheter. Fristene bygger på eksponering, KEV-status, om angrepet kan automatiseres, og hvor mye kontroll angriperen får. De spenner fra tre til seksti dager, mens enkelte kombinasjoner kan vente til neste store oppgradering eller gjenoppbygging.

Noen tilfeller krever også en undersøkelse av om systemet allerede er kompromittert. Dette er deres regelverk, ikke en fristtabell norske team er pålagt å følge. Det viser hvordan kontekst kan styre frister.

For å undersøke om applikasjonen kaller den sårbare koden, kan dere bruke reachability-analyse. Snyk og Semgrep tilbyr slik analyse. GitHub bruker også funn av sårbare funksjonskall i prioriteringen. Sjekk hvilke språk, pakker og integrasjoner verktøyet støtter. Semgrep Supply Chain er gratis for organisasjoner med inntil ti bidragsytere etter deres telleregler; over grensen kreves betalt lisens.

Analysen hjelper dere å prioritere, men den friskmelder ikke resten av listen. Snyk understreker at manglende funn av en kallesti ikke beviser at koden er utilgjengelig. Dynamiske kall og ufullstendig informasjon kan gi blindsoner. Bruk resultatet som støtte for en begrunnet vurdering, og behold en plan for funnene som ikke haster.

Gjør køen umulig å ignorere – ved å gjøre den liten

Tre mekanismer holder systemet friskt etter sorteringen:

• Stopp nye funn som haster, før de innføres. En kontroll i PR-en kan blokkere nye avhengigheter med risiko teamet ikke kan akseptere. GitHubs dependency review undersøker endringer i avhengigheter; den ordner ikke den eksisterende backloggen av seg selv. Gi eksisterende kritiske funn en ansvarlig og en frist, og sørg for at porten slipper gjennom selve rettingen. Et nødvendig unntak må ha en begrunnelse, en ansvarlig med mandat til å akseptere risikoen, et risikoreduserende tiltak og en utløpsdato.
• Resten tas i bolker, på rytme. En fast, liten dose oppgraderinger hver sprint – kjedelig, forutsigbar, aldri et skippertak. Samme logikk som all forbedring som faktisk skjer: den bor i hverdagen.
• Mål hvor lenge kritisk risiko blir stående. Følg tiden fra et kritisk funn oppdages til rettingen eller tiltaket er verifisert i det berørte miljøet. En merget PR er ikke nok. Se også på hvilke kritiske funn som fortsatt er åpne og hvor gamle de er; et fallende totaltall kan skjule ett viktig funn som aldri blir håndtert.

Ut av bakgrunnsstøyen

400 varsler er ikke synlighet. Det er tåke med fargekoder.

I eksempelet fikk tolv funn rask oppfølging. De andre 388 ble ikke erklært trygge; de fikk en begrunnelse og en plan for vedlikehold eller fjerning.

Begynn med det eldste funnet dere vurderer som kritisk. Avklar hvem som følger det opp, når risikoen skal være redusert, og hvordan dere skal verifisere det.