Säkerhetsfixar

En säkerhetsfix gör om ett beroendefynd till en pull request. Klicka på Öppna fix-PR på ett fynd eller på ett kort under Rekommendationer, eller anropa API:t, så öppnar din organisations beroendebot en pull request i det repot. Den uppgraderar paketet till den lägsta släppta version som åtgärdar alla öppna säkerhetsmeddelanden för det. Det här är spåret Säkerhetsfixar i Uppdateringar av beroenden, under Säkerhet › Åtgärda › Uppdateringar av beroenden.

Säkerhetsfixar omfattar beroenden i npm (inklusive Yarn, pnpm och Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex och CRAN (R) samt versioner av CI-actions (GitHub Actions), i de manifest som listas under Ekosystem och manifest. Andra ekosystem svarar stöds inte än. Hela listan finns under Ekosystem som stöds. Ingen AI-modell är inblandad: uppgraderingen beräknas från OSV:s poster för säkerhetsmeddelanden.

För en sårbarhet i en image som pushats till ditt registry och som följde med imagens FROM-bas uppgraderar Öppna fix-PR för basimage den basen, när fremforge har kontrollerat att den nyare basen inte längre har sårbarheten. Se Uppgraderingar av bas-images. Åtgärda alla i detta repo begär alla åtgärdbara paket i ett repo på en gång: se Åtgärda alla åtgärdbara i ett repo.

Säkerhetsfixar hette AutoFix fram till 2026-10-14. AutoFix är inte längre ett produktnamn: AI-genererade fixar för SAST-fynd är AI-fix. Granskningshändelserna autofix.* och de utfasade API-sökvägarna har fortfarande det gamla namnet. Pull requests som öppnades före bytet behåller sin branch autofix/; fremforge lägger till etiketten security-fix på de som fortfarande är öppna.

Inställningar

En ägare ställer in dessa under Säkerhet › Åtgärda › Uppdateringar av beroenden › Säkerhetsfixar, eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Alla fält är valfria i en PUT; ett fält som utelämnas behåller sitt värde, och ingenting sparas om något fält nekas.

Lägena:

• Av (off): inga pull requests för säkerhetsfixar, varken vid klick eller automatiskt.
• Vid klick (on_click): en person begär, med Öppna fix-PR, Åtgärda alla i detta repo eller Öppna fix-PR för basimage, eller via API:t.
• Automatiskt för viktiga fynd (auto_important): som vid klick, och fremforge öppnar dem också självt för höga och kritiska fynd som är nåbara eller kända som utnyttjade. Med Ta också med fynd vars nåbarhet är okänd påslaget räknas också höga och kritiska fynd utan nåbarhetsbedömning. Se Automatiska säkerhetsfixar.
• Automatiskt för alla höga och kritiska (auto_high_critical): fremforge öppnar dem självt för varje högt och kritiskt fynd som det kan åtgärda, oavsett nåbarhet.
• Automatiskt för kritiska och kända som utnyttjade (auto_critical_exploited): fremforge öppnar dem självt för varje kritiskt fynd, oavsett nåbarhet, och för varje känt utnyttjat fynd oavsett allvarlighetsgrad. Ett högt, medelallvarligt eller lågt fynd som inte är känt som utnyttjat väntar på ett klick. Det här är standard för en organisation som skapats 2026-10-27 eller senare; se Nya organisationer.

Svaret innehåller också skrivskyddade fält. configured är false så länge organisationen aldrig har sparat inställningarna och värdena är standardvärdena (för en ny organisation, de standardvärden den skapades med). lane_owner anger vem som öppnar säkerhets-pull requests: renovate så länge hostad Renovates egna säkerhets-pull requests fortfarande betjänar organisationen, security_lane när det här spåret har tagit över. high_blast_radius_exempt är true för organisationer vars Renovate-säkerhets-pull requests mergade sig själva före 2026-10-14 och flyttades till Sammanfoga när kontrollerna går igenom; se Merge.

En ändring registreras i granskningsloggen som dependency-updates.security-fixes.updated, med varje fälts gamla och nya värde.

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"

Säkerhetsfixar kräver inte Versionsuppdateringar. Den första fix-begäran (Öppna fix-PR, Åtgärda alla i detta repo, Öppna fix-PR för basimage eller POST .../security-fixes/requests), eller att du sparar ett automatiskt läge, skapar organisationens beroendebot <org>-fremforge-bot-deps med Versionsuppdateringar avstängt. Ett repo som har valts bort från uppdateringar av beroenden får inga fix-pull requests, och ett arkiverat repo eller ett spegelrepo nekas (repo_archived).

Vad som händer när du klickar på Öppna fix-PR

1. fremforge samlar alla öppna fynd på standardbranchen för samma paket i samma repo. En pull request stänger alla.
2. Det beräknar målversionen. För varje installerad version är det den lägsta släppta version som ligger utanför varje påverkat intervall i varje öppet säkerhetsmeddelande. Pull requesten tar den högsta av dem, så att den åtgärdar hela gruppen.
3. En riktad körning av hostad Renovate startar, som organisationens beroendebot. Den begränsas till just det paketet och just den versionen. Alla andra beroenden lämnas orörda.
4. Renovate öppnar pull requesten på en branch security-fix/<package>-<version>. Körningar för säkerhetsfixar går före vanliga Renovate-körningar, så det tar oftast under 15 minuter. Pull requesten får etiketten security-fix. Om repot inte har den etiketten än skapar fremforge den före körningen, en gång; en etikett som redan finns lämnas som den är. Om en etikett inte kan skapas öppnas pull requesten utan den.
5. fremforge kontrollerar pull requesten innan den hålls öppen. Den får bara ändra ekosystemets manifest och låsfiler (se tabellen nedan), och i ett manifest bara det paketets post. En ändring i någon annan fil, ett nytt direkt beroende, en uppgradering av ett annat paket, en delad version eller en låsfil vars paket nu kommer från ett annat index stänger pull requesten och tar bort dess branch. Det gör också en misslyckad uppdatering av låsfilen: en pull request med en inaktuell låsfil skulle inte gå att bygga.

Fyndet visar sedan Åtgärd föreslagen: #N med pull requestens status: öppen, mergad eller stängd.

Varje kopia, vid fixen. En låsfil kan innehålla flera kopior av ett paket: en direkt, och äldre som ligger under andra beroenden. Innan en pull request räknas som en fix läser fremforge dess låsfiler i pull requestens head och kontrollerar varje kopia av paketet som de registrerar mot den åtgärdade versionen. Det gäller package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock, Cargo.lock, go.mod och NuGets packages.lock.json, för både enskilda och samlade fixar. En förhandsversion av den åtgärdade versionen räknas som lägre än den.

• Varje kopia på eller över fixen: pull requesten åtgärdar paketet.
• Vissa kopior åtgärdade, en äldre kvar: pull requesten förblir öppen, och konsolen anger de kopior som är kvar (i API:t begärans lock_copies_left, med reason target_partly_reached). Åtgärd föreslagen visas bara på fynden för de kopior den åtgärdar; de andra behåller sin knapp Åtgärd.
• Ingen kopia vid fixen, till exempel en transitiv kopia som följde med sin förälder men till en version som fortfarande är sårbar: paketet ingår inte i pull requesten. Dess begäran avslutas som target_not_reached, och den transitiva fixen låser det separat. En pull request som inte har något åtgärdat paket kvar stängs.

Ett låsfilsformat som inte listas här kontrolleras som tidigare: pull requesten måste ändra paketet i låsfilen.

Vad den här kontrollen inte gör:

• Bara de låsfiler som pull requesten ändrar läses. Om en annan låsfil i repot, en som pull requesten lämnar orörd, fortfarande innehåller en sårbar version, förblir det fyndet öppet efter merge. Det påstås inte vara åtgärdat: dess knapp Åtgärd finns kvar.
• En kopia som lämnas kvar åtgärdas efter merge, inte samtidigt. Medan pull requesten är öppen nekas en ny begäran för samma paket eftersom en redan är öppen, så Åtgärd på en kopia som pull requesten lämnar kvar startar ingenting än. Begär det igen efter merge och nästa skanning.
• Samma version, direkt och nästlad. Ett fynd identifieras av paket och version, inte av var i trädet kopian ligger. Om pull requesten flyttar den direkta kopian men samma gamla version fortfarande ligger under ett annat beroende är det fyndet inte åtgärdat, så begäran avslutas som target_not_reached och dess pull request stängs. Den transitiva fixen nekar ett paket som ditt manifest anger direkt, så lås den nästlade kopian själv (till exempel med en overrides-post i npm).

Ditt repos Renovate-inställningar

Ett repos egen renovate.json (eller .renovaterc, eller nyckeln renovate i package.json) formar dess versionsuppdateringar. Den håller inte tillbaka en säkerhetsfix. En körning för säkerhetsfix ignorerar repots:

• packageRules, inklusive en regel med "enabled": false för paketet;
• ignoreDeps;
• ignorePaths och includePaths. Bara node_modules och bower_components hoppas över;
• enabledManagers. Körningen använder managers för fyndets ekosystem.

För att hålla ett paket utanför säkerhetsfixar registrerar du ett undantag för dess fynd: avfärda dem med en motivering och helst ett utgångsdatum, eller begär ett godkänt undantag. Ett fynd med ett undantag är inte öppet, så ingen fix-begäran görs för det, och Öppna fix-PR svarar security-fix-not-open. Till skillnad från en spärregel i en fil syns ett undantag på sidan Undantag, anger vem som gjorde det och varför, och upphör vid sitt utgångsdatum.

Två inställningar gäller fortfarande:

• En "enabled": false på översta nivån i renovate.json stänger av Renovate för hela repot, säkerhetsfixar inräknade.
• Ett repos packageRules som sätter registryUrls eller andra uppslagsinställningar gäller inte för en körning för säkerhetsfix. Körningen slår upp paket via organisationens egna inställningar och beroendeproxyn.

Kända utnyttjade sårbarheter först

När ett säkerhetsmeddelande som en begäran åtgärdar har en CVE som listas som utnyttjad i praktiken, av ENISA:s EU Vulnerability Database (EUVD) eller CISA:s Known Exploited Vulnerabilities catalogue (KEV), behandlas fixen som den mest brådskande:

• Den körs först. Dess Renovate-körning tas före alla andra köade begäranden om säkerhetsfixar, oavsett i vilken ordning de begärdes.
• Den är först i Åtgärda alla. En omgång med Åtgärda alla i detta repo släpper in kända utnyttjade paket före de andra, sedan efter allvarlighetsgrad, så när en gräns nås är det ett mindre brådskande paket som lämnas utanför.
• Den väntar inte på versionsåldern. Din Versionsålder håller tillbaka andra fixar, men en version som åtgärdar en känd utnyttjad sårbarhet föreslås direkt.
• Pull requesten säger det. Titeln slutar med known exploited, till exempel fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), beskrivningen börjar med CVE:erna och de listor som anger dem, och pull requesten får också etiketten known-exploited, som skapas på samma sätt som security-fix.

