Sikkerhetsrettelser

En sikkerhetsrettelse gjør et avhengighetsfunn om til en pull request. Klikk Åpne PR med rettelse på et funn eller på et kort under Recommendations, eller kall API-et, så åpner organisasjonens avhengighetsbot én pull request i det repositoryet. Den oppgraderer pakken til den laveste utgitte versjonen som retter alle åpne sårbarhetsvarsler for den. Dette er sporet Sikkerhetsrettelser i Avhengighetsoppdateringer, under Sikkerhet › Utbedre › Avhengighetsoppdateringer.

Sikkerhetsrettelser dekker avhengigheter i npm (inkludert Yarn, pnpm og Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex og CRAN (R) samt versjoner av CI-actions (GitHub Actions), i manifestene som er oppført under Økosystemer og manifester. Andre økosystemer svarer not yet supported. Hele listen står på Støttede økosystemer. Ingen AI-modell er involvert: oppgraderingen beregnes ut fra OSV-postene for sårbarhetsvarslene.

For en sårbarhet i et image som er pushet til registeret ditt, og som fulgte med imagets FROM-base, oppgraderer Åpne PR med rettelse av base-image denne basen, så snart fremforge har sjekket at den nyere basen ikke lenger har sårbarheten. Se Oppgradering av base-imager. Fix all in this repository ber om alle pakker som kan rettes i et repository på én gang: se Rett alt som kan rettes i et repository.

Sikkerhetsrettelser het AutoFix frem til 2026-10-14. AutoFix er ikke lenger et produktnavn: AI-genererte rettelser for SAST-funn er AI-rettelse. Revisjonshendelsene autofix.* og de utfasede API-stiene bærer fortsatt det gamle navnet. Pull requests som ble åpnet før byttet, beholder autofix/-branchen sin; fremforge legger etiketten security-fix til på dem som fortsatt er åpne.

Innstillinger

En eier setter disse under Sikkerhet › Utbedre › Avhengighetsoppdateringer › Sikkerhetsrettelser, eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Alle felt er valgfrie i en PUT; et felt som utelates, beholder verdien sin, og ingenting lagres hvis et felt avvises.

Modusene:

• Av (off): ingen pull requests med sikkerhetsrettelser, verken ved klikk eller automatisk.
• Ved klikk (on_click): en person ber om dem, med Åpne PR med rettelse, Fix all in this repository eller Åpne PR med rettelse av base-image, eller via API-et.
• Automatisk for viktige funn (auto_important): som ved klikk, og i tillegg åpner fremforge dem selv for høye og kritiske funn som er nåbare eller kjent utnyttet. Med Also findings with unknown reachability slått på teller også høye og kritiske funn uten en vurdering av nåbarhet. Se Automatiske sikkerhetsrettelser.
• Automatisk for alle høye og kritiske (auto_high_critical): fremforge åpner dem selv for alle høye og kritiske funn den kan rette, uansett nåbarhet.
• Automatisk for kritiske og kjent utnyttede (auto_critical_exploited): fremforge åpner dem selv for alle kritiske funn, uansett nåbarhet, og for alle kjent utnyttede funn uansett alvorlighetsgrad. Et høyt, middels eller lavt funn som ikke er kjent utnyttet, venter på et klikk. Dette er standard for en organisasjon opprettet 2026-10-27 eller senere; se Nye organisasjoner.

Svaret inneholder også skrivebeskyttede felt. configured er false så lenge organisasjonen aldri har lagret innstillingene og verdiene er standardverdiene (for en ny organisasjon: standardverdiene den ble opprettet med). lane_owner sier hvem som åpner pull requests for sikkerhet: renovate så lenge hostet Renovates egne pull requests for sikkerhet fortsatt betjener organisasjonen, security_lane når dette sporet har tatt over. high_blast_radius_exempt er true for organisasjoner der Renovates pull requests for sikkerhet merget seg selv før 2026-10-14, og som ble flyttet til Merge når sjekkene går gjennom; se Merging.

En endring registreres i revisjonsloggen som dependency-updates.security-fixes.updated, med gammel og ny verdi for hvert felt.

curl -X PUT -H "Authorization: Bearer ${FREMFORGE_PAT}" -H "Content-Type: application/json" \
  -d '{"mode": "auto_important", "max_per_day": 10}' \
  "https://frem.sh/_app/api/v1/orgs/acme/dependency-updates/security-fixes/settings"

Sikkerhetsrettelser krever ikke versjonsoppdateringer. Den første forespørselen om en rettelse (Åpne PR med rettelse, Fix all in this repository, Åpne PR med rettelse av base-image eller POST .../security-fixes/requests), eller å lagre en automatisk modus, klargjør organisasjonens avhengighetsbot <org>-fremforge-bot-deps med versjonsoppdateringer slått av. Et repository som er meldt ut av avhengighetsoppdateringer, får ingen pull requests med rettelser, og et arkivert repository eller et speil-repository avvises (repo_archived).

Hva som skjer når du klikker Open fix PR

1. fremforge samler alle åpne funn på standardbranchen for den samme pakken i det samme repositoryet. Én pull request lukker alle sammen.
2. Den beregner målversjonen. For hver installert versjon er det den laveste utgitte versjonen som ligger utenfor alle berørte versjonsintervaller i alle åpne sårbarhetsvarsler. Pull requesten bruker den høyeste av disse, slik at den retter hele gruppen.
3. En målrettet kjøring av hostet Renovate starter, som organisasjonens avhengighetsbot. Den er begrenset til den ene pakken og den ene versjonen. Alle andre avhengigheter blir latt være.
4. Renovate åpner pull requesten på en branch security-fix/<package>-<version>. Kjøringer for sikkerhetsrettelser går foran vanlige Renovate-kjøringer, så dette tar som regel under 15 minutter. Pull requesten får etiketten security-fix. Har repositoryet ikke den etiketten ennå, oppretter fremforge den før kjøringen, én gang; en etikett som allerede finnes, blir stående som den er. Kan en etikett ikke opprettes, åpnes pull requesten uten den.
5. fremforge sjekker pull requesten før den holdes åpen. Den kan bare endre økosystemets manifester og låsefiler (se tabellen nedenfor), og i et manifest bare oppføringen for den pakken. En endring i en annen fil, en ny direkte avhengighet, en oppgradering av en annen pakke, en delt versjon eller en låsefil der pakkene nå kommer fra en annen indeks, lukker pull requesten og sletter branchen. Det samme gjør en mislykket oppfrisking av låsefilen: en pull request med en utdatert låsefil ville ikke bygge.

Funnet viser deretter Fix proposed: #N med tilstanden til pull requesten: åpen, merget eller lukket.

Hver kopi, til rettelsen. En låsefil kan inneholde flere kopier av én pakke: en direkte, og eldre kopier nestet under andre avhengigheter. Før en pull request regnes som en rettelse, leser fremforge låsefilene ved pull requestens head og sjekker hver kopi av pakken de registrerer, mot den rettede versjonen. Dette gjelder package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock, Cargo.lock, go.mod og NuGets packages.lock.json, både for enkeltrettelser og grupperte rettelser. En forhåndsutgivelse av den rettede versjonen regnes som lavere enn den.

• Alle kopier på eller over rettelsen: pull requesten retter pakken.
• Noen kopier rettet, en eldre igjen: pull requesten forblir åpen, og konsollen navngir kopiene som er igjen (i API-et: forespørselens lock_copies_left, med reason target_partly_reached). Fix proposed vises bare på funnene for kopiene den retter; de andre beholder Rettelse-knappen sin.
• Ingen kopi på rettelsen, for eksempel en transitiv kopi som fulgte med forelderen sin, men til en versjon som fortsatt er sårbar: pakken er ikke en del av pull requesten. Forespørselen for den ender som target_not_reached, og den transitive rettelsen låser den for seg selv. En pull request uten noen rettet pakke lukkes.

Et låsefilformat som ikke står her, sjekkes som før: pull requesten må endre pakken i låsefilen.

Hva denne sjekken ikke gjør:

• Bare låsefilene pull requesten endrer, leses. Hvis en annen låsefil i repositoryet, en som pull requesten ikke rører, fortsatt inneholder en sårbar versjon, forblir det funnet åpent etter merge. Det regnes ikke som rettet: Rettelse-knappen blir stående.
• En kopi som blir igjen, rettes etter merge, ikke samtidig. Mens pull requesten er åpen, avvises en ny forespørsel for den samme pakken fordi det allerede finnes en åpen, så Rettelse på en kopi som pull requesten etterlater, starter ingenting ennå. Be om den på nytt etter merge og neste skanning.
• Samme versjon, direkte og nestet. Et funn identifiseres ved pakke og versjon, ikke ved hvor i treet kopien ligger. Hvis pull requesten flytter den direkte kopien, men den samme gamle versjonen fortsatt ligger nestet under en annen avhengighet, er det funnet ikke rettet, så forespørselen ender som target_not_reached og pull requesten lukkes. Den transitive rettelsen avviser en pakke som manifestet ditt navngir direkte, så lås den nestede kopien selv (for eksempel med en overrides-oppføring i npm).

Repositoryets Renovate-innstillinger

Repositoryets egen renovate.json (eller .renovaterc, eller nøkkelen renovate i package.json) former versjonsoppdateringene dets. Den holder ikke tilbake en sikkerhetsrettelse. En kjøring for en sikkerhetsrettelse ignorerer repositoryets:

• packageRules, inkludert en regel med "enabled": false for pakken;
• ignoreDeps;
• ignorePaths og includePaths. Bare node_modules og bower_components hoppes over;
• enabledManagers. Kjøringen bruker managerne for funnets økosystem.

For å holde en pakke utenfor sikkerhetsrettelser registrerer du et unntak for funnene dens: avvis dem med en begrunnelse og helst en utløpsdato, eller be om et godkjent unntak. Et funn med unntak er ikke åpent, så det lages ingen forespørsel om rettelse for det, og Åpne PR med rettelse svarer security-fix-not-open. I motsetning til en holderegel i en fil er et unntak synlig på siden Exceptions, viser hvem som laget det og hvorfor, og faller bort på utløpsdatoen.

To innstillinger gjelder fortsatt:

• En "enabled": false på toppnivå i renovate.json slår av Renovate for hele repositoryet, også sikkerhetsrettelser.
• packageRules i et repository som setter registryUrls eller andre oppslagsinnstillinger, gjelder ikke for en kjøring for en sikkerhetsrettelse. Kjøringen slår opp pakker via organisasjonens egne innstillinger og avhengighetsproxyen.

Kjent utnyttede sårbarheter først

Når et sårbarhetsvarsel som en forespørsel retter, har en CVE som er oppført som utnyttet i praksis, av ENISAs EU Vulnerability Database (EUVD) eller CISAs Known Exploited Vulnerabilities-katalog (KEV), behandles rettelsen som den mest presserende:

• Den kjører først. Renovate-kjøringen dens tas før alle andre forespørsler om sikkerhetsrettelser i køen, uansett rekkefølgen de ble bedt om i.
• Den er først i Fix all. En Fix all in this repository-bunke slipper inn kjent utnyttede pakker før de andre, deretter etter alvorlighetsgrad, så når en grense nås, er det en mindre presserende pakke som blir utelatt.
• Den venter ikke på utgivelsesalderen. Utgivelsesalder holder tilbake andre rettelser, men en versjon som retter en kjent utnyttet sårbarhet, foreslås med en gang.
• Pull requesten sier det. Tittelen slutter med known exploited, for eksempel fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), beskrivelsen begynner med CVE-ene og listene som nevner dem, og pull requesten får også etiketten known-exploited, opprettet på samme måte som security-fix.

