OSV-anbefalinger

Avhengighetsskanningen viser enkeltstående CVE-er. Fanen Anbefalinger under Sikkerhet › Funn › Avhengigheter (/<org>/_admin/security/findings/dependencies?view=recommendations) gjør den listen om til en rettingsliste: hvert åpent funn med en publisert rettelse blir ett kort – repo + package + current → fix + hvilke CVE-er den ene oppgraderingen løser.

Slik beregnes anbefalingene

Grupperingsnøkkelen er (repo_full_name, ecosystem, package_name, current_version, fixed_version). Funn som deler alle fem, slås sammen til ett kort.

Sorteringen skjer i tre trinn:

1. Nåbarhet – et kort får den mest nåbare nåbarhetsvurderingen blant funnene det retter: nåbar først, deretter ukjent (inkludert ikke analysert), deretter ikke nåbar.
2. Alvorlighetsgrad (innenfor en vurdering) – critical → high → medium → low.
3. EPSS-poengsum (innenfor alvorlighetsgraden) – den høyeste EPSS-poengsummen blant de samlede sårbarhetene vinner.

Et sårbarhetsvarsel med lav alvorlighetsgrad som koden din når, sorteres altså over et kritisk varsel som ikke er nåbart, og innenfor samme vurdering og alvorlighetsgrad sorteres et varsel som utnyttes aktivt, over et teoretisk. Et kort som ikke er nåbart, vises fortsatt; det flyttes bare nedover. Toppanbefalingene i oversikten og den ukentlige oppsummeringen bruker samme rekkefølge.

Hva kortet viser

acme/api                                              critical
  npm:lodash 4.17.20 → 4.17.21
  3 vulns fixed · EPSS 23.4% · CVE-2021-23337, CVE-2020-8203 +1

Et kort med vurderingen nåbar eller ikke nåbar viser også Nåbar eller Ikke nåbar ved siden av alvorlighetsgraden.

• Manifeststier – hvis samme pakke er låst i både package-lock.json og pnpm-lock.yaml, vises begge.
• EPSS – den høyeste sannsynligheten for utnyttelse blant de samlede CVE-ene (0–100 %). Den daglige oppdateringsjobben henter EPSS-data fra FIRST.org.
• Sårbarhets-ID-er – de tre første vises direkte; resten i en +N-oppsummering.

Få oppgraderings-PR-en

Hvert kort har en Åpne PR med rettelse-knapp for pakker i økosystemene som får sikkerhetsrettelser (se Støttede økosystemer). Den åpner én pull request som oppgraderer pakken i det repositoryet, som organisasjonens avhengighetsbot, og den venter på gjennomgang eller merges når sjekkene består, slik organisasjonen din har valgt; se Merging. Når den er bestilt, viser kortet Fix proposed: #N med statusen til pull requesten.

Andre måter å få oppgraderingen på:

• La Dependency updates åpne PR-ene. Med Avhengighetsoppdateringer slått på åpner Renovate en PR med en sikkerhetsoppdatering i den neste nattlige kjøringen etter at et sårbarhetsvarsel (OSV) er publisert for en avhengighet, uten å ta hensyn til schedule eller ventetiden for nye utgivelser. Når en åpen Renovate-PR allerede oppgraderer en pakke, lenker funnet på Funn-fanen til den (Renovate PR #n).
• Start en kjøring nå. Anbefalinger-fanen har en Start en kjøring av avhengighetsoppdateringer-knapp som starter en Renovate-kjøring utenom tur for hele organisasjonen, høyst én gang i timen. Hvis Dependency updates ikke er slått på, lenker fanen til siden der du slår det på.
• Oppgrader selv. Hvert kort oppgir pakken, den installerte versjonen og den foreslåtte rettede versjonen, så du kan gjøre endringen i din egen branch og la PR-skanningen bekrefte at funnene er borte.

Det gamle Åpne PR for oppgradering-endepunktet er fortsatt pensjonert og svarer 410 Gone; Åpne PR med rettelse-knappen erstatter det.

Krever migrering: rettelsen ligger i en annen pakke

Noen sårbarhetsvarsler har ingen rettelse i pakken du bruker, men er rettet i en etterfølger som varselet selv navngir: en ny modulsti eller hovedversjon, eller en pakke med nytt navn. Eksempler fra virkelige varsler:

Et slikt funn viser Krever overgang til <package> (rettet i <version>) i stedet for «ingen rettelse ennå», på fanene Funn og Per pakke, i API-et (needs_migration, se Findings-API-et) og i den ukentlige oppsummeringen. Det vises ikke under Anbefalinger og får ingen Åpne PR med rettelse-knapp: å flytte til en annen modul eller pakke endrer importer og ofte API-et, så det er en kodeendring du selv må gjøre, ikke en versjonsoppgradering.

Slik velges etterfølgeren:

• Varselet må gjelde den installerte versjonen din og ikke oppgi noen rettet versjon av pakken din over den. Hvis din egen pakke har en rettelse, får funnet den rettelsen som vanlig.
• Etterfølgeren er en annen pakke i samme økosystem som varselet oppgir med en rettet versjon. Versjonen som vises, er den laveste som varselet ikke gjelder. Et varsels aliaser (for eksempel en Go-GO-…-oppføring og tvillingen GHSA-…) leses sammen.
• Når flere er oppgitt, foretrekker Go samme hovedversjon som din (go-jose.v2 til go-jose/go-jose.v2, ikke go-jose/v4), deretter den laveste høyere hovedversjonen, og foreslår aldri en lavere hovedversjon av samme modul. Andre økosystemer foretrekker et navn som slutter med ditt (request til @cypress/request).
• Når versjonene ikke kan ordnes, eller ingen annen pakke er rettet, beholder funnet «ingen rettelse ennå». Et varsel som ikke er rettet noe sted, for eksempel golang.org/x/crypto/openpgp (ikke vedlikeholdt), vises aldri som en migrering.

Hvorfor dette ikke er det samme som Funn-fanen

Funn-fanen er den kanoniske kilden – én rad per (CVE × manifest). Anbefalinger er den handlingsrettede oppsummeringen:

• En pakke uten publisert rettelse vises aldri under Anbefalinger (det er ikke noe å gjøre ennå).
• En pakke som kan rettes med én oppgradering, vises én gang under Anbefalinger og N ganger under Funn (én per CVE).
• Et avvist funn vises aldri i noen av dem.

Bruk Funn til å vurdere enkeltstående CVE-er og avvisninger; bruk Anbefalinger til å styre dagens faktiske rettingsarbeid.

Via REST-API

GET /_app/api/v1/orgs/:slug/security/recommendations (findings:read) returnerer selve anbefalingene, i samme rekkefølge som fanen: én oppføring per repository, pakke og nåværende versjon, med fixed_version, highest_severity, vulnerability_count, vulnerability_ids, manifest_paths, max_epss, reachability, known_exploited og finding_id, funnet på standardbranchen som en forespørsel om sikkerhetsrettelse navngir (null når alle funnene i gruppen ligger på en pull request).

De underliggende CVE-funnene – rådataene som Anbefalinger samler – er tilgjengelige i det offentlige API-et. Bruk dem når du bygger et eget dashbord, eksporterer til et ticket-system eller styrer prioriteringen fra en AI-agent.

• List avhengighetsfunn GET /_app/api/v1/orgs/:slug/code-security/deps/findings – én rad per (CVE × manifest), med package_name, current_version, fixed_version, severity, vulnerability_id, manifest_path. Grupper på klientsiden etter (repo_full_name, ecosystem, package_name, current_version, fixed_version) for å gjenskape sammenstillingen i Recommendations.
• Avvis et funn POST /_app/api/v1/orgs/:slug/code-security/deps/findings/:id/dismiss body: { "reason": "..." }

Listeendepunktet krever et personlig tilgangstoken (PAT) med scopet findings:read; avvisninger krever findings:write:

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  "https://frem.sh/_app/api/v1/orgs/acme/code-security/deps/findings?include_dismissed=false"

Se referansen for det offentlige REST-API-et for hele OpenAPI-spesifikasjonen.

Se også

• SLA for utbedring – hvordan SLA-merket på Funn-fanen beregnes.
• Sikkerhetsoppsummering – sender de 5 viktigste funnene som kan rettes, nåbare først, på e-post hver mandag.
• Push-beskyttelse – secrets som blokkeres ved push, den andre halvdelen av den samme forsyningskjede-triaden.