En CVE räknas när den är säkerhetsmeddelandets eget id eller ett av dess alias (ett GHSA- eller PYSEC-meddelande har oftast ett CVE-alias). Båda listorna speglas och uppdateras dagligen. Om en begäran gäller en känd utnyttjad sårbarhet avgörs när den görs; API:t svarar med det som known_exploited_cves. Med Sammanfoga när kontrollerna går igenom aktiveras den även utanför ditt merge-fönster; se Merge. Gränserna gäller fortfarande.

Automatiska säkerhetsfixar

Med Automatiskt för viktiga fynd, Automatiskt för alla höga och kritiska eller Automatiskt för kritiska och kända som utnyttjade öppnar fremforge samma pull requests som ett klick på Öppna fix-PR eller Öppna fix-PR för basimage, utan att någon klickar, för varje fynd som uppfyller allt detta:

1. Det är öppet på standardbranchen: inte avfärdat, inte upptaget på en pull request.
2. Dess allvarlighetsgrad är hög eller kritisk. Medelallvarliga och låga fynd åtgärdas automatiskt bara med Automatiskt för kritiska och kända som utnyttjade, och bara när de är kända som utnyttjade.
3. Med Automatiskt för viktiga fynd: det är nåbart (dess nåbarhetsbedömning är reachable) eller känt som utnyttjat (en av dess CVE:er listas av ENISA EUVD eller CISA KEV), eller, med Ta också med fynd vars nåbarhet är okänd påslaget, saknar det bedömning eller har en okänd. Ett känt utnyttjat fynd kvalificerar även när det inte är nåbart. Med Automatiskt för alla höga och kritiska kvalificerar varje högt och kritiskt fynd. Med Automatiskt för kritiska och kända som utnyttjade kvalificerar ett kritiskt fynd oavsett nåbarhet, ett känt utnyttjat fynd oavsett allvarlighetsgrad, och inget annat.
4. fremforge kan åtgärda det deterministiskt: ett beroende i ett ekosystem och manifest som omfattas och har en släppt fix, eller ett image-fynd som en uppgradering av bas-image åtgärdar.