En CVE teller når den er sårbarhetsvarselets egen id eller et av aliasene (et GHSA- eller PYSEC-varsel har vanligvis et CVE-alias). Begge listene speiles og oppdateres daglig. Om en forespørsel er kjent utnyttet, avgjøres når den lages; API-et oppgir det som known_exploited_cves. Med Merge når sjekkene går gjennom aktiveres den også utenfor merge-vinduet ditt; se Merging. Grensene gjelder fortsatt.

Automatiske sikkerhetsrettelser

Med Automatisk for viktige funn, Automatisk for alle høye og kritiske eller Automatisk for kritiske og kjent utnyttede åpner fremforge de samme pull requestene som et klikk på Åpne PR med rettelse eller Åpne PR med rettelse av base-image, uten at noen klikker, for hvert funn som oppfyller alt dette:

1. Det er åpent på standardbranchen: ikke avvist, ikke oppdaget i en pull request.
2. Alvorlighetsgraden er høy eller kritisk. Middels og lave funn rettes bare automatisk med Automatisk for kritiske og kjent utnyttede, og bare når de er kjent utnyttet.
3. Med Automatisk for viktige funn: det er nåbart (nåbarhetsvurderingen er reachable) eller det er kjent utnyttet (en CVE for det er oppført av ENISA EUVD eller CISA KEV), eller, med Also findings with unknown reachability slått på, det har ingen eller en ukjent vurdering. Et kjent utnyttet funn kvalifiserer selv når det ikke er nåbart. Med Automatisk for alle høye og kritiske kvalifiserer alle høye og kritiske funn. Med Automatisk for kritiske og kjent utnyttede kvalifiserer et kritisk funn uansett nåbarhet, et kjent utnyttet funn kvalifiserer uansett alvorlighetsgrad, og ingenting annet gjør det.
4. fremforge kan rette det deterministisk: en avhengighet i et dekket økosystem og manifest med en utgitt rettelse, eller et imagefunn som en oppgradering av base-imaget retter.

