Sikkerhedsrettelser

En sikkerhedsrettelse gør et fund i en afhængighed til en pull request. Klik på Åbn rettelses-PR på et fund eller på et kort under Anbefalinger, eller kald API’et, så åbner din organisations afhængighedsbot én pull request i det repository. Den løfter pakken til den laveste udgivne version, der retter alle åbne advisories på den. Det er sporet Sikkerhedsrettelser under Opdateringer af afhængigheder, under Sikkerhed › Ret › Opdateringer af afhængigheder.

Sikkerhedsrettelser dækker afhængigheder i npm (herunder Yarn, pnpm og Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex og CRAN (R) samt versioner af CI-actions (GitHub Actions) i de manifester, der står under Økosystemer og manifester. Andre økosystemer svarer endnu ikke understøttet. Den fulde liste står under Understøttede økosystemer. Der er ingen AI-model involveret: opdateringen beregnes ud fra OSV’s advisory-poster.

For en sårbarhed i et image, der er pushet til dit registry, og som fulgte med imagets FROM-base, løfter Åbn PR med rettet base-image den base, når fremforge har tjekket, at den nyere base ikke længere har sårbarheden. Se Opdatering af base-images. Ret alle i dette repository bestiller alle pakker, der kan rettes i et repository, på én gang: se Ret alt, der kan rettes, i et repository.

Sikkerhedsrettelser hed AutoFix indtil 2026-10-14. AutoFix er ikke længere et produktnavn: AI-genererede rettelser til SAST-fund er AI-rettelse. Revisionshændelserne autofix.* og de udfasede API-stier bærer stadig det gamle navn. Pull requests, der blev åbnet før skiftet, beholder deres autofix/-branch; fremforge tilføjer etiketten security-fix til dem, der stadig er åbne.

Indstillinger

En ejer angiver disse under Sikkerhed › Ret › Opdateringer af afhængigheder › Sikkerhedsrettelser eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Alle felter er valgfrie i en PUT; et felt, der udelades, beholder sin værdi, og intet gemmes, hvis et felt afvises.

Tilstandene:

• Fra (off): ingen sikkerhedsrettelses-pull requests, hverken ved klik eller automatisk.
• Ved klik (on_click): en person beder om dem med Åbn rettelses-PR, Ret alle i dette repository eller Åbn PR med rettet base-image eller via API’et.
• Automatisk for vigtige fund (auto_important): som ved klik, og derudover åbner fremforge dem selv for høje og kritiske fund, der er nåbare eller kendt udnyttede. Med Medtag også fund, hvor nåbarheden er ukendt slået til tæller høje og kritiske fund uden en nåbarhedsvurdering også med. Se Automatiske sikkerhedsrettelser.
• Automatisk for alle høje og kritiske (auto_high_critical): fremforge åbner dem selv for alle høje og kritiske fund, den kan rette, uanset nåbarhed.
• Automatisk for kritiske og kendt udnyttede (auto_critical_exploited): fremforge åbner dem selv for alle kritiske fund, uanset nåbarhed, og for alle kendt udnyttede fund uanset alvorlighed. Et højt, middel eller lavt fund, der ikke er kendt udnyttet, venter på et klik. Det er standard for en organisation oprettet 2026-10-27 eller senere; se Nye organisationer.

Svaret indeholder også skrivebeskyttede felter. configured er false, så længe organisationen aldrig har gemt indstillingerne, og værdierne er standardværdierne (for en ny organisation de standardværdier, den blev oprettet med). lane_owner angiver, hvem der åbner sikkerheds-pull requests: renovate, så længe hostet Renovates egne sikkerheds-pull requests stadig betjener organisationen, og security_lane, når dette spor har overtaget. high_blast_radius_exempt er true for organisationer, hvis Renovate-sikkerheds-pull requests mergede sig selv før 2026-10-14 og blev flyttet til Flet, når tjek består; se Merging.

En ændring registreres i revisionsloggen som dependency-updates.security-fixes.updated med hvert felts gamle og nye værdi.

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"

Sikkerhedsrettelser kræver ikke Versionsopdateringer. Den første bestilling af en rettelse (Åbn rettelses-PR, Ret alle i dette repository, Åbn PR med rettet base-image eller POST .../security-fixes/requests), eller når du gemmer en automatisk tilstand, opretter din organisations afhængighedsbot <org>-fremforge-bot-deps med Versionsopdateringer slået fra. Et repository, der har fravalgt opdateringer af afhængigheder, får ingen rettelses-pull requests, og et arkiveret repository eller et mirror afvises (repo_archived).

Hvad der sker, når du klikker på Åbn rettelses-PR

1. fremforge samler alle åbne fund på standard-branchen for den samme pakke i det samme repository. Én pull request lukker dem alle.
2. Den beregner målversionen. For hver installeret version er det den laveste udgivne version uden for alle berørte intervaller i alle åbne advisories. Pull requesten tager den højeste af dem, så den retter hele gruppen.
3. En målrettet kørsel af hostet Renovate starter som din organisations afhængighedsbot. Den er begrænset til den ene pakke og den ene version. Alle andre afhængigheder lades i fred.
4. Renovate åbner pull requesten på en branch security-fix/<package>-<version>. Kørsler for sikkerhedsrettelser går forud for almindelige Renovate-kørsler, så det tager normalt under 15 minutter. Pull requesten får etiketten security-fix. Hvis repositoriet ikke har den etiket endnu, opretter fremforge den før kørslen, én gang; en etiket, der allerede findes, lades som den er. Hvis en etiket ikke kan oprettes, åbnes pull requesten uden den.
5. fremforge tjekker pull requesten, før den holdes åben. Den må kun ændre økosystemets manifester og lockfiler (se tabellen nedenfor), og i et manifest kun den pakkes post. En ændring af en anden fil, en ny direkte afhængighed, en opdatering af en anden pakke, en delt version eller en lockfil, hvis pakker nu kommer fra et andet index, lukker pull requesten og sletter dens branch. Det samme gør en mislykket opdatering af lockfilen: en pull request med en forældet lockfil ville ikke kunne bygge.

Fundet viser derefter Rettelse foreslået: #N med pull requestens tilstand: åben, merget eller lukket.

Hver kopi skal nå rettelsen. En lockfil kan indeholde flere kopier af én pakke: en direkte og ældre, der ligger under andre afhængigheder. Før en pull request tæller som en rettelse, læser fremforge dens lockfiler ved pull requestens head og tjekker hver kopi af pakken, de registrerer, mod den rettede version. Det gælder 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, for enkelte og samlede rettelser. En pre-release af den rettede version tæller som under den.

• Hver kopi er på eller over rettelsen: pull requesten retter pakken.
• Nogle kopier er rettet, en ældre er tilbage: pull requesten forbliver åben, og konsollen nævner de kopier, der er tilbage (i API’et bestillingens lock_copies_left med reason target_partly_reached). Rettelse foreslået vises kun på fundene for de kopier, den retter; de andre beholder deres Ret-knap.
• Ingen kopi når rettelsen, for eksempel en transitiv kopi, der flyttede med sin forælder, men til en version, der stadig er sårbar: pakken er ikke en del af pull requesten. Dens bestilling ender som target_not_reached, og den transitive rettelse fastlåser den for sig. En pull request uden nogen rettet pakke lukkes.

Et lockfilformat, der ikke står her, tjekkes som før: pull requesten skal ændre pakken i lockfilen.

Hvad dette tjek ikke gør:

• Kun de lockfiler, pull requesten ændrer, læses. Hvis en anden lockfil i repositoriet, en som pull requesten ikke rører, stadig indeholder en sårbar version, forbliver det fund åbent efter merge. Det angives ikke som rettet: dets Ret-knap bliver.
• En kopi, der er blevet tilbage, rettes efter merge, ikke samtidig. Mens pull requesten er åben, afvises en ny bestilling for samme pakke, fordi der allerede er en åben, så Ret på en kopi, som pull requesten efterlader, starter ikke noget endnu. Bestil den igen efter merge og næste scanning.
• Samme version, direkte og indlejret. Et fund identificeres ud fra pakke og version, ikke ud fra hvor i træet kopien sidder. Hvis pull requesten flytter den direkte kopi, men samme gamle version stadig ligger under en anden afhængighed, er det fund ikke rettet, så bestillingen ender som target_not_reached, og dens pull request lukkes. Den transitive rettelse afviser en pakke, som dit manifest nævner direkte, så fastlås selv den indlejrede kopi (for eksempel med en npm-overrides-post).

Dit repositorys Renovate-indstillinger

Et repositorys egen renovate.json (eller .renovaterc eller nøglen renovate i package.json) former dets versionsopdateringer. Den holder ikke en sikkerhedsrettelse tilbage. En kørsel for en sikkerhedsrettelse ignorerer repositoriets:

• packageRules, herunder en regel med "enabled": false for pakken;
• ignoreDeps;
• ignorePaths og includePaths. Kun node_modules og bower_components springes over;
• enabledManagers. Kørslen bruger managerne for fundets økosystem.

For at holde en pakke ude af sikkerhedsrettelser skal du registrere en undtagelse for dens fund: afvis dem med en begrundelse og helst en udløbsdato, eller anmod om en godkendt undtagelse. Et fund med en undtagelse er ikke åbent, så der bestilles ingen rettelse for det, og Åbn rettelses-PR svarer security-fix-not-open. I modsætning til en tilbageholdelsesregel i en fil er en undtagelse synlig på siden Undtagelser, viser hvem der lavede den og hvorfor, og bortfalder på sin udløbsdato.

To indstillinger gælder stadig:

• En "enabled": false på øverste niveau i renovate.json slår Renovate fra for hele repositoriet, inklusive sikkerhedsrettelser.
• Et repositorys packageRules, der sætter registryUrls eller andre opslagsindstillinger, gælder ikke for en kørsel for en sikkerhedsrettelse. Kørslen slår pakker op via din organisations egne indstillinger og afhængighedsproxyen.

Kendt udnyttede sårbarheder først

Når en advisory, som en bestilling retter, har en CVE, der er angivet som udnyttet i praksis af ENISA’s EU Vulnerability Database (EUVD) eller CISA’s Known Exploited Vulnerabilities-katalog (KEV), behandles rettelsen som den mest presserende:

• Den kører først. Dens Renovate-kørsel tages før alle andre bestillinger af sikkerhedsrettelser i køen, uanset hvilken rækkefølge de blev bestilt i.
• Den er først i Ret alle. En samlet bestilling med Ret alle i dette repository tager kendt udnyttede pakker før de andre og derefter efter alvorlighed, så når en grænse nås, er det en mindre presserende pakke, der udelades.
• Den venter ikke på udgivelsesalderen. Din Udgivelsesalder holder andre rettelser tilbage, men en version, der retter en kendt udnyttet sårbarhed, foreslås med det samme.
• Pull requesten siger det. Titlen slutter med known exploited, for eksempel fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), beskrivelsen begynder med CVE’erne og de lister, der nævner dem, og pull requesten får også etiketten known-exploited, oprettet på samme måde som security-fix.