För att prova på några repon först listar du dem under Repon. En tom lista omfattar alla organisationens repon. Säkerhetsexemplets repo åtgärdas aldrig automatiskt; ett klick på Öppna fix-PR fungerar fortfarande där.

Nya organisationer

En organisation som skapats 2026-10-27 eller senare börjar med Automatiskt för kritiska och kända som utnyttjade, och När fixar mergas satt till Vänta på granskning: fix-pull requests öppnas av sig själva, och ingen mergas utan en person. Gränserna, gruppering och versionsålder behåller sina standardvärden. Ingenting registreras i Versionsuppdateringar: beroendeboten <org>-fremforge-bot-deps skapas först när det första fyndet kvalificerar. En ägare kan när som helst byta till vilket annat läge som helst, inklusive Av, eller bredda det. Organisationer som skapats före 2026-10-27 behåller den inställning de hade.

När det agerar

fremforge kontrollerar var tionde minut. Ett fynd föreslås kort efter att det kvalificerar: när en skanning rapporterar ett nytt fynd, när dess bedömning blir nåbar, eller när den dagliga uppdateringen av kända utnyttjade sårbarheter lägger till en av dess CVE:er. Fynd som redan kvalificerar när du slår på det tas också med, inom gränserna.

Vad som förblir detsamma

Varje automatisk begäran går exakt samma väg som ett klick: en pull request per paket (eller per bas-image), den lägsta åtgärdande versionen, organisationens gränser, väntan på versionsålder, nekandet av delade versioner och omfångskontrollerna. I listan över begäranden har en sådan begäran "trigger": "policy", och dess pull request anger att den öppnades automatiskt.