Vil du prøve det på noen få repositoryer først, fører du dem opp under Repositoryer. En tom liste dekker alle repositoryene i organisasjonen. Eksempel-repositoryet for sikkerhet rettes aldri automatisk; et klikk på Åpne PR med rettelse virker fortsatt der.

Nye organisasjoner

En organisasjon opprettet 2026-10-27 eller senere starter med Automatisk for kritiske og kjent utnyttede, og Når rettelser merges satt til Vent på gjennomgang: pull requests med rettelser åpnes av seg selv, og ingen merges uten en person. Grensene, grupperingen og utgivelsesalderen beholder standardverdiene sine. Ingenting meldes på versjonsoppdateringer: avhengighetsboten <org>-fremforge-bot-deps opprettes først når det første funnet kvalifiserer. En eier kan når som helst bytte til en annen modus, også Av, eller utvide den. Organisasjoner opprettet før 2026-10-27 beholder innstillingen de hadde.

Når den handler

fremforge sjekker hvert tiende minutt. Et funn foreslås kort tid etter at det kvalifiserer: når en skanning rapporterer et nytt funn, når vurderingen blir nåbar, eller når den daglige oppdateringen av kjent utnyttede legger til en av CVE-ene. Funn som allerede kvalifiserer når du slår det på, tas også med, innenfor grensene.

Hva som er likt

Hver automatisk forespørsel går nøyaktig samme vei som et klikk: én pull request per pakke (eller per base-image), den laveste versjonen som retter, organisasjonens grenser, sperren for utgivelsesalder, avvisningen av delte versjoner og omfangssjekkene. I listen over forespørsler har en slik forespørsel "trigger": "policy", og pull requesten sier at den ble åpnet automatisk.