En CVE tæller, når den er advisoryens eget id eller et af dens aliasser (en GHSA- eller PYSEC-advisory har normalt et CVE-alias). Begge lister spejles og opdateres dagligt. Om en bestilling er kendt udnyttet, afgøres, når den oprettes; API’et angiver det som known_exploited_cves. Med Flet, når tjek består aktiveres den også uden for dit merge-vindue; se Merging. Grænserne gælder stadig.

Automatiske sikkerhedsrettelser

Med Automatisk for vigtige fund, Automatisk for alle høje og kritiske eller Automatisk for kritiske og kendt udnyttede åbner fremforge de samme pull requests som et klik på Åbn rettelses-PR eller Åbn PR med rettet base-image, uden at nogen klikker, for hvert fund, der opfylder alle disse betingelser:

1. Det er åbent på standard-branchen: ikke afvist og ikke rejst på en pull request.
2. Dets alvorlighed er høj eller kritisk. Middel og lave fund rettes kun automatisk med Automatisk for kritiske og kendt udnyttede, og kun når de er kendt udnyttede.
3. Med Automatisk for vigtige fund: det er nåbart (dets nåbarhedsvurdering er reachable) eller det er kendt udnyttet (en af dets CVE’er er angivet af ENISA EUVD eller CISA KEV), eller, med Medtag også fund, hvor nåbarheden er ukendt slået til, det har ingen eller en ukendt vurdering. Et kendt udnyttet fund kvalificerer, selv når det ikke er nåbart. Med Automatisk for alle høje og kritiske kvalificerer alle høje og kritiske fund. Med Automatisk for kritiske og kendt udnyttede kvalificerer et kritisk fund uanset nåbarhed, et kendt udnyttet fund uanset alvorlighed, og intet andet.
4. fremforge kan rette det deterministisk: en afhængighed i et dækket økosystem og manifest med en udgivet rettelse, eller et image-fund, som en opdatering af base-imaget retter.