• Den mergas som du har ställt in. Som varje pull request för säkerhetsfix följer den När fixar mergas; se Merge.
• Den använder aldrig AI. Bara den deterministiska motorn körs automatiskt. AI-fix börjar alltid med att en person klickar på ett fynd.
• En topp får vänta på sin tur. När listan över kända utnyttjade sårbarheter lägger till en CVE som många av dina repon har, öppnar fremforge så många som dina gränser tillåter, kända som utnyttjade och kritiska först, och resten senare, i takt med att pull requests mergas eller stängs och 24-timmarsfönstret flyttas. Den öppnar aldrig fler än gränserna tillåter.
• En stängd pull request förblir stängd. Om någon stänger en pull request för säkerhetsfix utan att merga den öppnar fremforge den inte igen för samma fynd och samma målversion. Ett nytt kvalificerande fynd för det paketet, eller en nyare målversion, är ett nytt skäl och kan föreslås. En begäran som avslutades utan pull request (till exempel Väntar på release-åldern) provas igen efter 24 timmar.

Begäranden som görs automatiskt registreras som autofix.proposed med source: policy, aktören system:autofix-policy och qualifiedBy (known_exploited, reachable, unknown eller severity).

Ekosystem och manifest

Omfattas inte än, och det sägs på fyndet:

• Andra byggverktyg för JVM (Ivy, sbt): fyndet visar Manifestet täcks inte.
• bun.lockb, Buns binära låsfil, som bara Bun kan skriva om. Kör bun install --save-text-lockfile en gång för att byta till bun.lock.
• Bun-paket som manifestet inte anger: körningen avslutas med ingen ändring.
• pub-paket som manifestet inte anger: körningen avslutas med ingen ändring.
• Fynd från en uppladdad SBOM (manifest sbom:<name>): det finns ingen fil i repot att ändra. Fyndet visar Från en SBOM.
• Conan (conan.lock): OSV, där beroendeskanningen läser sina säkerhetsmeddelanden, publicerar inga för Conan-paket, så det finns ingen Conan-sårbarhet att åtgärda.

Ett paket som bara är ett transitivt beroende (i låsfilen, men inte i ett manifest) låses från projektets rot: en overrides-post i npm, en <dependencyManagement>-post i Maven, eller raden // indirect i go.mod. Se Transitiva beroenden.

Uppdatering av låsfiler

Låsfilen uppdateras av pakethanteraren själv (uv lock, poetry lock, dotnet restore, cargo update, composer update --no-scripts --no-plugins, dart pub upgrade, bun install --ignore-scripts och så vidare), utan att repots egna skript eller plugins körs, som organisationens Renovate-bot, i samma sandlåda för hostad Renovate som dess vanliga uppdateringar. En uppdatering flyttar aldrig paket till ett annat index: en låsfil för Python eller Cargo vars paket efteråt skulle komma från ett annat index nekas. Om uppdateringen misslyckas, till exempel för att repot anger ett privat index som boten inte kan läsa, stängs pull requesten som PR stängd: låsfilen misslyckades i stället för att lämnas öppen med en inaktuell låsfil.

Organisationens beroendeproxy som index. När repots manifest, låsfiler eller verktygskonfiguration anger organisationens egen beroendeproxy (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...) autentiserar uppdateringen sig där som din Renovate-bot. Det gäller varje Renovate-körning i det repot, inte bara fremforges. Inloggningsuppgiften ges för exakt de sökvägar i organisationens proxy som repot anger, och för inget annat: ett index för uv, Poetry eller Pipenv och en källa i nuget.config får den via Renovates egen hantering av inloggningsuppgifter, Cargo via en credential provider som bara svarar för organisationens Cargo-proxy. (Ett Gradle-bygge uppdateras inte alls här; se Gradle.) Inloggningsuppgiften finns i filer för just den körningen, aldrig i repot, aldrig i miljön och aldrig i loggar.

Gradle

fremforge kör aldrig ditt repos bygge. Att uppdatera en Gradle-låsfil innebär att köra din Gradle wrapper och dina byggskript, så för ett Gradle-fynd delas arbetet upp:

1. fremforge ändrar bara versionen. Renovate redigerar build.gradle(.kts), versionskatalogen eller gradle.properties, med samma omfångskontroller och kontroller av delade versioner som för varje pull request för säkerhetsfix, och öppnar pull requesten utan att röra låsfilerna. Ingen Renovate-körning, varken fremforges eller vanlig, kör kod från repot.
2. Din egen CI uppdaterar låsfilerna. Om bygget har *.lockfile-filer eller gradle/verification-metadata.xml committar fremforge ett genererat arbetsflöde, .forgejo/workflows/fremforge-autofix-relock.yaml, på en tillfällig branch autofix-relock/<request> (med [skip ci], så att inget av dina egna arbetsflöden körs på den) och startar det en gång på organisationens hostade runner (runs-on: fremforge): en tillfällig VM för den commiten. Det räknas inte mot organisationens CI-minuter: fremforge registrerar körningen det startade och utelämnar den från din användning och faktura. Den tar dock en av dina samtidiga jobbplatser medan den körs. Du behöver inte ändra ditt repo. Körningen syns på repots flik Actions.
3. Jobbet kör samma kommandon som Renovates Gradle-manager skulle: gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, och --write-verification-metadata när bygget verifierar beroenden. Det väljer en JDK från runnern (21, annars 17), skickar runnerns utgående proxy till JVM:en och läser organisationens beroendeproxy med jobbets egen token via egenskaperna fremforgeUsername och fremforgePassword. Det har ingen inloggningsuppgift med skrivbehörighet: dess behörigheter är contents: read, packages: read och id-token: write.
4. fremforge kontrollerar och committar resultatet. Jobbet skickar de ändrade lås- och verifieringsfilerna till fremforge med en jobbtoken för audience fremforge:autofix-relock, som fremforge bara accepterar från just den körningen. fremforge nekar allt som inte är en Gradle-lås- eller verifieringsfil för det låsta bygget, en låsfil som fortfarande låser den sårbara versionen, eller en branch som har ändrats under tiden. Sedan lägger det till filerna i pull requesten för säkerhetsfix som en commit av din Renovate-bot, så att din pull request-CI körs på den, kontrollerar att pull requesten inte ändrar något annat än Gradle-byggfiler och låsfiler, och tar bort den tillfälliga branchen. Statusen fremforge/autofix-relock på pull requesten länkar till körningen.

Ett bygge utan låsfiler får bara versionsändringen, och inget jobb körs.

Om jobbet misslyckas, avbryts, inte rapporterar eller inte är klart 90 minuter efter att det startades (till exempel när organisationens runner-minuter är slut) stängs pull requesten som PR stängd: låsfilen misslyckades med en länk till körningen. Granska en Gradle-pull request efter att låsfilscommiten har kommit; fram till dess är dess låsfiler inaktuella. Med Sammanfoga när kontrollerna går igenom aktiveras inte en Gradle-fix medan uppdateringen av dess låsfil väntar eller committas; den aktiveras när låsfilscommiten har landat och dess kontroller går igenom. Om du mergar den för hand, vänta på låsfilscommiten.

RubyGems, Hex, CRAN och Composer-paket som composer.json inte anger

Bundler läser Gemfile och Mix läser mix.exs för att låsa dem, och båda är kod (Ruby, Elixir), så fremforge kör aldrig Bundler eller Mix självt. Att uppdatera renv.lock kräver R, som varken fremforge eller Renovate kör. Renovate uppdaterar bara de Composer-paket som composer.json anger. För de här fixarna uppdateras låsfilen i din egen CI, på samma sätt som en uppdatering för Gradle, och pull requesten öppnas först när den har kommit:

1. Din egen CI uppdaterar låsfilen. fremforge committar det genererade arbetsflödet .forgejo/workflows/fremforge-autofix-relock.yaml på en tillfällig branch autofix-relock/<request> som skapas från basbranchens head (med [skip ci]), och startar det en gång på organisationens hostade runner, utan att räkna det mot dina CI-minuter. I låsfilens katalog kör det bundle lock --update <gem> --conservative --patch|--minor|--major --strict (den minsta nivå som når fixen, med Ruby från .ruby-version eller låsfilen och den Bundler-version som låsfilen skrevs med), mix deps.update <package> i den officiella imagen elixir (den version som din .tool-versions anger, annars den aktuella; dina runners har ingen Elixir), fremforges R-skript i imagen rocker/r-ver med den R-version som renv.lock registrerar (se CRAN nedan), eller composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Ingenting installeras och inget gem- eller paketskript körs. Det har ingen inloggningsuppgift med skrivbehörighet. Medan det körs visar fyndet Åtgärd beställd.
2. Versionsåldern kontrolleras i jobbet. Om inte fixen gäller en känd utnyttjad sårbarhet läser jobbet publiceringstiden för den version det låste från rubygems.org, hex.pm eller repo.packagist.org, eller, för CRAN, från paketets eget fält Date/Publication; en version som är yngre än organisationens versionsålder avslutar begäran med Ingen PR än: för ny, och den provas igen efter 24 timmar.
3. fremforge kontrollerar låsfilen och öppnar pull requesten. Jobbet skickar tillbaka den enda låsfilen med en jobbtoken för just den körningen. fremforge nekar en låsfil där något annat än de låsta versionerna har ändrats (källor, plattformar, beroenden, Bundler-versionen, Composers content-hash, ett git- eller sökvägsberoende i mix.lock, i renv.lock allt utom paketets egen post), en som inte låser den åtgärdade versionen, eller en som fortfarande låser den sårbara versionen. Sedan committar det filen som din Renovate-bot på branchen för säkerhetsfixen, som skapats från basbranchen, öppnar pull requesten med den vanliga titeln, beskrivningen och etiketterna, och tar bort den tillfälliga branchen. Från och med då är det en vanlig pull request för säkerhetsfix.

Om jobbet misslyckas, avbryts, inte rapporterar eller inte är klart 90 minuter efter att det startades, öppnas ingen pull request och begäran avslutas med Ingen PR: låsfilen kunde inte uppdateras, med orsaken och en länk till körningen.