• Den merges slik du har satt det. Som alle pull requests med sikkerhetsrettelser følger den Når rettelser merges; se Merging.
• Den bruker aldri AI. Bare den deterministiske motoren kjører automatisk. AI-rettelse starter alltid med at en person klikker på ett funn.
• En topp venter på tur. Når listen over kjent utnyttede legger til en CVE som mange av repositoryene dine har, åpner fremforge det grensene dine tillater, kjent utnyttede og kritiske først, og resten senere, etter hvert som pull requests merges eller lukkes og døgnvinduet flytter seg. Den åpner aldri mer enn grensene.
• En lukket pull request forblir lukket. Lukker noen en pull request med en sikkerhetsrettelse uten å merge den, åpner fremforge den ikke igjen for de samme funnene og den samme målversjonen. Et nytt kvalifiserende funn på den pakken, eller en nyere målversjon, er en ny grunn og kan foreslås. En forespørsel som endte uten pull request (for eksempel Waiting for the release age), forsøkes på nytt etter 24 timer.

Forespørsler som lages automatisk, registreres som autofix.proposed med source: policy, aktøren system:autofix-policy og qualifiedBy (known_exploited, reachable, unknown eller severity).

Økosystemer og manifester

Ikke dekket ennå, og det står på funnet:

• Andre byggeverktøy for JVM (Ivy, sbt): funnet viser Manifest not covered.
• bun.lockb, Buns binære låsefil, som bare Bun kan skrive om. Kjør bun install --save-text-lockfile én gang for å bytte til bun.lock.
• Bun-pakker som manifestet ikke navngir: kjøringen ender med no change.
• pub-pakker som manifestet ikke navngir: kjøringen ender med no change.
• Funn fra en opplastet SBOM (manifest sbom:<name>): det finnes ingen fil i repositoryet å endre. Funnet viser From an SBOM.
• Conan (conan.lock): OSV, der avhengighetsskanningen henter sårbarhetsvarslene sine, publiserer ingen for Conan-pakker, så det finnes ingen Conan-sårbarhet å rette.

En pakke som bare er en transitiv avhengighet (i låsefilen, men ikke i et manifest), låses fra roten av prosjektet: en overrides-oppføring i npm, en <dependencyManagement>-oppføring i Maven eller // indirect-linjen i go.mod. Se Transitive avhengigheter.

Oppfrisking av låsefiler

Låsefilen oppfriskes av pakkebehandleren selv (uv lock, poetry lock, dotnet restore, cargo update, composer update --no-scripts --no-plugins, dart pub upgrade, bun install --ignore-scripts og så videre), uten at repositoryets egne skript eller plugins kjøres, som organisasjonens Renovate-bot, i den samme sandkassen for hostet Renovate som de vanlige oppdateringene. En oppfrisking flytter aldri pakker til en annen indeks: en låsefil for Python eller Cargo der pakkene etterpå ville komme fra en annen indeks, avvises. Mislykkes oppfriskingen, for eksempel fordi repositoryet navngir en privat indeks som boten ikke kan lese, lukkes pull requesten som PR closed: relock failed i stedet for å bli stående åpen med en utdatert låsefil.

Organisasjonens avhengighetsproxy som indeks. Når repositoryets manifester, låsefiler eller verktøykonfigurasjon navngir organisasjonens egen avhengighetsproxy (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...), autentiserer oppfriskingen seg der som Renovate-boten din. Dette gjelder alle Renovate-kjøringer for det repositoryet, ikke bare fremforge. Legitimasjonen gis for nøyaktig de proxystiene i organisasjonen din som repositoryet navngir, og for ingenting annet: en indeks for uv, Poetry eller Pipenv og en kilde i nuget.config får den via Renovates egen håndtering av legitimasjon, Cargo via en legitimasjonsleverandør som bare svarer for organisasjonens Cargo-proxy. (Et Gradle-bygg oppfriskes ikke her i det hele tatt; se Gradle.) Legitimasjonen ligger i filer for den ene kjøringen, aldri i repositoryet, aldri i miljøet og aldri i logger.

Gradle

fremforge kjører aldri bygget i repositoryet ditt. Å oppfriske en Gradle-låsefil betyr å kjøre Gradle-wrapperen og byggeskriptene dine, så for et Gradle-funn deles arbeidet:

1. fremforge endrer bare versjonen. Renovate redigerer build.gradle(.kts), versjonskatalogen eller gradle.properties, med de samme sjekkene for omfang og delte versjoner som for alle pull requests med sikkerhetsrettelser, og åpner pull requesten uten å røre låsefilene. Ingen Renovate-kjøring, verken fremforges eller den vanlige, kjører kode fra repositoryet.
2. Din egen CI oppfrisker låsefilene. Har bygget *.lockfile-filer eller gradle/verification-metadata.xml, committer fremforge en generert workflow, .forgejo/workflows/fremforge-autofix-relock.yaml, på en midlertidig branch autofix-relock/<request> (med [skip ci], så ingen av dine egne workflower kjører på den) og starter den én gang på organisasjonens hostede runner (runs-on: fremforge): en flyktig VM for den commiten. Den teller ikke mot organisasjonens CI-minutter: fremforge registrerer kjøringen den startet, og holder den utenfor forbruket og fakturaen din. Den tar likevel en av dine samtidige jobbplasser mens den kjører. Du trenger ikke å endre repositoryet ditt. Kjøringen vises i repositoryets Actions-fane.
3. Jobben kjører de samme kommandoene som Renovates Gradle-manager ville gjort: gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, og --write-verification-metadata når bygget verifiserer avhengigheter. Den velger en JDK fra runneren (21, ellers 17), sender runnerens utgående proxy videre til JVM-en og leser organisasjonens avhengighetsproxy med jobbens eget token via egenskapene fremforgeUsername og fremforgePassword. Den har ingen skrivelegitimasjon: tillatelsene er contents: read, packages: read og id-token: write.
4. fremforge sjekker og committer resultatet. Jobben sender de endrede låse- og verifiseringsfilene til fremforge med et jobbtoken for audiencen fremforge:autofix-relock, som fremforge bare godtar fra den ene kjøringen. fremforge avviser alt som ikke er en Gradle-låsefil eller verifiseringsfil for bygget som ble låst på nytt, en låsefil som fortsatt låser den sårbare versjonen, eller en branch som har endret seg i mellomtiden. Deretter legger den filene til i pull requesten med sikkerhetsrettelsen som én commit fra Renovate-boten din, så CI-en for pull requesten kjører på den, sjekker at pull requesten ikke endrer annet enn Gradle-byggefiler og låsefiler, og sletter den midlertidige branchen. Statusen fremforge/autofix-relock på pull requesten lenker til kjøringen.