Vil du prøve det af på nogle få repositorier først, så angiv dem under Repositorier. En tom liste dækker alle organisationens repositorier. Sikkerhedseksempel-repositoriet rettes aldrig automatisk; et klik på Åbn rettelses-PR virker stadig dér.

Nye organisationer

En organisation oprettet 2026-10-27 eller senere starter med Automatisk for kritiske og kendt udnyttede og med Hvornår rettelser merges sat til Vent på gennemgang: rettelses-pull requests åbner af sig selv, og ingen merges uden en person. Grænserne, gruppering og udgivelsesalder beholder deres standardværdier. Intet tilmeldes Versionsopdateringer: afhængighedsbotten <org>-fremforge-bot-deps oprettes først, når det første fund kvalificerer. En ejer kan til enhver tid skifte til en anden tilstand, herunder Fra, eller udvide den. Organisationer oprettet før 2026-10-27 beholder den indstilling, de havde.

Hvornår den handler

fremforge tjekker hvert 10. minut. Et fund foreslås kort efter, at det kvalificerer: når en scanning rapporterer et nyt fund, når dets vurdering bliver nåbar, eller når den daglige opdatering af kendt udnyttede tilføjer en af dets CVE’er. Fund, der allerede kvalificerer, når du slår det til, medtages også inden for grænserne.

Hvad der er det samme

Hver automatisk bestilling går præcis samme vej som et klik: én pull request pr. pakke (eller pr. base-image), den laveste version, der retter, din organisations grænser, tilbageholdelsen for udgivelsesalder, afvisningen ved delt version og tjekkene af omfang. På listen over bestillinger har sådan en bestilling "trigger": "policy", og dens pull request oplyser, at den blev åbnet automatisk.