CRAN

En CRAN-fix flyttar en post i renv.lock och ingenting annat. Jobbet installerar den version av renv som renv.lock skrevs med, så att filen behåller sitt format, och läser den åtgärdade versionens DESCRIPTION från det paketrepo som renv.lock anger. Det installerar aldrig ditt projekt eller kör dess kod. Det nekar, och säger varför, när:

• den åtgärdade versionen behöver ett paket (Depends, Imports eller LinkingTo) som renv.lock inte låser, eller låser under den version som behövs;
• den åtgärdade versionen behöver en annan R-version än den som renv.lock registrerar;
• ditt projekts DESCRIPTION begränsar paketet till under fixen, till exempel Imports: commonmark (<= 1.8);
• den åtgärdade versionen är yngre än organisationens versionsålder.

I vart och ett av dessa fall uppdaterar du paketen tillsammans med renv i ditt projekt (renv::update() och sedan renv::snapshot()). Annars får posten den nya versionen, dess beroenden och renvs hash, och fremforge accepterar filen bara om alla andra poster, R-versionen och repona är oförändrade.

Delade versioner

En version som hålls på ett ställe och läses av flera beroenden, till exempel en egenskap i pom.xml (<logback.version>), en Gradle-variabel i gradle.properties eller en post i en versionskatalog ([versions] logback = "1.5.12"), flyttar alla de beroendena när den uppgraderas. fremforge läser varje pom.xml, eller varje Gradle-byggfil och katalog, i pull requesten.

En egenskap i pom.xml uppgraderas när uppgraderingen är rätt för varje läsare. Varje annat beroende som läser den måste ha öppna sårbarheter i repot (på standardbranchen), vara åtgärdat vid eller under den nya versionen, och vara publicerat i den versionen i organisationens Maven-proxy. Pull requesten listar då de beroendena under Also updated by this pull request och stänger deras fynd när den mergas. Om två fix-begäranden skulle göra samma uppgradering behåller den för paketet som sorteras först den, och den andra avslutas med PR stängd: delad version och anger den.

Annars, och alltid för en Gradle-variabel eller katalogpost, en fix på en release-branch eller en version som läses på ett sätt som fremforge inte kan knyta till ett beroende, stängs pull requesten som PR stängd: delad version, och begärans detail anger vilken läsare som inte uppfyllde vilket villkor (ingen öppen sårbarhet, ingen åtgärdad version, behöver en högre version, inte publicerad i den nya versionen). Uppgradera då den delade versionen själv, så att du väljer versionen för alla: det sårbara paketets fix kanske inte finns som release för de andra (en biblioteksfamilj levererar ofta en patch-release av bara en artefakt). En version som bara det sårbara paketet läser uppgraderas som vanligt.

Åtgärda alla åtgärdbara i ett repo

Under Rekommendationer har varje repo med två eller fler paket som fremforge kan åtgärda nu en knapp Åtgärda alla i detta repo. Den begär en pull request per paket (och per bas-image, nedan), eller, i ett repo som samlar sina fixar, en per låsfil, kända som utnyttjade först, sedan högsta allvarlighetsgrad. Begärandena släpps in tillsammans under dina gränser: när ett repo har 3 öppna pull requests för säkerhetsfixar, eller organisationen har använt sina 20 begäranden för dagen, begärs inte resten, och resultatet anger hur många som begärdes. Ett paket som redan har en begäran hoppas över.

Med API:t: POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests med {"repo": "<name>"} svarar 202 med ett utfall per paket (queued, eller refused med en reason), eller 200 när inget köades.

Samlade fixar

I ett repo som listas under Samlade repon (grouped_repos) hamnar fixarna för en låsfil i en pull request, som Dependabots grupper, i stället för en per paket. Alla andra repon behåller en pull request per paket, och det gör också alla repon som standard.

• Vad som samlas: paket i en låsfil (ett ekosystem, ett manifest, en basbranch) vars fix stannar inom den installerade major-versionen, i npm (med pnpm och Yarn), PyPI, Go, Cargo och NuGet. Högst 20 paket hamnar i en grupp; fler ger en andra.
• Vad som inte samlas: en fix som kräver en ny major-version, en bas-image, en låsning av en CI-action, samt paket i Gradle, Maven, Composer, RubyGems, Hex och CRAN. Var och en av dem blir en egen pull request, som tidigare.
• När: Åtgärda alla i detta repo och automatiska säkerhetsfixar. En enskild Öppna fix-PR på ett fynd är fortfarande en pull request för det paketet.
• Gränser: en grupp räknas som en pull request mot Öppna fix-pull requests per repo och som en begäran mot Fix-pull requests per dag. Ett paket som redan har en egen begäran, eller som provades de senaste 10 minuterna, lämnas utanför gruppen i stället för att upprepas.
• Varje paket behåller sin egen begäran. Pull requesten listar varje paket med dess åtgärdade version, och vart och ett pakets fynd stängs när den mergas, som för en enskild fix. Ett paket som körningen inte kunde uppdatera tillsammans med de andra, eller bara kunde uppdatera till en version under fixen (se Varje kopia, vid fixen under Vad som händer när du klickar på Öppna fix-PR), lämnas utanför och anges på pull requesten. Det behåller sin egen begäran: ett som väntar på sin versionsålder begärs igen senare, och ett paket som manifestet inte anger (ett transitivt beroende) låses separat av den transitiva fixen. Ett paket som lämnas utanför håller aldrig tillbaka gruppen.
• I konsolen visar Aktivitet en samlad pull request en gång, som Samlad · N paket med varje paket och dess version. I API:t har varje begäran i en grupp samma group_id (på POST .../requests med repo, och på GET .../requests).