Et bygg uten låsefiler får bare versjonsendringen, og ingen jobb kjører.

Hvis jobben mislykkes, blir avbrutt, ikke rapporterer eller ikke er ferdig 90 minutter etter at den startet (for eksempel når organisasjonens runner-minutter er brukt opp), lukkes pull requesten som PR lukket: ny låsing mislyktes med en lenke til kjøringen. Gå gjennom en Gradle-pull request etter at commiten med låsefilene har kommet; inntil da er låsefilene utdaterte. Med Merge når sjekkene går gjennom aktiveres ikke en Gradle-rettelse mens oppfriskingen av låsefilen venter eller committes; den aktiveres når commiten med låsefilen er på plass og sjekkene er grønne. Merger du den for hånd, venter du på commiten med låsefilen.

RubyGems, Hex, CRAN og Composer-pakker som composer.json ikke navngir

Bundler leser Gemfile og Mix leser mix.exs for å låse dem, og begge er kode (Ruby, Elixir), så fremforge kjører aldri Bundler eller Mix selv. Å oppdatere renv.lock krever R, som verken fremforge eller Renovate kjører. Renovate oppdaterer bare Composer-pakkene som composer.json navngir. For disse rettelsene oppdateres låsefilen i din egen CI, på samme måte som en oppfrisking for Gradle, og pull requesten åpnes først når den har kommet:

1. Din egen CI oppdaterer låsefilen. fremforge committer den genererte workflowen .forgejo/workflows/fremforge-autofix-relock.yaml på en midlertidig branch autofix-relock/<request> laget fra head av basebranchen (med [skip ci]), og starter den én gang på organisasjonens hostede runner, uten at den teller mot CI-minuttene dine. I låsefilens katalog kjører den bundle lock --update <gem> --conservative --patch|--minor|--major --strict (det laveste nivået som når rettelsen, med Ruby fra .ruby-version eller låsefilen og Bundler-versjonen som låsefilen ble skrevet med), mix deps.update <package> i det offisielle elixir-imaget (versjonen som .tool-versions navngir, ellers den gjeldende; runnerne dine har ikke Elixir), fremforges R-skript i rocker/r-ver-imaget med R-versjonen som renv.lock registrerer (se CRAN nedenfor), eller composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Ingenting installeres, og ingen skript fra gems eller pakker kjøres. Den har ingen skrivelegitimasjon. Mens den kjører, viser funnet Fix requested.
2. Utgivelsesalderen sjekkes i jobben. Med mindre rettelsen gjelder en kjent utnyttet sårbarhet, leser jobben publiseringstidspunktet for versjonen den låste, fra rubygems.org, hex.pm eller repo.packagist.org, eller for CRAN fra pakkens eget felt Date/Publication; en versjon som er yngre enn organisasjonens utgivelsesalder, avslutter forespørselen med No PR yet: too new, og den forsøkes på nytt etter 24 timer.
3. fremforge sjekker låsefilen og åpner pull requesten. Jobben sender den ene låsefilen tilbake med et jobbtoken for den ene kjøringen. fremforge avviser en låsefil der noe annet enn de låste versjonene har endret seg (kilder, plattformer, avhengigheter, Bundler-versjonen, Composers content-hash, en git- eller sti-avhengighet i mix.lock, i renv.lock alt annet enn pakkens egen post), en som ikke låser den rettede versjonen, eller en som fortsatt låser den sårbare versjonen. Deretter committer den filen som Renovate-boten din på branchen for sikkerhetsrettelsen, laget fra basebranchen, åpner pull requesten med vanlig tittel, beskrivelse og etiketter, og sletter den midlertidige branchen. Fra da av er det en vanlig pull request med sikkerhetsrettelse.

Hvis jobben mislykkes, blir avbrutt, ikke rapporterer eller ikke er ferdig 90 minutter etter at den startet, åpnes ingen pull request, og forespørselen ender med Ingen PR: oppdatering av låsefilen mislyktes, med årsaken og en lenke til kjøringen.

CRAN

En CRAN-rettelse flytter én post i renv.lock og ingenting annet. Jobben installerer den versjonen av renv som renv.lock ble skrevet med, så filen beholder formatet sitt, og leser DESCRIPTION for den rettede versjonen fra pakke-repositoryet som renv.lock navngir. Den installerer aldri prosjektet ditt eller kjører koden dets. Den avviser, og sier hvorfor, når:

• den rettede versjonen trenger en pakke (Depends, Imports eller LinkingTo) som renv.lock ikke låser, eller låser til en lavere versjon enn den som trengs;
• den rettede versjonen trenger en annen R-versjon enn den renv.lock registrerer;
• prosjektets DESCRIPTION begrenser pakken til under rettelsen, for eksempel Imports: commonmark (<= 1.8);
• den rettede versjonen er yngre enn organisasjonens utgivelsesalder.

I hvert av disse tilfellene oppdaterer du pakkene sammen med renv i prosjektet ditt (renv::update() og deretter renv::snapshot()). Ellers får posten den nye versjonen, avhengighetene og renvs hash, og fremforge godtar filen bare hvis alle andre poster, R-versjonen og repositoryene er uendret.

Delte versjoner

En versjon som holdes på ett sted og leses av flere avhengigheter, for eksempel en egenskap i pom.xml (<logback.version>), en Gradle-variabel i gradle.properties eller en oppføring i en versjonskatalog ([versions] logback = "1.5.12"), flytter alle disse avhengighetene når den oppgraderes. fremforge leser hver pom.xml, eller hver Gradle-byggefil og katalog, i pull requesten.

En egenskap i pom.xml oppgraderes når oppgraderingen er riktig for alle som leser den. Hver annen avhengighet som leser den, må ha åpne sårbarheter i repositoryet (på standardbranchen), være rettet på eller under den nye versjonen og være publisert i den versjonen på organisasjonens Maven-proxy. Pull requesten lister da disse avhengighetene under Also updated by this pull request og lukker funnene deres når den merges. Hvis to forespørsler om rettelser ville gjort den samme oppgraderingen, beholder forespørselen for pakken som sorteres først, den, og den andre ender med PR closed: shared version og navngir den.

Ellers, og alltid for en Gradle-variabel eller katalogoppføring, en rettelse på en utgivelsesbranch eller en versjon som leses på en måte som fremforge ikke kan knytte til en avhengighet, lukkes pull requesten som PR lukket: delt versjon, og forespørselens detail sier hvilken leser som ikke oppfylte hvilket vilkår (ingen åpen sårbarhet, ingen rettet versjon, trenger en høyere versjon, ikke publisert i den nye versjonen). Oppgrader i så fall den delte versjonen selv, så du velger versjonen for alle: rettelsen for den sårbare pakken finnes kanskje ikke som utgivelse av de andre (en bibliotekfamilie gir ofte ut en patch-versjon av bare én artefakt). En versjon som bare den sårbare pakken leser, oppgraderes som vanlig.

Rett alt som kan rettes i et repository

På Anbefalinger har hvert repository med to eller flere pakker som fremforge kan rette nå, en Fix all in this repository-knapp. Den ber om én pull request per pakke (og per base-image, se nedenfor), eller, i et repository som grupperer rettelsene sine, én per låsefil, kjent utnyttede først, deretter høyeste alvorlighetsgrad. Forespørslene slippes inn samlet innenfor grensene dine: når et repository har 3 åpne pull requests med sikkerhetsrettelser, eller organisasjonen har brukt sine 20 forespørsler for dagen, blir resten ikke forespurt, og resultatet sier hvor mange som ble det. En pakke som allerede har en forespørsel, hoppes over.

Med API-et: POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests med {"repo": "<name>"} svarer 202 med ett utfall per pakke (queued, eller refused med en reason), eller 200 når ingen ble lagt i kø.

Grupperte rettelser

I et repository som står under Grupperte repositoryer (grouped_repos), havner rettelsene for én låsefil i én pull request, som Dependabot-grupper, i stedet for én per pakke. Alle andre repositoryer beholder én pull request per pakke, og det gjør også alle repositoryer som standard.

• Hva som grupperes: pakker i én låsefil (ett økosystem, ett manifest, én basebranch) der rettelsen holder seg innenfor den installerte major-versjonen, i npm (med pnpm og Yarn), PyPI, Go, Cargo og NuGet. Høyst 20 pakker havner i én gruppe; flere gir en gruppe til.
• Hva som ikke grupperes: en rettelse som krever en ny major-versjon, et base-image, en låsing av en CI-action, og pakker for Gradle, Maven, Composer, RubyGems, Hex og CRAN. Hver av disse er sin egen pull request, som før.
• Når: Fix all in this repository og automatiske sikkerhetsrettelser. En enkelt Åpne PR med rettelse på ett funn er fortsatt én pull request for den pakken.
• Grenser: en gruppe teller som én pull request mot Open fix pull requests per repository og som én forespørsel mot Fix pull requests per day. En pakke som allerede har en egen forespørsel, eller som ble forsøkt de siste 10 minuttene, holdes utenfor gruppen i stedet for å gjentas.
• Hver pakke beholder sin egen forespørsel. Pull requesten lister hver pakke med den rettede versjonen, og funnene for hver pakke lukkes når den merges, som for en enkeltrettelse. En pakke som kjøringen ikke kunne oppdatere sammen med de andre, eller bare kunne oppdatere til en versjon under rettelsen (se Hver kopi, til rettelsen under Hva som skjer når du klikker Open fix PR), utelates og navngis på pull requesten. Den beholder sin egen forespørsel: en som venter på utgivelsesalderen, blir bedt om igjen senere, og en pakke som manifestet ikke navngir (en transitiv avhengighet), låses for seg selv av den transitive rettelsen. En utelatt pakke holder aldri gruppen tilbake.
• I konsollen viser Activity en gruppert pull request én gang, som Grouped · N packages med hver pakke og versjonen dens. I API-et har hver forespørsel i en gruppe den samme group_id (på POST .../requests med repo, og på GET .../requests).