• Den merges, som du har sat det op. Som alle sikkerhedsrettelses-pull requests følger den Hvornår rettelser merges; se Merging.
• Den bruger aldrig AI. Kun den deterministiske motor kører automatisk. AI-rettelse starter altid med en persons klik på ét fund.
• En bølge venter på sin tur. Når listen over kendt udnyttede tilføjer en CVE, som mange af dine repositorier har, åbner fremforge det, dine grænser tillader, kendt udnyttede og kritiske først, og resten senere, efterhånden som pull requests merges eller lukkes, og 24-timersvinduet flytter sig. Den åbner aldrig flere end grænserne.
• En lukket pull request forbliver lukket. Hvis nogen lukker en sikkerhedsrettelses-pull request uden at merge den, åbner fremforge den ikke igen for de samme fund og den samme målversion. Et nyt kvalificerende fund på den pakke eller en nyere målversion er en ny grund og kan foreslås. En bestilling, der endte uden en pull request (for eksempel Venter på udgivelsesalderen), forsøges igen efter 24 timer.

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

Økosystemer og manifester

Endnu ikke dækket, og det står på fundet:

• Andre JVM-byggeværktøjer (Ivy, sbt): fundet viser Manifest ikke dækket.
• bun.lockb, Buns binære lockfil, som kun Bun kan omskrive. Kør bun install --save-text-lockfile én gang for at skifte til bun.lock.
• Bun-pakker, som manifestet ikke nævner: kørslen ender med ingen ændring.
• pub-pakker, som manifestet ikke nævner: kørslen ender med ingen ændring.
• Fund fra en uploadet SBOM (manifest sbom:<name>): der er ingen fil i repositoriet at ændre. Fundet viser Fra en SBOM.
• Conan (conan.lock): OSV, som scanningen af afhængigheder læser sine advisories fra, publicerer ingen for Conan-pakker, så der er ingen Conan-sårbarhed at rette.

En pakke, der kun er en transitiv afhængighed (i lockfilen, men ikke i et manifest), fastlåses fra roden af dit projekt: en npm-overrides-post, en Maven-<dependencyManagement>-post eller linjen // indirect i go.mod. Se Transitive afhængigheder.

Opdatering af lockfiler

Lockfilen opdateres af pakkemanageren 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), uden nogensinde at køre repositoriets egne scripts eller plugins, som din organisations Renovate-bot, gennem den samme hostede Renovate-sandkasse som dens almindelige opdateringer. En opdatering flytter aldrig pakker til et andet index: en Python- eller Cargo-lockfil, hvis pakker bagefter ville komme fra et andet index, afvises. Hvis opdateringen fejler, for eksempel fordi repositoriet nævner et privat index, som botten ikke kan læse, lukkes pull requesten som PR lukket: lockfil fejlede i stedet for at blive stående åben med en forældet lockfil.

Din organisations afhængighedsproxy som index. Når repositoriets manifester, lockfiler eller værktøjskonfiguration nævner din organisations egen afhængighedsproxy (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...), godkender opdateringen sig dér som din Renovate-bot. Det gælder for alle Renovate-kørsler i det repository, ikke kun fremforges. Legitimationsoplysningen gives til præcis de af din organisations proxy-stier, som repositoriet nævner, og til intet andet: et uv-, Poetry- eller Pipenv-index og en nuget.config-kilde får den gennem Renovates egen håndtering af legitimationsoplysninger, Cargo gennem en credential provider, der kun svarer for din organisations Cargo-proxy. (Et Gradle-build opdateres slet ikke her; se Gradle.) Legitimationsoplysningen ligger i filer for den ene kørsel, aldrig i repositoriet, aldrig i miljøet og aldrig i logs.

Gradle

fremforge kører aldrig dit repositorys build. At opdatere en Gradle-lockfil betyder at køre din Gradle-wrapper og dine build-scripts, så for et Gradle-fund deles arbejdet op:

1. fremforge ændrer kun versionen. Renovate redigerer build.gradle(.kts), versionskataloget eller gradle.properties med de samme tjek af omfang og delt version som alle sikkerhedsrettelses-pull requests og åbner pull requesten uden at røre lockfilerne. Ingen Renovate-kørsel, hverken fremforges eller den almindelige, eksekverer kode fra repositoriet.
2. Din egen CI opdaterer lockfilerne. Hvis buildet har *.lockfile-filer eller gradle/verification-metadata.xml, committer fremforge et genereret workflow, .forgejo/workflows/fremforge-autofix-relock.yaml, på en midlertidig branch autofix-relock/<request> (med [skip ci], så ingen af dine egne workflows kører på den) og starter det én gang på din organisations hostede runner (runs-on: fremforge): en flygtig VM for det commit. Det tæller ikke med i din organisations CI-minutter: fremforge registrerer den kørsel, den startede, og holder den ude af dit forbrug og din faktura. Den tæller dog med i dit antal samtidige jobs, mens den kører. Du behøver ikke ændre dit repository. Kørslen vises under repositoriets fane Actions.
3. Jobbet kører de samme kommandoer, som Renovates Gradle-manager ville: gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, og --write-verification-metadata, når buildet verificerer afhængigheder. Det vælger et JDK fra runneren (21, ellers 17), giver runnerens udgående proxy videre til JVM’en og læser din organisations afhængighedsproxy med jobbets eget token via egenskaberne fremforgeUsername og fremforgePassword. Det har ingen skriveadgang: dets rettigheder er contents: read, packages: read og id-token: write.
4. fremforge tjekker og committer resultatet. Jobbet sender de ændrede lock- og verifikationsfiler til fremforge med et job-token for audiencen fremforge:autofix-relock, som fremforge kun accepterer fra den ene kørsel. fremforge afviser alt, der ikke er en Gradle-lock- eller verifikationsfil fra det genlåste build, en lockfil, der stadig låser den sårbare version, eller en branch, der er ændret i mellemtiden. Derefter tilføjer den filerne til sikkerhedsrettelsens pull request som ét commit fra din Renovate-bot, så din pull request-CI kører på det, tjekker at pull requesten kun ændrer Gradle-build-filer og lockfiler, og sletter den midlertidige branch. Statussen fremforge/autofix-relock på pull requesten linker til kørslen.

