OSV-anbefalinger

Scanning af afhængigheder viser de enkelte CVE’er. Fanen Anbefalinger under Sikkerhed › Fund › Afhængigheder (/<org>/_admin/security/findings/dependencies?view=recommendations) gør den liste til en rettelsesliste: hvert åbent fund med en udgivet rettelse bliver til ét kort med repo + package + current → fix + hvilke CVE’er den ene opgradering løser.

Sådan beregnes anbefalingerne

Grupperingsnøglen er (repo_full_name, ecosystem, package_name, current_version, fixed_version). Fund, der deler alle fem, samles i ét kort.

Sorteringen sker i tre trin:

1. Reachability: et kort får den mest nåbare nåbarhedsvurdering blandt de fund, det retter: nåbar først, derefter ukendt (inklusive ikke analyseret), derefter ikke nåbar.
2. Alvorlighed (inden for en vurdering): critical → high → medium → low.
3. EPSS-score (inden for alvorlighed): den højeste EPSS-score blandt de samlede sårbarheder vinder.

En advisory med lav alvorlighed, som din kode når, sorteres altså over en kritisk, der ikke er nåbar, og inden for samme vurdering og alvorlighed sorteres en advisory, der aktivt udnyttes, over en teoretisk. Et kort, der ikke er nåbart, vises stadig; det rykker bare ned. Oversigtens topanbefalinger og den ugentlige oversigt bruger samme rækkefølge.

Hvad 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, hvis vurdering er nåbar eller ikke nåbar, viser også Kan nås eller Ikke nåbar ved siden af alvorligheden.

• Manifeststier: hvis samme pakke er fastlåst i både package-lock.json og pnpm-lock.yaml, vises begge.
• EPSS: den højeste sandsynlighed for udnyttelse (exploit prediction) blandt de samlede CVE’er (0–100 %). Det daglige opdateringsjob henter EPSS-data fra FIRST.org.
• Sårbarheds-id’er: de første tre vises direkte; resten i en +N-opsummering.

Få opgraderings-pull requesten

Hvert kort har knappen Åbn rettelses-PR for pakker i de økosystemer, der får sikkerhedsrettelser (se Understøttede økosystemer). Den åbner én pull request, der opgraderer pakken i det repository, som din organisations afhængighedsbot, og den venter på review eller merges, når dens tjek består, alt efter hvad din organisation har valgt; se Merging. Når den er bestilt, viser kortet Rettelse foreslået: #N med pull requestens tilstand.

Andre måder at få opgraderingen på:

• Lad opdateringer af afhængigheder åbne pull requests. Med Opdateringer af afhængigheder slået til åbner Renovate en pull request med en sikkerhedsopdatering i sin næste natlige kørsel, efter at en advisory (OSV) er udgivet for en afhængighed, uden hensyn til din schedule og ventetiden for release-alder. Når en åben Renovate-pull request allerede opgraderer en pakke, linker fundet på fanen Fund til den (Renovate-PR #n).
• Start en kørsel nu. Fanen Anbefalinger har knappen Start en kørsel med opdatering af afhængigheder, der starter en ekstra Renovate-kørsel for hele organisationen, højst én gang i timen. Er opdateringer af afhængigheder ikke slået til, linker fanen til den side, hvor du slår det til.
• Opgradér selv. Hvert kort angiver pakken, den installerede version og den foreslåede rettede version, så du kan lave ændringen i din egen branch og lade scanningen af pull requesten bekræfte, at fundene er væk.

Det gamle endpoint Åbn opgraderings-PR forbliver nedlagt og svarer 410 Gone; knappen Åbn rettelses-PR erstatter det.

Kræver migrering: rettelsen ligger i en anden pakke

Nogle advisories har ingen rettelse til den pakke, du bruger, men er rettet i en efterfølger, som advisoryen selv navngiver: en ny modulsti eller major-version eller en omdøbt pakke. Eksempler fra rigtige advisories:

Sådan et fund viser Kræver migrering til <package> (rettet i <version>) i stedet for “ingen rettelse endnu” på fanerne Fund og Efter pakke, i API’et (needs_migration, se API til fund) og i den ugentlige oversigt. Det vises ikke under Anbefalinger og får ingen knap Åbn rettelses-PR: at skifte til et andet modul eller en anden pakke ændrer imports og ofte API’et, så det er en kodeændring, du selv skal lave, ikke en versionsopgradering.

Sådan vælges efterfølgeren:

• Advisoryen skal berøre din installerede version og må ikke angive nogen rettet version af din pakke over den. Har din egen pakke en rettelse, får fundet den rettelse som sædvanligt.
• Efterfølgeren er en anden pakke i samme økosystem, som advisoryen angiver med en rettet version. Den viste version er den laveste, advisoryen ikke berører. En advisorys aliasser (for eksempel en Go GO-…-post og dens GHSA-…-tvilling) læses samlet.
• Når der er angivet flere, foretrækker Go samme major-version som din (go-jose.v2 til go-jose/go-jose.v2, ikke go-jose/v4), derefter den laveste højere major, og foreslår aldrig en lavere major af samme modul. Andre økosystemer foretrækker et navn, der ender på dit (request til @cypress/request).
• Når versionerne ikke kan ordnes, eller ingen anden pakke er rettet, beholder fundet “ingen rettelse endnu”. En advisory, der ikke er rettet nogen steder, for eksempel golang.org/x/crypto/openpgp (ikke vedligeholdt), vises aldrig som en migrering.

Hvorfor det ikke er det samme som fanen Fund

Fanen Fund er den kanoniske kilde: én række pr. (CVE × manifest). Anbefalinger er den handlingsrettede opsummering:

• En pakke uden udgivet rettelse vises aldrig under Anbefalinger (der er endnu intet at gøre).
• En pakke, der kan rettes med én opgradering, vises én gang under Anbefalinger og N gange under Fund (én pr. CVE).
• Et afvist fund vises aldrig nogen af stederne.

Brug Fund til at triagere enkelte CVE’er og afvisninger; brug Anbefalinger til at styre dagens faktiske rettelsesarbejde.

Via REST API’et

GET /_app/api/v1/orgs/:slug/security/recommendations (findings:read) returnerer selve anbefalingerne i fanens rækkefølge: én post pr. repository, pakke og nuværende version, med fixed_version, highest_severity, vulnerability_count, vulnerability_ids, manifest_paths, max_epss, reachability, known_exploited og finding_id, det fund på standardbranchen, som en anmodning om sikkerhedsrettelse navngiver (null, når alle gruppens fund er på en pull request).

De underliggende CVE-fund, de rå data, som Anbefalinger samler, er tilgængelige i det offentlige API. Brug dem, når du bygger et eget dashboard, eksporterer til et ticketsystem eller lader en AI-agent styre prioriteringen.

• List afhængighedsfund GET /_app/api/v1/orgs/:slug/code-security/deps/findings: én række pr. (CVE × manifest) med package_name, current_version, fixed_version, severity, vulnerability_id, manifest_path. Gruppér på klientsiden efter (repo_full_name, ecosystem, package_name, current_version, fixed_version) for at genskabe samlingen fra Anbefalinger.
• Afvis et fund POST /_app/api/v1/orgs/:slug/code-security/deps/findings/:id/dismiss med body: { "reason": "..." }

Liste-endpointet kræver et personligt adgangstoken (PAT) med scopet findings:read; afvisninger kræver findings:write:

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

Se referencen for det offentlige REST API for den fulde OpenAPI-specifikation.

Se også

• SLA for rettelse: hvordan SLA-mærket på fanen Fund beregnes.
• Sikkerhedsoversigt: sender hver mandag en mail med de 5 vigtigste fund, der kan rettes, nåbare først.
• Push-beskyttelse: secrets, der blokeres ved push, den forreste del af samme forsyningskædetriade.