Oppgradering av base-imager

For en sårbarhet i et image som er pushet til organisasjonens register, kan fremforge oppgradere imagets FROM-base i Dockerfilen som bygde det. Åpne PR med rettelse av base-image på funnet (under Sikkerhet › Funn › Containerimager) finnes når alt dette stemmer:

1. fremforge vet hvilket repository og hvilken commit som bygde imaget, på en av to måter:

   • imaget navngir dem, med OCI-etikettene org.opencontainers.image.source og org.opencontainers.image.revision (docker/metadata-action setter begge). Etikettene vinner når de finnes;
   • eller, uten slike etiketter, imaget ble pushet av en fremforge Actions-kjøring i et repository i organisasjonen din: fremforges register registrerer hvilken kjøring som pushet hvert manifest, og repositoryet og commiten er kjøringens. Hver push av imaget må komme fra Actions-kjøringer i det ene repositoryet; et image som også er pushet fra et annet sted (en bærbar PC, en annen CI), eller av en kjøring i et repository i en annen organisasjon, tilskrives ikke på denne måten.

   Funnet sier hvilket repository og hvilken Dockerfile som bygde imaget, og hvordan fremforge vet det («from its image labels» eller «from the Actions run that pushed it»), og det samme gjør API-et (base_attribution på hvert imagefunn).

2. fremforge fant Dockerfilen i den commiten som imaget er bygget på FROM-basen til: lagene i base-imaget er de første lagene i imaget ditt.

3. Trivy plasserer den sårbare pakken i et av disse baselagene, ikke i et lag som Dockerfilen din legger til.

4. Den nyeste basen i samme linje (samme major-versjon og tag-form, eller nyere digest for samme tag ved en flytende tag), skannet av fremforge med den samme sårbarhetsdatabasen, har den ikke lenger.

Denne analysen kjøres sammen med den daglige imageskanningen. Pull requesten endrer bare den FROM-linjen: taggen, og digesten som fremforge skannet for den. En endring på en annen linje eller i en annen fil, eller en annen digest enn den fremforge skannet, lukker den. Alle åpne funn i imaget som den samme basen retter, listes i én pull request.

Når det ikke finnes noen knapp, sier funnet hvorfor:

Når du har merget pull requesten og pushet det nybygde imaget under samme tag, sammenligner fremforge det nye imaget med det gamle når det nye er skannet. Hvert funn for den gamle digesten som det nye imaget ikke lenger har, lukkes som rettet av fremforge (fixed_source: security_fix), så lenge den gamle digesten ikke er i bruk: den har ingen tag lenger, den er ikke i den siste aktive utrullingen for et repository og et miljø, og ingen andre enn fremforges egne boter har pullet den etter digest de siste 7 dagene. Funnene for den gamle digesten blir stående oppført under den digesten så lenge imaget finnes i registeret ditt.

Er den gamle digesten fortsatt i bruk, lukkes ingenting: funnet viser Fixed in newer image med den nye digesten, og sier hvorfor det forblir åpent (har fortsatt tag, er fortsatt rullet ut, eller er pullet nylig). Det lukkes når den gamle digesten ikke lenger er i bruk, og gjenåpnes hvis den digesten tas i bruk igjen.

Etter merge

Når pull requesten er merget og neste skanning av standardbranchen ikke lenger rapporterer et funn, lukkes funnet. Historikken i samsvarsrapporten registrerer det som rettet av en sikkerhetsrettelse (fixed_source: security_fix; rader registrert før 2026-10-14 sa autofix). Et funn som lukkes av en av hostet Renovates egne pull requests for sikkerhet, registreres som fixed_source: renovate. Utbedringsmålinger teller begge.

Grenser

• Én aktiv forespørsel per (repository, pakke) på hver branch. En ny forespørsel for den samme pakken på den samme branchen svarer already requested. En rettelse til en beskyttet utgivelsesbranch er en egen forespørsel, atskilt fra standardbranchens.
• Høyst 3 åpne pull requests med sikkerhetsrettelser per repository, som standard; 0 til 10.
• Høyst 20 forespørsler per organisasjon innenfor et vilkårlig døgn, som standard; 0 til 50.
• En gruppert pull request teller som én mot begge.

De gjelder for klikk og automatiske sikkerhetsrettelser samlet. AI-rettelse har egne grenser. Når det ikke åpnes noen pull request, se Feilsøking.

API