Et build uden lockfiler får kun versionsændringen, og intet job kører.

Hvis jobbet fejler, annulleres, ikke rapporterer eller ikke er færdigt 90 minutter efter start (for eksempel når organisationens runner-minutter er brugt op), lukkes pull requesten som PR lukket: lockfil fejlede med et link til kørslen. Gennemgå en Gradle-pull request, når lockfil-committet er kommet; indtil da er dens lockfiler forældede. Med Flet, når tjek består aktiveres en Gradle-rettelse ikke, mens opdateringen af dens lockfil afventer eller er ved at blive committet; den aktiveres, når lockfil-committet er landet, og dens tjek består. Hvis du merger den manuelt, så vent på lockfil-committet.

RubyGems, Hex, CRAN og Composer-pakker, som composer.json ikke nævner

Bundler læser Gemfile, og Mix læser mix.exs for at låse dem, og begge er kode (Ruby, Elixir), så fremforge kører aldrig selv Bundler eller Mix. At opdatere renv.lock kræver R, som hverken fremforge eller Renovate kører. Renovate opdaterer kun de Composer-pakker, som composer.json nævner. For disse rettelser opdateres lockfilen i din egen CI, på samme måde som en Gradle-opdatering, og pull requesten åbnes først, når den er kommet:

1. Din egen CI opdaterer lockfilen. fremforge committer det genererede workflow .forgejo/workflows/fremforge-autofix-relock.yaml på en midlertidig branch autofix-relock/<request>, lavet fra base-branchens head (med [skip ci]), og starter det én gang på din organisations hostede runner, uden at det tæller med i dine CI-minutter. I lockfilens mappe kører det bundle lock --update <gem> --conservative --patch|--minor|--major --strict (det mindste niveau, der når rettelsen, med Ruby fra .ruby-version eller lockfilen og den Bundler-version, lockfilen blev skrevet med), mix deps.update <package> i det officielle elixir-image (den version, din .tool-versions nævner, ellers den aktuelle; dine runners har ikke Elixir), fremforges R-script i rocker/r-ver-imaget med den R-version, som renv.lock registrerer (se CRAN nedenfor), eller composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Intet installeres, og intet gem- eller pakkescript kører. Det har ingen skriveadgang. Mens det kører, viser fundet Rettelse bestilt.
2. Udgivelsesalderen tjekkes i jobbet. Medmindre rettelsen gælder en kendt udnyttet sårbarhed, læser jobbet udgivelsestidspunktet for den version, det låste, fra rubygems.org, hex.pm eller repo.packagist.org eller, for CRAN, fra pakkens eget felt Date/Publication; en version, der er yngre end din organisations udgivelsesalder, afslutter bestillingen med Ingen PR endnu: for ny, og den forsøges igen efter 24 timer.
3. fremforge tjekker lockfilen og åbner pull requesten. Jobbet sender den ene lockfil tilbage med et job-token for den ene kørsel. fremforge afviser en lockfil, hvor noget andet end de låste versioner er ændret (kilder, platforme, afhængigheder, Bundler-versionen, Composers content-hash, en git- eller sti-afhængighed i mix.lock, i renv.lock alt andet end pakkens egen post), en der ikke låser den rettede version, eller en der stadig låser den sårbare version. Derefter committer den filen som din Renovate-bot på sikkerhedsrettelsens branch, lavet fra base-branchen, åbner pull requesten med den sædvanlige titel, beskrivelse og etiketter og sletter den midlertidige branch. Fra da af er det en almindelig sikkerhedsrettelses-pull request.

Hvis jobbet fejler, annulleres, ikke rapporterer eller ikke er færdigt 90 minutter efter start, åbnes der ingen pull request, og bestillingen ender med Ingen PR: lockfilen kunne ikke opdateres med årsagen og et link til kørslen.

CRAN

En CRAN-rettelse flytter én post i renv.lock og intet andet. Jobbet installerer den version af renv, som renv.lock blev skrevet med, så filen beholder sit format, og læser den rettede versions DESCRIPTION fra det pakke-repository, som renv.lock nævner. Det installerer aldrig dit projekt eller kører dets kode. Det afviser og forklarer hvorfor, når:

• den rettede version kræver en pakke (Depends, Imports eller LinkingTo), som renv.lock ikke låser eller låser under den krævede version;
• den rettede version kræver en anden R-version end den, renv.lock registrerer;
• dit projekts DESCRIPTION begrænser pakken til under rettelsen, for eksempel Imports: commonmark (<= 1.8);
• den rettede version er yngre end din organisations udgivelsesalder.

I hvert af disse tilfælde skal du opdatere pakkerne sammen med renv i dit projekt (renv::update() og derefter renv::snapshot()). Ellers får posten den nye version, dens afhængigheder og renvs hash, og fremforge accepterer kun filen, hvis alle andre poster, R-versionen og repositorierne er uændrede.

Delte versioner

En version, der står ét sted og læses af flere afhængigheder, såsom en pom.xml-property (<logback.version>), en Gradle-variabel i gradle.properties eller en post i et versionskatalog ([versions] logback = "1.5.12"), flytter alle disse afhængigheder, når den opdateres. fremforge læser alle pom.xml-filer, eller alle Gradle-build-filer og kataloger, i pull requesten.

En pom.xml-property opdateres, når opdateringen er rigtig for alle, der læser den. Hver anden afhængighed, der læser den, skal have åbne sårbarheder i repositoriet (på standard-branchen), være rettet på eller under den nye version og være publiceret i den version på din organisations Maven-proxy. Pull requesten nævner så de afhængigheder under Also updated by this pull request og lukker deres fund, når den merges. Hvis to bestillinger ville lave den samme opdatering, beholder bestillingen for den pakke, der sorteres først, opdateringen, og den anden ender med PR lukket: delt version med navnet på den første.

Ellers, og altid for en Gradle-variabel eller katalogpost, en rettelse på en release-branch eller en version, der læses på en måde, som fremforge ikke kan knytte til en afhængighed, lukkes pull requesten som PR lukket: delt version, og bestillingens detail angiver, hvilken læser der ikke opfyldte hvilken betingelse (ingen åben sårbarhed, ingen rettet version, kræver en højere version, ikke publiceret i den nye version). Opdatér så selv den delte version, så du vælger versionen for dem alle: den sårbare pakkes rettelse findes måske ikke som release af de andre (en biblioteksfamilie udgiver ofte en patch-release af kun én artefakt). En version, som kun den sårbare pakke læser, opdateres som normalt.

Ret alt, der kan rettes, i et repository

Under Anbefalinger har hvert repository med to eller flere pakker, som fremforge kan rette nu, en knap Ret alle i dette repository. Den bestiller én pull request pr. pakke (og pr. base-image, se nedenfor), eller, i et repository der samler sine rettelser, én pr. lockfil, kendt udnyttede først, derefter højeste alvorlighed. Bestillingerne optages samlet inden for dine grænser: når et repository har 3 åbne sikkerhedsrettelses-pull requests, eller din organisation har brugt sine 20 bestillinger for dagen, bestilles resten ikke, og resultatet siger, hvor mange der blev. En pakke, der allerede har en bestilling, springes over.

Med API’et: POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests med {"repo": "<name>"} svarer 202 med ét udfald pr. pakke (queued, eller refused med en reason), eller 200, når ingen blev sat i kø.

Samlede rettelser

I et repository, der står under Samlede repositorier (grouped_repos), samles rettelserne for én lockfil i én pull request, som Dependabot-grupper, i stedet for én pr. pakke. Alle andre repositorier beholder én pull request pr. pakke, og det gør alle repositorier som standard.

• Hvad der samles: pakker fra én lockfil (ét økosystem, ét manifest, én base-branch), hvis rettelse holder sig inden for den installerede major-version, i npm (med pnpm og Yarn), PyPI, Go, Cargo og NuGet. Højst 20 pakker kommer i én gruppe; flere giver en ny gruppe.
• Hvad der ikke samles: en rettelse, der kræver en ny major-version, et base-image, en fastlåsning af en CI-action samt Gradle-, Maven-, Composer-, RubyGems-, Hex- og CRAN-pakker. Hver af dem får sin egen pull request som før.
• Hvornår: Ret alle i dette repository og automatiske sikkerhedsrettelser. Et enkelt Åbn rettelses-PR på ét fund er stadig én pull request for den pakke.
• Grænser: en gruppe tæller som én pull request i Åbne rettelses-pull requests pr. repository og som én bestilling i Rettelses-pull requests pr. dag. En pakke, der allerede har sin egen bestilling eller blev forsøgt inden for de seneste 10 minutter, udelades fra gruppen i stedet for at blive gentaget.
• Hver pakke beholder sin egen bestilling. Pull requesten viser hver pakke med dens rettede version, og hver pakkes fund lukkes, når den merges, som ved en enkelt rettelse. En pakke, som kørslen ikke kunne opdatere sammen med de andre, eller kun kunne opdatere til en version under rettelsen (se Hver kopi skal nå rettelsen under Hvad der sker, når du klikker på Åbn rettelses-PR), udelades og nævnes på pull requesten. Den beholder sin egen bestilling: en, der venter på sin udgivelsesalder, bestilles igen senere, og en pakke, som manifestet ikke nævner (en transitiv afhængighed), fastlåses for sig af den transitive rettelse. En udeladt pakke holder aldrig gruppen tilbage.
• I konsollen viser Aktivitet en samlet pull request én gang, som Samlet · N pakker med hver pakke og dens version. I API’et har hver bestilling i en gruppe samme group_id (på POST .../requests med repo og på GET .../requests).