Uppgraderingar av bas-images

För en sårbarhet i en image som pushats till organisationens registry kan fremforge uppgradera imagens FROM-bas i den Dockerfile som byggde den. Öppna fix-PR för basimage på fyndet (under Säkerhet › Fynd › Container-images) finns när allt detta gäller:

1. fremforge vet vilket repo och vilken commit som byggde imagen, på ett av två sätt:

   • imagen anger dem, med OCI-etiketterna org.opencontainers.image.source och org.opencontainers.image.revision (docker/metadata-action sätter båda). Etiketterna har företräde när de finns;
   • eller, utan sådana etiketter, imagen pushades av en fremforge Actions-körning i ett repo i din organisation: fremforges registry registrerar vilken körning som pushade varje manifest, och repot och commiten är den körningens. Varje push av imagen måste komma från Actions-körningar i just det repot; en image som också pushats från något annat ställe (en laptop, en annan CI), eller av en körning i ett repo i en annan organisation, tillskrivs inte på det här sättet.

   Fyndet anger vilket repo och vilken Dockerfile som byggde imagen och hur fremforge vet det (“från dess image-etiketter” eller “från Actions-körningen som pushade den”), och det gör även API:t (base_attribution på varje image-fynd).

2. fremforge hittade den Dockerfile i den commiten vars FROM-bas imagen bygger på: bas-imagens lager är de första lagren i din image.

3. Trivy placerar det sårbara paketet i ett av de baslagren, inte i ett lager som din Dockerfile lägger till.

4. Den nyaste basen i samma linje (samma major-version och taggform, eller samma taggs nyare digest för en flytande tagg), skannad av fremforge med samma sårbarhetsdatabas, har den inte längre.

Den här analysen körs med den dagliga image-skanningen. Pull requesten ändrar bara den FROM-raden: taggen, och den digest som fremforge skannade för den. En ändring på någon annan rad eller i någon annan fil, eller en annan digest än den fremforge skannade, stänger den. Varje öppet fynd i imagen som samma bas åtgärdar listas i en pull request.

När det inte finns någon knapp anger fyndet varför:

När du har mergat pull requesten och pushat den ombyggda imagen under samma tagg jämför fremforge den nya imagen med den gamla när den nya har skannats. Varje fynd för den gamla digesten som den nya imagen inte längre har stängs som åtgärdat av fremforge (fixed_source: security_fix), förutsatt att den gamla digesten inte längre används: den har ingen tagg längre, den finns inte i den senaste aktiva driftsättningen av ett repo och en miljö, och ingen utom fremforges egna botar har hämtat den via digest de senaste 7 dagarna. Den gamla digestens fynd förblir listade under den digesten så länge imagen finns i ditt registry.

Om den gamla digesten fortfarande används stängs ingenting: fyndet visar Åtgärdad i nyare image med den nya digesten, och anger varför det förblir öppet (fortfarande taggad, fortfarande driftsatt, eller hämtad nyligen). Det stängs när den gamla digesten slutar användas, och öppnas igen om den digesten börjar användas igen.

Efter merge

När pull requesten har mergats och nästa skanning av standardbranchen inte längre rapporterar ett fynd stängs fyndet. Dess historik i compliancerapporten registrerar det som åtgärdat av en säkerhetsfix (fixed_source: security_fix; rader som registrerades före 2026-10-14 sade autofix). Ett fynd som stängts av en av hostad Renovates egna säkerhets-pull requests registreras som fixed_source: renovate. Åtgärdsmått räknar båda.

Gränser

• En aktiv begäran per (repo, paket) på varje branch. En andra begäran för samma paket på samma branch svarar redan begärd. En fix till en skyddad release-branch är en separat begäran från standardbranchens.
• Högst 3 öppna pull requests för säkerhetsfixar per repo, som standard; 0 till 10.
• Högst 20 begäranden per organisation under 24 timmar, som standard; 0 till 50.
• En samlad pull request räknas som en mot båda.

De gäller klick och automatiska säkerhetsfixar tillsammans. AI-fix har egna gränser. När ingen pull request öppnas, se Felsökning.

API