• Be om en rettelse POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:write (findings:write godtas også). Brødteksten navngir nøyaktig ett av:

  • finding_id: ett avhengighetsfunn. Én pull request for pakken. Svarer 202 med forespørselens id, målversjonen, funnøklene den dekker, known_exploited_cves (id-ene til de kjent utnyttede CVE-ene den retter; tom hvis ingen) og automerge.
  • repo: alle pakker som kan rettes i det repositoryet, én pull request hver, eller én per låsefil i et gruppert repository. Svarer 202 med ett utfall per pakke (queued med group_id, null når den ikke er gruppert, eller refused med en reason), eller 200 når ingen ble lagt i kø.
  • image_finding_id: en oppgradering av base-image. Avvisninger omfatter image_not_from_base, image_no_base_fix, image_source_unknown og image_not_attributed.

  En avvisning er problem+json der type er security-fix-<reason>, og som har reason, for eksempel no_fixed_version, ecosystem_not_supported, manifest_not_supported eller sbom_finding. Hver av dem er beskrevet under API-feil.

• List forespørsler GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:read, med status og pull request for hver forespørsel.

• Innstillinger GET og PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings; se Innstillinger.

• Hvem åpner pull requests for sikkerhet GET og PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane; se Ta over fra Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates har security_fixes_bot, som er true når avhengighetsboten finnes for sikkerhetsrettelser. enrolled i samme svar betyr at versjonsoppdateringer er slått på.

• Tellere GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics: forespørsler, pull requests som er åpnet, merget og lukket, akseptrate, pull requests som er merget uten en godkjennende gjennomgang, og funn som er rettet av en sikkerhetsrettelse.

Hvert avhengighetsfunn som GET /_app/api/v1/orgs/{org}/code-security/deps/findings returnerer, har autofix_eligible, autofix_unavailable_reason (hvorfor et funn med en rettelse ikke er dekket) og autofix, den nyeste forespørselen som dekker det. Hvert imagefunn fra GET .../code-security/images/findings har de samme tre feltene for oppgradering av base-imager.

curl -X POST -H "Authorization: Bearer ${FREMFORGE_PAT}" -H "Content-Type: application/json" \
  -d "{\"finding_id\": \"${FINDING_ID}\"}" \
  "https://frem.sh/_app/api/v1/orgs/acme/dependency-updates/security-fixes/requests"

Utfaset API

Disse stiene, feltene og scopene fortsetter å virke til 2027-10-15. Frem til da har hvert svar fra en utfaset sti Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT og en Link-header med rel="successor-version" som navngir etterfølgeren.

Ta over fra Renovate

Inntil en organisasjon bytter, betjenes den av hostet Renovates egne pull requests for sårbarhetsvarsler ved siden av dette sporet (lane_owner: renovate). Når sporet for sikkerhetsrettelser tar over (lane_owner: security_lane), åpner Renovate bare versjonsoppdateringer, så hver rettelse foreslås én gang. Åpne pull requests for sikkerhet fra Renovate lukkes, med en kommentar som lenker til pull requesten som erstatter dem, når dette sporet har en pull request med rettelse for hver pakke de oppgraderer; inntil da forblir de åpne.

For kunder gjøres byttet foreløpig på forespørsel: kontakt support. fremforge bytter selv for sine egne organisasjoner. API-et er PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane med {"lane_owner": "security_lane"} (eller "renovate" for å bytte tilbake), scope dependency-updates:write; GET på samme sti svarer med gjeldende verdi, og i tillegg unsupported_ecosystems (et objekt fra økosystem til antall åpne funn som kan rettes, men som sporet ikke retter) og unsupported_total, så du kan se på forhånd om et bytte ville blitt avvist. Overtakelsen avvises med mindre sporet kan handle:

• Sikkerhetsrettelser er Off: 409 security-lane-lane-off. Velg først en annen modus enn Off, eller send "acknowledge": ["no_security_prs"] for å godta at ingen pull requests for sikkerhet åpnes i det hele tatt.
• Åpne funn i økosystemer som sporet ikke retter (for eksempel CRAN eller Conan, som Renovates varsler dekker): 409 security-lane-unsupported-ecosystems, der unsupported_ecosystems lister de åpne funnene som kan rettes, per økosystem. Send "acknowledge": ["unsupported_ecosystems"] for å bytte likevel; disse funnene får da ingen automatisk pull request.

Ved byttet begynner pull requests med sikkerhetsrettelser å følge Når rettelser merges i organisasjoner der de til da ventet på gjennomgang; se Merging.

Byttet registreres i revisjonsloggen som dependency-updates.security-lane.enabled, og å bytte tilbake som dependency-updates.security-lane.disabled.

Revisjon

Hvert trinn står i revisjonsloggen: autofix.proposed, autofix.pr_opened, autofix.rejected (med årsaken), autofix.relocked (en låsefil-commit fra din egen CI, med kjøringen), autofix.relock_refused (et jobbtoken som ikke var fra den startede kjøringen), autofix.merged og autofix.closed, hver med funnøklene og engine: deterministic. autofix.proposed for en kjent utnyttet rettelse har også knownExploitedCves. En endring av innstillingene er dependency-updates.security-fixes.updated.

AI-rettelser for SAST-funn

AI-genererte rettelser for SAST-funn er flyttet til en egen side: AI-rettelse.

Se også

• Avhengighetsoppdateringer: begge sporene og boten.
• Merging: gjennomgang, merge når grønt, merge-vinduet og utgivelsesfrysen.
• Feilsøking: når det ikke åpnes noen pull request.
• OSV-anbefalinger: kortene som Åpne PR med rettelse-knappen står på.
• Sjekkliste for oppsett: grensene og tilvalgene dine samlet på Sikkerhet › Oversikt.