Opdatering af base-images

For en sårbarhed i et image, der er pushet til din organisations registry, kan fremforge løfte imagets FROM-base i den Dockerfile, der byggede det. Åbn PR med rettet base-image på fundet (under Sikkerhed › Fund › Container-images) findes, når alt dette gælder:

1. fremforge ved, hvilket repository og commit der byggede imaget, på en af to måder:

   • imaget nævner dem med OCI-etiketterne org.opencontainers.image.source og org.opencontainers.image.revision (docker/metadata-action sætter begge). Etiketterne vinder, når de findes;
   • eller, uden sådanne etiketter, blev imaget pushet af en fremforge Actions-kørsel fra et repository i din organisation: fremforges registry registrerer, hvilken kørsel der pushede hvert manifest, og repositoriet og committet er den kørsels. Hvert push af imaget skal komme fra Actions-kørsler i det ene repository; et image, der også er pushet fra et andet sted (en bærbar, en anden CI), eller af en kørsel i en anden organisations repository, tilskrives ikke på denne måde.

   Fundet oplyser, hvilket repository og hvilken Dockerfile der byggede imaget, og hvordan fremforge ved det (“fra dets image-etiketter” eller “fra den Actions-kørsel, der pushede det”), og det samme gør API’et (base_attribution på hvert image-fund).

2. fremforge fandt den Dockerfile i det commit, hvis FROM-base imaget er bygget på: base-imagets lag er de første lag i dit image.

3. Trivy placerer den sårbare pakke i et af disse base-lag, ikke i et lag, som din Dockerfile tilføjer.

4. Den nyeste base i samme linje (samme major-version og tag-form, eller samme tags nyere digest for et flydende tag), scannet af fremforge med samme sårbarhedsdatabase, har den ikke længere.

Denne analyse kører med den daglige scanning af images. Pull requesten ændrer kun den FROM-linje: tagget og det digest, fremforge scannede for det. En ændring af en anden linje eller fil, eller et andet digest end det, fremforge scannede, lukker den. Alle åbne fund i imaget, som den samme base retter, står i én pull request.

Når der ikke er nogen knap, oplyser fundet hvorfor:

Når du har merget pull requesten og pushet det genopbyggede image under samme tag, sammenligner fremforge det nye image med det gamle, når det nye er scannet. Hvert fund i det gamle digest, som det nye image ikke længere har, lukkes som rettet af fremforge (fixed_source: security_fix), så længe det gamle digest ikke er i brug: det har ikke længere noget tag, det er ikke i den seneste aktive udrulning af et repository og miljø, og ingen andre end fremforges egne bots har pullet det efter digest inden for de seneste 7 dage. Det gamle digests fund forbliver opført under det digest, så længe imaget findes i dit registry.

Hvis det gamle digest stadig er i brug, lukkes intet: fundet viser Rettet i nyere image med det nye digest og oplyser, hvorfor det forbliver åbent (stadig tagget, stadig udrullet eller pullet for nylig). Det lukkes, når det gamle digest ikke længere er i brug, og genåbnes, hvis det digest kommer i brug igen.

Efter merge

Når pull requesten er merget, og den næste scanning af standard-branchen ikke længere rapporterer et fund, lukkes fundet. Dets historik i compliance-rapporten registrerer det som rettet af en sikkerhedsrettelse (fixed_source: security_fix; rækker registreret før 2026-10-14 sagde autofix). Et fund, der lukkes af en af hostet Renovates egne sikkerheds-pull requests, registreres som fixed_source: renovate. Målinger af afhjælpning tæller begge.

Grænser

• Én aktiv bestilling pr. (repository, pakke) på hver branch. En ny bestilling af samme pakke på samme branch svarer allerede bestilt. En rettelse til en beskyttet release-branch er en separat bestilling fra standard-branchens.
• Højst 3 åbne sikkerhedsrettelses-pull requests pr. repository som standard; 0 til 10.
• Højst 20 bestillinger pr. organisation inden for vilkårlige 24 timer som standard; 0 til 50.
• En samlet pull request tæller som én i begge.

De gælder for klik og automatiske sikkerhedsrettelser tilsammen. AI-rettelse har sine egne grænser. Når der ikke åbnes en pull request, så se Fejlfinding.

API