• Begär en fix POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:write (findings:write accepteras också). Bodyn anger exakt ett av:

  • finding_id: ett beroendefynd. En pull request för dess paket. Svarar 202 med begärans id, målversionen, de fyndnycklar den omfattar, known_exploited_cves (de CVE-id:n för kända utnyttjade sårbarheter som den åtgärdar; tom om inga) och automerge.
  • repo: varje åtgärdbart paket i det repot, en pull request var, eller en per låsfil i ett samlat repo. Svarar 202 med ett utfall per paket (queued med dess group_id, null när det inte är samlat, eller refused med en reason), eller 200 när inget köades.
  • image_finding_id: en uppgradering av bas-image. Nekanden omfattar image_not_from_base, image_no_base_fix, image_source_unknown och image_not_attributed.

  Ett nekande är problem+json vars type är security-fix-<reason> och som innehåller reason, till exempel no_fixed_version, ecosystem_not_supported, manifest_not_supported eller sbom_finding. Var och en beskrivs under API-fel.

• Lista begäranden GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:read, med varje begärans status och pull request.

• Inställningar GET och PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings; se Inställningar.

• Vem som öppnar säkerhets-pull requests GET och PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane; se Ta över från Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates innehåller security_fixes_bot, true när beroendeboten finns för säkerhetsfixar. Dess enrolled betyder att Versionsuppdateringar är påslaget.

• Räknare GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics: begäranden, pull requests som öppnats, mergats och stängts, godkännandegrad, pull requests som mergats utan en godkännande granskning, och fynd som åtgärdats av en säkerhetsfix.

Varje beroendefynd som returneras av GET /_app/api/v1/orgs/{org}/code-security/deps/findings innehåller autofix_eligible, autofix_unavailable_reason (varför ett fynd med en fix inte omfattas) och autofix, den senaste begäran som omfattar det. Varje image-fynd från GET .../code-security/images/findings innehåller samma tre fält för uppgraderingar av bas-images.

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"

Utfasat API

Dessa sökvägar, fält och scopes fortsätter att fungera till och med 2027-10-15. Fram till dess har varje svar från en utfasad sökväg Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT och en Link-header med rel="successor-version" som anger efterföljaren.

Ta över från Renovate

Tills en organisation byter betjänar hostad Renovates egna pull requests för sårbarhetsvarningar den vid sidan av det här spåret (lane_owner: renovate). När spåret Säkerhetsfixar tar över (lane_owner: security_lane) öppnar Renovate bara versionsuppdateringar, så att varje fix föreslås en gång. Öppna säkerhets-pull requests från Renovate stängs, med en kommentar som länkar till ersättande fix-pull request, när det här spåret har en fix-pull request för varje paket som de uppgraderar; fram till dess förblir de öppna.

För kunder görs bytet tills vidare på begäran: kontakta supporten. fremforge byter för sina egna organisationer. API:t är PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane med {"lane_owner": "security_lane"} (eller "renovate" för att byta tillbaka), scope dependency-updates:write; GET på samma sökväg svarar med det aktuella värdet, och även unsupported_ecosystems (ett objekt, ekosystem till antalet öppna åtgärdbara fynd som spåret inte åtgärdar) och unsupported_total, så att du i förväg kan se om ett byte skulle nekas. Övertagandet nekas om inte spåret kan agera:

• Säkerhetsfixar är Av: 409 security-lane-lane-off. Välj ett annat läge än Av först, eller skicka "acknowledge": ["no_security_prs"] för att acceptera att inga säkerhets-pull requests alls öppnas.
• Öppna fynd i ekosystem som spåret inte åtgärdar (till exempel CRAN eller Conan, som Renovates varningar omfattar): 409 security-lane-unsupported-ecosystems, vars unsupported_ecosystems listar de öppna åtgärdbara fynden per ekosystem. Skicka "acknowledge": ["unsupported_ecosystems"] för att byta ändå; de fynden får då ingen automatisk pull request.

Vid bytet börjar pull requests för säkerhetsfixar följa När fixar mergas, i organisationer där de fram till dess väntade på granskning; se Merge.

Bytet registreras i granskningsloggen som dependency-updates.security-lane.enabled, och bytet tillbaka som dependency-updates.security-lane.disabled.

Granskning

Varje steg finns i granskningsloggen: autofix.proposed, autofix.pr_opened, autofix.rejected (med orsaken), autofix.relocked (en låsfilscommit från din egen CI, med körningen), autofix.relock_refused (en jobbtoken som inte var den startade körningen), autofix.merged och autofix.closed, var och en med fyndnycklarna och engine: deterministic. autofix.proposed för en fix av en känd utnyttjad sårbarhet innehåller också knownExploitedCves. En ändring av inställningarna är dependency-updates.security-fixes.updated.

AI-fixar för SAST-fynd

AI-genererade fixar för SAST-fynd har flyttat till en egen sida: AI-fix.

Se även

• Uppdateringar av beroenden: båda spåren och boten.
• Merge: granskning, merge när kontrollerna går igenom, merge-fönstret och release-frysningen.
• Felsökning: när ingen pull request öppnas.
• OSV-rekommendationer: korten som knappen Öppna fix-PR sitter på.
• Checklista för konfiguration: dina gränser och val i en överblick under Säkerhet › Översikt.