• Bestil en rettelse POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:write (findings:write accepteres også). Body’en angiver præcis ét af:

  • finding_id: ét fund i en afhængighed. Én pull request for dens pakke. Svarer 202 med bestillingens id, målversionen, de fundnøgler, den dækker, known_exploited_cves (de kendt udnyttede CVE-id’er, den retter; tom, hvis ingen) og automerge.
  • repo: alle pakker, der kan rettes, i det repository, én pull request hver, eller én pr. lockfil i et samlet repository. Svarer 202 med ét udfald pr. pakke (queued med dens group_id, null når den ikke er samlet, eller refused med en reason), eller 200, når ingen blev sat i kø.
  • image_finding_id: en opdatering af base-imaget. Afvisninger omfatter image_not_from_base, image_no_base_fix, image_source_unknown og image_not_attributed.

  En afvisning er problem+json, hvis type er security-fix-<reason>, og som har reason, for eksempel no_fixed_version, ecosystem_not_supported, manifest_not_supported eller sbom_finding. Hver af dem er beskrevet under API-fejl.

• Vis bestillinger GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:read, med hver bestillings status og pull request.

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

• Hvem åbner sikkerheds-pull requests GET og PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane; se Overtagelse fra Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates indeholder security_fixes_bot, true når afhængighedsbotten findes til sikkerhedsrettelser. Dens enrolled betyder, at Versionsopdateringer er slået til.

• Tællere GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics: bestillinger, åbnede, mergede og lukkede pull requests, accepteringsrate, pull requests merget uden en godkendende gennemgang, og fund rettet af en sikkerhedsrettelse.

Hvert fund i en afhængighed, som GET /_app/api/v1/orgs/{org}/code-security/deps/findings returnerer, har autofix_eligible, autofix_unavailable_reason (hvorfor et fund med en rettelse ikke er dækket) og autofix, den seneste bestilling, der dækker det. Hvert image-fund fra GET .../code-security/images/findings har de samme tre felter for opdateringer af base-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"

Udfaset API

Disse stier, felter og scopes virker fortsat indtil 2027-10-15. Indtil da har hvert svar fra en udfaset sti headerne Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT og en Link-header med rel="successor-version", der nævner afløseren.

Overtagelse fra Renovate

Indtil en organisation skifter, betjener hostet Renovates egne pull requests for sårbarhedsadvarsler den ved siden af dette spor (lane_owner: renovate). Når sporet Sikkerhedsrettelser overtager (lane_owner: security_lane), åbner Renovate kun versionsopdateringer, så hver rettelse foreslås én gang. Åbne Renovate-sikkerheds-pull requests lukkes med en kommentar, der linker til den erstattende rettelses-pull request, når dette spor har en rettelses-pull request for hver pakke, de opdaterer; indtil da forbliver de åbne.

For kunder foretages skiftet indtil videre på anmodning: spørg support. fremforge skifter selv sine egne organisationer. API’et er PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane med {"lane_owner": "security_lane"} (eller "renovate" for at skifte tilbage), scope dependency-updates:write; GET på samme sti svarer med den aktuelle værdi og desuden unsupported_ecosystems (et objekt fra økosystem til antallet af åbne fund, der kan rettes, men som sporet ikke retter) og unsupported_total, så du på forhånd kan se, om et skift ville blive afvist. Overtagelsen afvises, medmindre sporet kan handle:

• Sikkerhedsrettelser er Fra: 409 security-lane-lane-off. Vælg først en anden tilstand end Fra, eller send "acknowledge": ["no_security_prs"] for at acceptere, at der slet ikke åbnes sikkerheds-pull requests.
• Åbne fund i økosystemer, som sporet ikke retter (for eksempel CRAN eller Conan, som Renovates advarsler dækker): 409 security-lane-unsupported-ecosystems, hvis unsupported_ecosystems viser de åbne fund, der kan rettes, pr. økosystem. Send "acknowledge": ["unsupported_ecosystems"] for at skifte alligevel; de fund får så ingen automatisk pull request.

Ved skiftet begynder sikkerhedsrettelses-pull requests at følge Hvornår rettelser merges i organisationer, hvor de indtil da ventede på gennemgang; se Merging.

Skiftet registreres i revisionsloggen som dependency-updates.security-lane.enabled, og et skift tilbage som dependency-updates.security-lane.disabled.

Revision

Hvert trin står i revisionsloggen: autofix.proposed, autofix.pr_opened, autofix.rejected (med årsagen), autofix.relocked (et lockfil-commit fra din egen CI, med kørslen), autofix.relock_refused (et job-token, der ikke var fra den startede kørsel), autofix.merged og autofix.closed, hver med fundnøglerne og engine: deterministic. autofix.proposed for en kendt udnyttet rettelse har også knownExploitedCves. En ændring af indstillingerne er dependency-updates.security-fixes.updated.

AI-rettelser til SAST-fund

AI-genererede rettelser til SAST-fund er flyttet til deres egen side: AI-rettelse.

Se også

• Opdateringer af afhængigheder: begge spor og botten.
• Merging: gennemgang, merge når tjek er grønne, merge-vinduet og release-frysningen.
• Fejlfinding: når der ikke åbnes en pull request.
• OSV-anbefalinger: de kort, som knappen Åbn rettelses-PR sidder på.
• Tjekliste til opsætning: dine grænser og tilvalg samlet under Sikkerhed › Overblik.