Sicherheitskorrekturen

Eine Sicherheitskorrektur macht aus einem Abhängigkeitsbefund einen Pull Request. Klicke bei einem Befund oder auf einer Karte unter Empfehlungen auf Korrektur-PR öffnen oder rufe die API auf, und der Abhängigkeits-Bot deiner Organisation öffnet einen Pull Request in diesem Repository. Er hebt das Paket auf die niedrigste veröffentlichte Version an, die jede offene Advisory dazu behebt. Das ist der Weg Sicherheitskorrekturen der Abhängigkeits-Updates, unter Sicherheit › Beheben › Abhängigkeits-Updates.

Sicherheitskorrekturen decken Abhängigkeiten aus npm (einschließlich Yarn, pnpm und Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex und CRAN (R) sowie CI-Action-Versionen (GitHub Actions) ab, in den Manifesten, die unter Ökosysteme und Manifeste aufgeführt sind. Andere Ökosysteme antworten mit not yet supported. Die vollständige Liste steht unter Unterstützte Ökosysteme. Es ist kein KI-Modell beteiligt: Das Upgrade wird aus den OSV-Advisory-Datensätzen berechnet.

Für eine Schwachstelle in einem Image, das in deine Registry gepusht wurde und die mit der FROM-Basis des Images kam, hebt Korrektur-PR für Basis-Image öffnen diese Basis an, sobald fremforge geprüft hat, dass die neuere Basis sie nicht mehr enthält. Siehe Basis-Image-Upgrades. Alle in diesem Repository beheben fordert jedes behebbare Paket eines Repositorys auf einmal an: siehe Alles Behebbare in einem Repository beheben.

Sicherheitskorrekturen hießen bis zum 2026-10-14 AutoFix. AutoFix ist kein Produktname mehr: KI-generierte Korrekturen für SAST-Befunde sind die KI-Korrektur. Die Audit-Ereignisse autofix.* und die veralteten API-Pfade tragen noch den alten Namen. Pull Requests, die vor der Umstellung geöffnet wurden, behalten ihren Branch autofix/; fremforge versieht die noch offenen mit dem Label security-fix.

Einstellungen

Ein Owner legt sie unter Sicherheit › Beheben › Abhängigkeits-Updates › Sicherheitskorrekturen fest oder mit PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Jedes Feld ist bei einem PUT optional; ein weggelassenes behält seinen Wert, und es wird nichts gespeichert, wenn ein Feld abgewiesen wird.

Die Modi:

• Aus (off): keine Pull Requests für Sicherheitskorrekturen, weder per Klick noch automatisch.
• Per Klick (on_click): Eine Person fordert sie an, mit Korrektur-PR öffnen, Alle in diesem Repository beheben oder Korrektur-PR für Basis-Image öffnen, oder über die API.
• Automatisch für wichtige Befunde (auto_important): wie per Klick, und fremforge öffnet sie zusätzlich von selbst für hohe und kritische Befunde, die erreichbar oder bekanntermaßen ausgenutzt sind. Mit Auch Befunde mit unbekannter Erreichbarkeit zählen auch hohe und kritische Befunde ohne Erreichbarkeitsurteil. Siehe Automatische Sicherheitskorrekturen.
• Automatisch für alle hohen und kritischen (auto_high_critical): fremforge öffnet sie von selbst für jeden hohen und kritischen Befund, den es beheben kann, unabhängig von seiner Erreichbarkeit.
• Automatisch für kritische und bekannt ausgenutzte (auto_critical_exploited): fremforge öffnet sie von selbst für jeden kritischen Befund, unabhängig von seiner Erreichbarkeit, und für jeden bekanntermaßen ausgenutzten Befund jedes Schweregrads. Ein hoher, mittlerer oder niedriger Befund, der nicht bekanntermaßen ausgenutzt wird, wartet auf einen Klick. Das ist der Standard für eine Organisation, die am oder nach dem 2026-10-27 angelegt wurde; siehe Neue Organisationen.

Die Antwort enthält außerdem schreibgeschützte Felder. configured ist false, solange die Organisation die Einstellungen nie gespeichert hat und die Werte die Standardwerte sind (bei einer neuen Organisation die Standardwerte, mit denen sie angelegt wurde). lane_owner sagt, wer Sicherheits-Pull-Requests öffnet: renovate, solange die eigenen Sicherheits-Pull-Requests von gehostetem Renovate die Organisation noch bedienen, security_lane, sobald dieser Weg übernommen hat. high_blast_radius_exempt ist true für Organisationen, deren Renovate-Sicherheits-Pull-Requests sich vor dem 2026-10-14 selbst gemergt haben und auf Zusammenführen, wenn die Prüfungen bestehen umgestellt wurden; siehe Mergen.

Eine Änderung wird im Audit-Log als dependency-updates.security-fixes.updated erfasst, mit dem alten und neuen Wert jedes Felds.

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"

Sicherheitskorrekturen brauchen keine Versions-Updates. Die erste Korrekturanforderung (Korrektur-PR öffnen, Alle in diesem Repository beheben, Korrektur-PR für Basis-Image öffnen oder POST .../security-fixes/requests) oder das Speichern eines automatischen Modus richtet den Abhängigkeits-Bot deiner Organisation <org>-fremforge-bot-deps ein, wobei die Versions-Updates ausgeschaltet bleiben. Ein Repository, das sich von den Abhängigkeits-Updates abgemeldet hat, bekommt keine Korrektur-Pull-Requests, und ein archiviertes oder gespiegeltes Repository wird abgewiesen (repo_archived).

Was passiert, wenn du auf Korrektur-PR öffnen klickst

1. fremforge sammelt jeden offenen Befund auf dem Standard-Branch zum selben Paket im selben Repository. Ein Pull Request schließt sie alle.
2. Es berechnet die Zielversion. Für jede installierte Version ist das die niedrigste veröffentlichte Version außerhalb jedes betroffenen Bereichs jeder offenen Advisory. Der Pull Request nimmt die höchste davon, sodass er die ganze Gruppe behebt.
3. Ein gezielter Lauf von gehostetem Renovate startet, als Abhängigkeits-Bot deiner Organisation. Er ist auf dieses eine Paket und diese eine Version beschränkt. Jede andere Abhängigkeit bleibt unberührt.
4. Renovate öffnet den Pull Request auf einem Branch security-fix/<package>-<version>. Läufe für Sicherheitskorrekturen haben Vorrang vor gewöhnlichen Renovate-Läufen, sodass das meist weniger als 15 Minuten dauert. Der Pull Request trägt das Label security-fix. Hat das Repository dieses Label noch nicht, legt fremforge es vor dem Lauf einmalig an; ein bereits vorhandenes Label bleibt, wie es ist. Lässt sich ein Label nicht anlegen, wird der Pull Request ohne es geöffnet.
5. fremforge prüft den Pull Request, bevor es ihn offen lässt. Er darf nur die Manifeste und Lockfiles des Ökosystems ändern (siehe Tabelle unten) und in einem Manifest nur den Eintrag dieses Pakets. Eine Änderung an einer anderen Datei, eine neue direkte Abhängigkeit, das Anheben eines anderen Pakets, eine geteilte Version oder eine Lockfile, deren Pakete nun aus einem anderen Index stammen, schließt den Pull Request und löscht seinen Branch. Dasselbe gilt für eine fehlgeschlagene Aktualisierung der Lockfile: Ein Pull Request mit veralteter Lockfile würde nicht bauen.

Der Befund zeigt dann Fix vorgeschlagen: #N mit dem Zustand des Pull Requests: offen, gemergt oder geschlossen.

Jede Kopie auf dem Stand der Korrektur. Eine Lockfile kann mehrere Kopien eines Pakets enthalten: eine direkte und ältere, die unter anderen Abhängigkeiten verschachtelt sind. Bevor ein Pull Request als Korrektur zählt, liest fremforge seine Lockfiles am Head des Pull Requests und prüft jede darin verzeichnete Kopie des Pakets gegen die korrigierte Version. Das gilt für package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock, Cargo.lock, go.mod und NuGets packages.lock.json, für einzelne wie für gebündelte Korrekturen. Eine Vorabversion der korrigierten Version zählt als darunter.

• Jede Kopie auf oder über der Korrektur: Der Pull Request behebt das Paket.
• Einige Kopien behoben, eine ältere übrig: Der Pull Request bleibt offen, und die Konsole nennt die übrigen Kopien (in der API das lock_copies_left der Anforderung, mit reason target_partly_reached). Fix vorgeschlagen erscheint nur bei den Befunden der Kopien, die er behebt; die anderen behalten ihre Schaltfläche Fix.
• Keine Kopie auf dem Stand der Korrektur, zum Beispiel eine transitive Kopie, die sich mit ihrem Elternpaket bewegt hat, aber auf eine Version, die noch verwundbar ist: Das Paket gehört nicht zum Pull Request. Seine Anforderung endet als target_not_reached, und die transitive Korrektur legt es eigenständig fest. Ein Pull Request, der kein behobenes Paket mehr enthält, wird geschlossen.

Ein Lockfile-Format, das hier nicht aufgeführt ist, wird wie bisher geprüft: Der Pull Request muss das Paket in der Lockfile ändern.

Was diese Prüfung nicht leistet:

• Nur die Lockfiles, die der Pull Request ändert, werden gelesen. Enthält eine andere Lockfile im Repository, die der Pull Request unberührt lässt, noch eine verwundbare Version, bleibt dieser Befund nach dem Merge offen. Er wird nicht als behoben ausgegeben: Seine Schaltfläche Fix bleibt.
• Eine zurückgebliebene Kopie wird nach dem Merge behoben, nicht gleichzeitig. Solange der Pull Request offen ist, wird eine neue Anforderung für dasselbe Paket abgewiesen, weil bereits eine offen ist, sodass Fix bei einer zurückgebliebenen Kopie noch nichts startet. Fordere es nach dem Merge und dem nächsten Scan erneut an.
• Dieselbe Version, direkt und verschachtelt. Ein Befund wird über Paket und Version identifiziert, nicht darüber, wo im Baum die Kopie liegt. Hebt der Pull Request die direkte Kopie an, ist dieselbe alte Version aber noch unter einer anderen Abhängigkeit verschachtelt, ist dieser Befund nicht behoben; die Anforderung endet dann als target_not_reached, und ihr Pull Request wird geschlossen. Die transitive Korrektur weist ein Paket ab, das dein Manifest direkt nennt, also lege die verschachtelte Kopie selbst fest (zum Beispiel mit einem npm-Eintrag overrides).

Die Renovate-Einstellungen deines Repositorys

Die eigene renovate.json eines Repositorys (oder .renovaterc, oder der Schlüssel renovate in package.json) prägt seine Versions-Updates. Eine Sicherheitskorrektur hält sie nicht zurück. Ein Lauf für eine Sicherheitskorrektur ignoriert im Repository:

• packageRules, einschließlich einer Regel mit "enabled": false für das Paket;
• ignoreDeps;
• ignorePaths und includePaths. Übersprungen werden nur node_modules und bower_components;
• enabledManagers. Der Lauf verwendet die Manager für das Ökosystem des Befunds.

Um ein Paket aus den Sicherheitskorrekturen herauszuhalten, erfasse eine Ausnahme für seine Befunde: Verwirf sie mit einer Begründung und möglichst mit einem Ablaufdatum, oder beantrage eine freigegebene Ausnahme. Ein Befund mit Ausnahme ist nicht offen, also wird für ihn keine Korrekturanforderung gestellt, und Korrektur-PR öffnen antwortet mit security-fix-not-open. Anders als eine Halteregel in einer Datei ist eine Ausnahme auf der Seite Ausnahmen sichtbar, nennt, wer sie warum angelegt hat, und erlischt an ihrem Ablaufdatum.

Zwei Einstellungen gelten weiterhin:

• Ein "enabled": false auf oberster Ebene in renovate.json schaltet Renovate für das ganze Repository aus, einschließlich der Sicherheitskorrekturen.
• packageRules eines Repositorys, die registryUrls oder andere Lookup-Einstellungen setzen, gelten nicht für einen Lauf einer Sicherheitskorrektur. Der Lauf sucht Pakete über die eigenen Einstellungen deiner Organisation und den Dependency-Proxy.

Bekanntermaßen ausgenutzte Schwachstellen zuerst

Hat eine Advisory, die eine Anforderung behebt, eine CVE, die in der EU-Schwachstellendatenbank der ENISA (EUVD) oder im Katalog Known Exploited Vulnerabilities der CISA (KEV) als aktiv ausgenutzt gelistet ist, wird die Korrektur als die dringendste behandelt:

• Sie läuft zuerst. Ihr Renovate-Lauf kommt vor jeder anderen wartenden Anforderung einer Sicherheitskorrektur dran, egal in welcher Reihenfolge sie angefordert wurden.
• Sie steht bei Alle beheben vorn. Ein Stapel Alle in diesem Repository beheben nimmt bekanntermaßen ausgenutzte Pakete vor den übrigen auf, danach nach Schweregrad, sodass bei Erreichen eines Limits ein weniger dringendes Paket draußen bleibt.
• Sie wartet nicht auf das Release-Alter. Dein Release-Alter hält andere Korrekturen zurück, aber eine Version, die eine bekanntermaßen ausgenutzte Schwachstelle behebt, wird sofort vorgeschlagen.
• Der Pull Request sagt es. Der Titel endet auf known exploited, zum Beispiel fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), die Beschreibung beginnt mit den CVEs und den Listen, die sie nennen, und der Pull Request trägt zusätzlich das Label known-exploited, das genauso angelegt wird wie security-fix.

Eine CVE zählt, wenn sie die eigene ID der Advisory oder einer ihrer Aliasse ist (eine GHSA- oder PYSEC-Advisory hat meist einen CVE-Alias). Beide Listen werden gespiegelt und täglich aktualisiert. Ob eine Anforderung bekanntermaßen ausgenutzt ist, wird bei ihrer Erstellung entschieden; die API gibt es als known_exploited_cves an. Mit Zusammenführen, wenn die Prüfungen bestehen wird sie auch außerhalb deines Merge-Fensters scharfgeschaltet; siehe Mergen. Die Limits gelten weiterhin.

Automatische Sicherheitskorrekturen

Mit Automatisch für wichtige Befunde, Automatisch für alle hohen und kritischen oder Automatisch für kritische und bekannt ausgenutzte öffnet fremforge dieselben Pull Requests wie ein Klick auf Korrektur-PR öffnen oder Korrektur-PR für Basis-Image öffnen, ohne dass jemand klickt, für jeden Befund, der alle folgenden Bedingungen erfüllt:

1. Er ist auf dem Standard-Branch offen: nicht verworfen, nicht an einem Pull Request gemeldet.
2. Sein Schweregrad ist hoch oder kritisch. Mittlere und niedrige Befunde werden nur mit Automatisch für kritische und bekannt ausgenutzte automatisch behoben, und nur, wenn sie bekanntermaßen ausgenutzt werden.
3. Mit Automatisch für wichtige Befunde: Er ist erreichbar (sein Erreichbarkeits-Urteil ist reachable) oder bekanntermaßen ausgenutzt (eine seiner CVEs ist in ENISA EUVD oder CISA KEV gelistet), oder er hat, mit Auch Befunde mit unbekannter Erreichbarkeit, kein oder ein unbekanntes Urteil. Ein bekanntermaßen ausgenutzter Befund qualifiziert sich auch dann, wenn er nicht erreichbar ist. Mit Automatisch für alle hohen und kritischen qualifiziert sich jeder hohe und kritische Befund. Mit Automatisch für kritische und bekannt ausgenutzte qualifiziert sich ein kritischer Befund unabhängig von seiner Erreichbarkeit, ein bekanntermaßen ausgenutzter Befund bei jedem Schweregrad, und sonst nichts.
4. fremforge kann ihn deterministisch beheben: eine Abhängigkeit in einem abgedeckten Ökosystem und Manifest mit veröffentlichter Korrektur oder ein Image-Befund, den ein Basis-Image-Upgrade behebt.

Um es zunächst an einigen Repositorys auszuprobieren, trage sie unter Repositorys ein. Eine leere Liste deckt jedes Repository der Organisation ab. Das Sicherheits-Beispiel-Repository wird nie automatisch korrigiert; ein Klick auf Korrektur-PR öffnen funktioniert dort trotzdem.

Neue Organisationen

Eine Organisation, die am oder nach dem 2026-10-27 angelegt wurde, startet mit Automatisch für kritische und bekannt ausgenutzte und mit Wann Korrekturen gemergt werden auf Auf Review warten: Korrektur-Pull-Requests öffnen sich von selbst, und keiner wird ohne eine Person gemergt. Die Limits, die Bündelung und das Release-Alter behalten ihre Standardwerte. Nichts wird in Versions-Updates aufgenommen: Der Abhängigkeits-Bot <org>-fremforge-bot-deps wird erst angelegt, wenn sich der erste Befund qualifiziert. Ein Owner kann jederzeit auf jeden anderen Modus umstellen, auch auf Aus, oder ihn erweitern. Organisationen, die vor dem 2026-10-27 angelegt wurden, behalten ihre bisherige Einstellung.

Wann es handelt

fremforge prüft alle 10 Minuten. Ein Befund wird bald nach seiner Qualifizierung vorgeschlagen: wenn ein Scan einen neuen Befund meldet, wenn sein Urteil zu erreichbar wird oder wenn die tägliche Aktualisierung der bekanntermaßen ausgenutzten Schwachstellen eine seiner CVEs hinzufügt. Befunde, die sich beim Einschalten bereits qualifizieren, werden im Rahmen der Limits ebenfalls berücksichtigt.

Was gleich bleibt

Jede automatische Anforderung nimmt genau den Weg eines Klicks: ein Pull Request pro Paket (oder pro Basis-Image), die niedrigste behebende Version, die Limits deiner Organisation, das Zurückhalten nach Release-Alter, die Ablehnung bei geteilten Versionen und die Prüfungen des Umfangs. In der Liste der Anforderungen hat eine solche Anforderung "trigger": "policy", und ihr Pull Request sagt, dass er automatisch geöffnet wurde.

• Er wird so gemergt, wie du es eingestellt hast. Wie jeder Pull Request einer Sicherheitskorrektur folgt er Wann Korrekturen gemergt werden; siehe Mergen.
• Er verwendet nie KI. Automatisch läuft nur die deterministische Engine. Die KI-Korrektur beginnt immer mit dem Klick einer Person auf einen einzelnen Befund.
• Eine Häufung wartet, bis sie dran ist. Fügt die Liste der bekanntermaßen ausgenutzten Schwachstellen eine CVE hinzu, die viele deiner Repositorys betrifft, öffnet fremforge so viel, wie deine Limits erlauben, bekanntermaßen ausgenutzte und kritische zuerst, und den Rest später, sobald Pull Requests gemergt oder geschlossen werden und das 24-Stunden-Fenster weiterrückt. Es öffnet nie mehr, als die Limits zulassen.
• Ein geschlossener Pull Request bleibt geschlossen. Schließt jemand einen Pull Request einer Sicherheitskorrektur ohne Merge, öffnet fremforge ihn für dieselben Befunde und dieselbe Zielversion nicht erneut. Ein neuer qualifizierender Befund zu diesem Paket oder eine neuere Zielversion ist ein neuer Grund und kann vorgeschlagen werden. Eine Anforderung, die ohne Pull Request endete (zum Beispiel Wartet auf das Release-Alter), wird nach 24 Stunden erneut versucht.

Automatisch gestellte Anforderungen werden als autofix.proposed erfasst, mit source: policy, dem Akteur system:autofix-policy und qualifiedBy (known_exploited, reachable, unknown oder severity).

Ökosysteme und Manifeste

Noch nicht abgedeckt, und das sagt der Befund auch:

• Andere JVM-Build-Werkzeuge (Ivy, sbt): Der Befund zeigt Manifest nicht abgedeckt.
• bun.lockb, die binäre Lockfile von Bun, die nur Bun neu schreiben kann. Führe einmal bun install --save-text-lockfile aus, um auf bun.lock umzustellen.
• Bun-Pakete, die das Manifest nicht nennt: Der Lauf endet mit no change.
• pub-Pakete, die das Manifest nicht nennt: Der Lauf endet mit no change.
• Befunde aus einer hochgeladenen SBOM (Manifest sbom:<name>): Es gibt keine Datei im Repository, die geändert werden könnte. Der Befund zeigt Aus einer SBOM.
• Conan (conan.lock): OSV, woraus das Abhängigkeits-Scanning seine Advisories liest, veröffentlicht keine für Conan-Pakete, also gibt es keine Conan-Schwachstelle zu beheben.

Ein Paket, das nur eine transitive Abhängigkeit ist (in der Lockfile, aber nicht in einem Manifest), wird von der Wurzel deines Projekts aus festgelegt: ein npm-Eintrag overrides, ein Maven-Eintrag <dependencyManagement> oder die Zeile // indirect in go.mod. Siehe Transitive Abhängigkeiten.

Aktualisierung der Lockfile

Die Lockfile wird vom Paketmanager selbst aktualisiert (uv lock, poetry lock, dotnet restore, cargo update, composer update --no-scripts --no-plugins, dart pub upgrade, bun install --ignore-scripts und so weiter), ohne je die eigenen Skripte oder Plugins des Repositorys auszuführen, als Renovate-Bot deiner Organisation und in derselben Sandbox von gehostetem Renovate wie seine gewöhnlichen Updates. Eine Aktualisierung verschiebt Pakete nie in einen anderen Index: Eine Python- oder Cargo-Lockfile, deren Pakete danach aus einem anderen Index stammen würden, wird abgewiesen. Scheitert die Aktualisierung, zum Beispiel weil das Repository einen privaten Index nennt, den der Bot nicht lesen kann, wird der Pull Request als PR geschlossen: Lockfile fehlgeschlagen geschlossen, statt mit einer veralteten Lockfile offen zu bleiben.

Der Dependency-Proxy deiner Organisation als Index. Nennen die Manifeste, Lockfiles oder die Werkzeugkonfiguration des Repositorys den eigenen Dependency-Proxy deiner Organisation (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...), authentifiziert sich die Aktualisierung dort als dein Renovate-Bot. Das gilt für jeden Renovate-Lauf dieses Repositorys, nicht nur für fremforge. Die Zugangsdaten werden genau für die Proxy-Pfade deiner Organisation vergeben, die das Repository nennt, und für nichts anderes: Ein Index von uv, Poetry oder Pipenv und eine Quelle in nuget.config erhalten sie über Renovates eigene Verwaltung von Zugangsdaten, Cargo über einen Credential-Provider, der nur für den Cargo-Proxy deiner Organisation antwortet. (Ein Gradle-Build wird hier überhaupt nicht aktualisiert; siehe Gradle.) Die Zugangsdaten liegen in Dateien dieses einen Laufs, nie im Repository, nie in der Umgebung und nie in Logs.

Gradle

fremforge führt nie den Build deines Repositorys aus. Eine Gradle-Lockfile zu aktualisieren, heißt, deinen Gradle-Wrapper und deine Build-Skripte auszuführen, daher wird die Arbeit bei einem Gradle-Befund aufgeteilt:

1. fremforge ändert nur die Version. Renovate bearbeitet build.gradle(.kts), den Versionskatalog oder gradle.properties, mit denselben Prüfungen des Umfangs und der geteilten Versionen wie bei jedem Pull Request einer Sicherheitskorrektur, und öffnet den Pull Request, ohne die Lockfiles anzufassen. Kein Renovate-Lauf, weder von fremforge noch ein gewöhnlicher, führt Code des Repositorys aus.
2. Deine eigene CI aktualisiert die Lockfiles. Hat der Build *.lockfile-Dateien oder gradle/verification-metadata.xml, committet fremforge einen generierten Workflow, .forgejo/workflows/fremforge-autofix-relock.yaml, auf einen Wegwerf-Branch autofix-relock/<request> (mit [skip ci], sodass keiner deiner eigenen Workflows darauf läuft) und startet ihn einmal auf dem gehosteten Runner deiner Organisation (runs-on: fremforge): eine kurzlebige VM dieses Commits. Er zählt nicht zu den CI-Minuten deiner Organisation: fremforge vermerkt den Lauf, den es gestartet hat, und lässt ihn aus deiner Nutzung und deiner Rechnung heraus. Während er läuft, belegt er allerdings einen deiner gleichzeitigen Job-Slots. Du musst dein Repository nicht ändern. Der Lauf erscheint im Tab Actions des Repositorys.
3. Der Job führt dieselben Befehle aus wie Renovates Gradle-Manager: gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, und --write-verification-metadata, wenn der Build Abhängigkeiten verifiziert. Er wählt ein JDK vom Runner (21, sonst 17), gibt den Egress-Proxy des Runners an die JVM weiter und liest den Dependency-Proxy deiner Organisation mit dem eigenen Token des Jobs über die Properties fremforgeUsername und fremforgePassword. Er hat keine Schreibberechtigung: Seine Berechtigungen sind contents: read, packages: read und id-token: write.
4. fremforge prüft und committet das Ergebnis. Der Job sendet die geänderten Lock- und Verifikationsdateien mit einem Job-Token für die Audience fremforge:autofix-relock an fremforge, das fremforge nur von genau diesem Lauf akzeptiert. fremforge weist alles ab, was keine Gradle-Lock- oder Verifikationsdatei des neu gelockten Builds ist, eine Lockfile, die noch die verwundbare Version festlegt, oder einen Branch, der sich zwischenzeitlich geändert hat. Dann fügt es die Dateien dem Pull Request der Sicherheitskorrektur als einen Commit deines Renovate-Bots hinzu, sodass deine Pull-Request-CI darauf läuft, prüft, dass der Pull Request nur Gradle-Build-Dateien und Lockfiles ändert, und löscht den Wegwerf-Branch. Der Status fremforge/autofix-relock am Pull Request verlinkt den Lauf.

Ein Build ohne Lockfiles bekommt nur die Versionsänderung, und es läuft kein Job.

Scheitert der Job, wird er abgebrochen, meldet er sich nicht oder ist er 90 Minuten nach dem Start nicht fertig (zum Beispiel weil die Runner-Minuten der Organisation aufgebraucht sind), wird der Pull Request als PR geschlossen: Lockfile fehlgeschlagen mit einem Link auf den Lauf geschlossen. Reviewe einen Gradle-Pull-Request erst, wenn der Lockfile-Commit eingetroffen ist; bis dahin sind seine Lockfiles veraltet. Mit Zusammenführen, wenn die Prüfungen bestehen wird eine Gradle-Korrektur nicht scharfgeschaltet, solange die Aktualisierung ihrer Lockfile aussteht oder committet wird; sie wird scharfgeschaltet, sobald der Lockfile-Commit gelandet ist und ihre Checks bestehen. Wenn du sie von Hand mergst, warte auf den Lockfile-Commit.

RubyGems, Hex, CRAN und Composer-Pakete, die composer.json nicht nennt

Bundler liest die Gemfile und Mix liest mix.exs, um sie zu locken, und beides ist Code (Ruby, Elixir), daher führt fremforge Bundler oder Mix nie selbst aus. Zum Aktualisieren von renv.lock braucht es R, das weder fremforge noch Renovate ausführt. Renovate aktualisiert nur die Composer-Pakete, die composer.json nennt. Für diese Korrekturen wird die Lockfile in deiner eigenen CI aktualisiert, genauso wie bei einer Gradle-Aktualisierung, und der Pull Request wird erst geöffnet, wenn sie eingetroffen ist:

1. Deine eigene CI aktualisiert die Lockfile. fremforge committet den generierten Workflow .forgejo/workflows/fremforge-autofix-relock.yaml auf einen Wegwerf-Branch autofix-relock/<request>, der vom Head des Basis-Branches abzweigt (mit [skip ci]), und startet ihn einmal auf dem gehosteten Runner deiner Organisation, ohne ihn auf deine CI-Minuten anzurechnen. Im Verzeichnis der Lockfile führt er bundle lock --update <gem> --conservative --patch|--minor|--major --strict aus (die kleinste Stufe, die die Korrektur erreicht, mit dem Ruby aus .ruby-version oder der Lockfile und der Bundler-Version, mit der die Lockfile geschrieben wurde), mix deps.update <package> im offiziellen Image elixir (die Version, die deine .tool-versions nennt, sonst die aktuelle; deine Runner haben kein Elixir), das R-Skript von fremforge im Image rocker/r-ver mit der R-Version, die renv.lock verzeichnet (siehe CRAN unten), oder composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Es wird nichts installiert, und kein Gem- oder Paket-Skript läuft. Er hat keine Schreibberechtigung. Während er läuft, zeigt der Befund Fix angefordert.
2. Das Release-Alter wird im Job geprüft. Sofern die Korrektur nicht einer bekanntermaßen ausgenutzten Schwachstelle gilt, liest der Job den Veröffentlichungszeitpunkt der gelockten Version von rubygems.org, hex.pm oder repo.packagist.org oder, bei CRAN, aus dem Feld Date/Publication des Pakets selbst; eine Version, die jünger ist als das Release-Alter deiner Organisation, beendet die Anforderung mit Noch kein PR: zu neu, und sie wird nach 24 Stunden erneut versucht.
3. fremforge prüft die Lockfile und öffnet den Pull Request. Der Job sendet die eine Lockfile mit einem Job-Token für genau diesen Lauf zurück. fremforge weist eine Lockfile ab, in der sich außer den gelockten Versionen etwas geändert hat (Quellen, Plattformen, Abhängigkeiten, die Bundler-Version, Composers content-hash, eine Git- oder Pfad-Abhängigkeit in mix.lock, in renv.lock alles außer dem eigenen Datensatz dieses Pakets), eine, die die korrigierte Version nicht festlegt, oder eine, die noch die verwundbare Version festlegt. Dann committet es sie als dein Renovate-Bot auf den Branch der Sicherheitskorrektur, der vom Basis-Branch abzweigt, öffnet den Pull Request mit dem üblichen Titel, der üblichen Beschreibung und den üblichen Labels und löscht den Wegwerf-Branch. Ab dann ist es ein gewöhnlicher Pull Request einer Sicherheitskorrektur.

Scheitert der Job, wird er abgebrochen, meldet er sich nicht oder ist er 90 Minuten nach dem Start nicht fertig, wird kein Pull Request geöffnet, und die Anforderung endet mit Kein PR: Lockfile-Aktualisierung fehlgeschlagen, mit dem Grund und einem Link auf den Lauf.

CRAN

Eine CRAN-Korrektur ändert genau einen Datensatz von renv.lock und sonst nichts. Der Job installiert die renv-Version, mit der renv.lock geschrieben wurde, sodass die Datei ihr Format behält, und liest die DESCRIPTION der korrigierten Version aus dem Paket-Repository, das renv.lock nennt. Er installiert nie dein Projekt und führt nie dessen Code aus. Er bricht mit Begründung ab, wenn:

• die korrigierte Version ein Paket (Depends, Imports oder LinkingTo) braucht, das renv.lock nicht festlegt oder unterhalb der benötigten Version festlegt;
• die korrigierte Version eine andere R-Version braucht als die, die renv.lock verzeichnet;
• die DESCRIPTION deines Projekts das Paket unterhalb der Korrektur begrenzt, zum Beispiel Imports: commonmark (<= 1.8);
• die korrigierte Version jünger ist als das Release-Alter deiner Organisation.

Aktualisiere in jedem dieser Fälle die Pakete zusammen mit renv in deinem Projekt (renv::update(), dann renv::snapshot()). Andernfalls erhält der Datensatz die neue Version, ihre Abhängigkeiten und den Hash von renv, und fremforge akzeptiert die Datei nur, wenn jeder andere Datensatz, die R-Version und die Repositorys unverändert sind.

Geteilte Versionen

Eine Version, die an einer Stelle gepflegt und von mehreren Abhängigkeiten gelesen wird, etwa eine pom.xml-Property (<logback.version>), eine Gradle-Variable in gradle.properties oder ein Eintrag im Versionskatalog ([versions] logback = "1.5.12"), bewegt beim Anheben jede dieser Abhängigkeiten mit. fremforge liest jede pom.xml bzw. jede Gradle-Build-Datei und jeden Katalog im Pull Request.

Eine pom.xml-Property wird angehoben, wenn das Anheben für jeden Leser richtig ist. Jede andere Abhängigkeit, die sie liest, muss im Repository offene Schwachstellen haben (auf dem Standard-Branch), auf oder unterhalb der neuen Version behoben sein und in dieser Version im Maven-Proxy deiner Organisation veröffentlicht sein. Der Pull Request listet diese Abhängigkeiten dann unter Also updated by this pull request auf und schließt ihre Befunde beim Merge. Würden zwei Korrekturanforderungen dasselbe Anheben vornehmen, behält es die Anforderung für das Paket, das zuerst einsortiert wird, und die andere endet mit PR geschlossen: geteilte Version und nennt sie.

Andernfalls, und immer bei einer Gradle-Variablen oder einem Katalogeintrag, bei einer Korrektur auf einem Release-Branch oder bei einer Version, die auf eine Weise gelesen wird, die fremforge keiner Abhängigkeit zuordnen kann, wird der Pull Request als PR geschlossen: geteilte Version geschlossen, und das detail der Anforderung sagt, welcher Leser welche Bedingung nicht erfüllt hat (keine offene Schwachstelle, keine korrigierte Version, braucht eine höhere Version, in der neuen Version nicht veröffentlicht). Hebe die geteilte Version dann selbst an, sodass du die Version für alle wählst: Die Korrektur des verwundbaren Pakets gibt es womöglich nicht als Release der anderen (eine Bibliotheksfamilie liefert oft nur für ein Artefakt ein Patch-Release). Eine Version, die nur das verwundbare Paket liest, wird wie gewohnt angehoben.

Alles Behebbare in einem Repository beheben

Unter Empfehlungen hat jedes Repository mit zwei oder mehr Paketen, die fremforge jetzt beheben kann, eine Schaltfläche Alle in diesem Repository beheben. Sie fordert einen Pull Request pro Paket an (und pro Basis-Image, siehe unten) bzw. in einem Repository, das seine Korrekturen bündelt, einen pro Lockfile, bekanntermaßen ausgenutzte zuerst, dann nach höchstem Schweregrad. Die Anforderungen werden gemeinsam unter deinen Limits aufgenommen: Hat ein Repository 3 offene Pull Requests für Sicherheitskorrekturen oder hat deine Organisation ihre 20 Anforderungen für den Tag aufgebraucht, wird der Rest nicht angefordert, und das Ergebnis sagt, wie viele es waren. Ein Paket, für das bereits eine Anforderung besteht, wird übersprungen.

Mit der API: POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests mit {"repo": "<name>"} antwortet mit 202 und einem Ergebnis pro Paket (queued oder refused mit einem reason) oder mit 200, wenn nichts eingereiht wurde.

Gebündelte Korrekturen

In einem Repository, das unter Gebündelte Repositorys (grouped_repos) aufgeführt ist, kommen die Korrekturen einer Lockfile in einen Pull Request, wie bei Dependabot-Gruppen, statt in einen pro Paket. Jedes andere Repository behält einen Pull Request pro Paket, und standardmäßig gilt das für jedes Repository.

• Was gebündelt wird: Pakete einer Lockfile (ein Ökosystem, ein Manifest, ein Basis-Branch), deren Korrektur innerhalb der installierten Major-Version bleibt, in npm (mit pnpm und Yarn), PyPI, Go, Cargo und NuGet. Höchstens 20 Pakete kommen in eine Gruppe; weitere bilden eine zweite.
• Was nicht: eine Korrektur, die eine neue Major-Version braucht, ein Basis-Image, eine Festlegung einer CI-Action sowie Gradle-, Maven-, Composer-, RubyGems-, Hex- und CRAN-Pakete. Jedes davon ist wie bisher ein eigener Pull Request.
• Wann: Alle in diesem Repository beheben und automatische Sicherheitskorrekturen. Ein einzelnes Korrektur-PR öffnen bei einem Befund bleibt ein Pull Request für dieses Paket.
• Limits: Eine Gruppe zählt als ein Pull Request bei Offene Korrektur-Pull-Requests pro Repository und als eine Anforderung bei Korrektur-Pull-Requests pro Tag. Ein Paket, das bereits eine eigene Anforderung hat oder in den letzten 10 Minuten versucht wurde, bleibt aus der Gruppe heraus, statt wiederholt zu werden.
• Jedes Paket behält seine eigene Anforderung. Der Pull Request listet jedes Paket mit seiner korrigierten Version auf, und die Befunde jedes Pakets werden beim Merge geschlossen, wie bei einer einzelnen Korrektur. Ein Paket, das der Lauf nicht zusammen mit den anderen aktualisieren konnte oder nur auf eine Version unterhalb seiner Korrektur (siehe Jede Kopie auf dem Stand der Korrektur unter Was passiert, wenn du auf Korrektur-PR öffnen klickst), bleibt draußen und wird im Pull Request genannt. Es behält seine eigene Anforderung: Eine, die auf ihr Release-Alter wartet, wird später erneut angefordert, und ein Paket, das das Manifest nicht nennt (eine transitive Abhängigkeit), wird eigenständig von der transitiven Korrektur festgelegt. Ein ausgelassenes Paket hält die Gruppe nie auf.
• In der Konsole zeigt Aktivität einen gebündelten Pull Request einmal an, als Gebündelt · N Pakete mit jedem Paket und seiner Version. In der API trägt jede Anforderung einer Gruppe dieselbe group_id (bei POST .../requests mit repo und bei GET .../requests).

Basis-Image-Upgrades

Für eine Schwachstelle in einem Image, das in die Registry deiner Organisation gepusht wurde, kann fremforge die FROM-Basis des Images in dem Dockerfile anheben, aus dem es gebaut wurde. Korrektur-PR für Basis-Image öffnen beim Befund (unter Sicherheit › Befunde › Container-Images) erscheint, wenn alles Folgende zutrifft:

1. fremforge weiß, welches Repository und welcher Commit das Image gebaut haben, auf einem von zwei Wegen:

   • Das Image nennt sie, mit den OCI-Labels org.opencontainers.image.source und org.opencontainers.image.revision (docker/metadata-action setzt beide). Sind die Labels vorhanden, haben sie Vorrang;
   • oder, ohne solche Labels, das Image wurde von einem fremforge-Actions-Lauf eines Repositorys deiner Organisation gepusht: Die Registry von fremforge vermerkt, welcher Lauf welches Manifest gepusht hat, und Repository und Commit sind die dieses Laufs. Jeder Push des Images muss aus Actions-Läufen dieses einen Repositorys stammen; ein Image, das auch von anderswo gepusht wurde (ein Laptop, eine andere CI) oder von einem Lauf eines Repositorys einer anderen Organisation, wird nicht auf diese Weise zugeordnet.

   Der Befund sagt, welches Repository und welches Dockerfile das Image gebaut haben und woher fremforge das weiß („from its image labels" oder „from the Actions run that pushed it"), und die API ebenso (base_attribution bei jedem Image-Befund).

2. fremforge hat in diesem Commit das Dockerfile gefunden, auf dessen FROM-Basis das Image gebaut ist: Die Layer des Basis-Images sind die ersten Layer deines Images.

3. Trivy verortet das verwundbare Paket in einem dieser Basis-Layer, nicht in einem Layer, den dein Dockerfile hinzufügt.

4. Die neueste Basis derselben Linie (gleiche Major-Version und Tag-Form oder, bei einem gleitenden Tag, der neuere Digest desselben Tags), von fremforge mit derselben Schwachstellendatenbank gescannt, enthält es nicht mehr.

Diese Analyse läuft mit dem täglichen Image-Scan. Der Pull Request ändert nur diese FROM-Zeile: den Tag und den Digest, den fremforge dafür gescannt hat. Eine Änderung an einer anderen Zeile oder Datei oder ein anderer Digest als der von fremforge gescannte schließt ihn. Jeder offene Befund des Images, den dieselbe Basis behebt, wird in einem Pull Request aufgeführt.

Gibt es keine Schaltfläche, sagt der Befund, warum:

Nachdem du den Pull Request gemergt und das neu gebaute Image unter demselben Tag gepusht hast, vergleicht fremforge das neue Image mit dem alten, sobald das neue gescannt wurde. Jeder Befund des alten Digests, den das neue Image nicht mehr hat, wird von fremforge als behoben geschlossen (fixed_source: security_fix), sofern der alte Digest nicht mehr in Gebrauch ist: Er trägt keinen Tag mehr, er ist nicht im neuesten Live-Deployment eines Repositorys und einer Umgebung, und niemand außer fremforges eigenen Bots hat ihn in den letzten 7 Tagen per Digest gepullt. Die Befunde des alten Digests bleiben unter diesem Digest aufgeführt, solange das Image in deiner Registry existiert.

Ist der alte Digest noch in Gebrauch, wird nichts geschlossen: Der Befund zeigt Im neueren Image behoben mit dem neuen Digest und sagt, warum er offen bleibt (noch getaggt, noch deployt oder kürzlich gepullt). Er wird geschlossen, sobald der alte Digest nicht mehr in Gebrauch ist, und wieder geöffnet, wenn dieser Digest erneut in Gebrauch kommt.

Nach dem Merge

Wenn der Pull Request gemergt ist und der nächste Scan des Standard-Branches einen Befund nicht mehr meldet, wird der Befund geschlossen. Seine Historie im Compliance-Bericht verzeichnet ihn als durch eine Sicherheitskorrektur behoben (fixed_source: security_fix; vor dem 2026-10-14 erfasste Zeilen lauteten autofix). Ein Befund, der durch einen der eigenen Sicherheits-Pull-Requests von gehostetem Renovate geschlossen wurde, wird als fixed_source: renovate erfasst. Die Kennzahlen zur Behebung zählen beides.

Limits

• Eine laufende Anforderung pro (Repository, Paket) auf jedem Branch. Eine zweite Anforderung für dasselbe Paket auf demselben Branch antwortet mit already requested. Eine Korrektur auf einem geschützten Release-Branch ist eine eigene Anforderung, getrennt von der des Standard-Branches.
• Höchstens 3 offene Pull Requests für Sicherheitskorrekturen pro Repository, standardmäßig; 0 bis 10.
• Höchstens 20 Anforderungen pro Organisation innerhalb von 24 Stunden, standardmäßig; 0 bis 50.
• Ein gebündelter Pull Request zählt bei beiden als einer.

Sie gelten für Klicks und automatische Sicherheitskorrekturen gemeinsam. Die KI-Korrektur hat eigene Limits. Wenn kein Pull Request geöffnet wird, siehe Fehlerbehebung.

API

• Eine Korrektur anfordern POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, Scope dependency-updates:write (findings:write wird ebenfalls akzeptiert). Der Body nennt genau eines von:

  • finding_id: ein Abhängigkeitsbefund. Ein Pull Request für sein Paket. Antwortet mit 202 und der ID der Anforderung, der Zielversion, den abgedeckten Befundschlüsseln, known_exploited_cves (die bekanntermaßen ausgenutzten CVE-IDs, die sie behebt; leer, wenn keine) und automerge.
  • repo: jedes behebbare Paket in diesem Repository, je ein Pull Request oder in einem gebündelten Repository einer pro Lockfile. Antwortet mit 202 und einem Ergebnis pro Paket (queued mit seiner group_id, null, wenn es nicht gebündelt ist, oder refused mit einem reason) oder mit 200, wenn nichts eingereiht wurde.
  • image_finding_id: ein Basis-Image-Upgrade. Zu den Ablehnungen gehören image_not_from_base, image_no_base_fix, image_source_unknown und image_not_attributed.

  Eine Ablehnung ist problem+json mit dem type security-fix-<reason> und einem reason, zum Beispiel no_fixed_version, ecosystem_not_supported, manifest_not_supported oder sbom_finding. Jede ist unter API-Fehler beschrieben.

• Anforderungen auflisten GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, Scope dependency-updates:read, mit Status und Pull Request jeder Anforderung.

• Einstellungen GET und PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings; siehe Einstellungen.

• Wer Sicherheits-Pull-Requests öffnet GET und PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane; siehe Übernahme von Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates enthält security_fixes_bot, true, wenn der Abhängigkeits-Bot für Sicherheitskorrekturen existiert. Sein enrolled bedeutet, dass die Versions-Updates eingeschaltet sind.

• Zähler GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics: Anforderungen, geöffnete, gemergte und geschlossene Pull Requests, Annahmequote, Pull Requests, die ohne freigebendes Review gemergt wurden, und durch eine Sicherheitskorrektur behobene Befunde.

Jeder Abhängigkeitsbefund, den GET /_app/api/v1/orgs/{org}/code-security/deps/findings liefert, enthält autofix_eligible, autofix_unavailable_reason (warum ein Befund mit Korrektur nicht abgedeckt ist) und autofix, die neueste Anforderung, die ihn abdeckt. Jeder Image-Befund aus GET .../code-security/images/findings enthält dieselben drei Felder für Basis-Image-Upgrades.

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"

Veraltete API

Diese Pfade, Felder und Scopes funktionieren bis zum 2027-10-15 weiter. Bis dahin trägt jede Antwort eines veralteten Pfads Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT und einen Link-Header mit rel="successor-version", der den Nachfolger nennt.

Übernahme von Renovate

Bis eine Organisation umstellt, bedienen die eigenen Vulnerability-Alert-Pull-Requests von gehostetem Renovate sie neben diesem Weg (lane_owner: renovate). Wenn der Weg Sicherheitskorrekturen übernimmt (lane_owner: security_lane), öffnet Renovate nur noch Versions-Updates, sodass jede Korrektur genau einmal vorgeschlagen wird. Offene Renovate-Sicherheits-Pull-Requests werden mit einem Kommentar, der auf den ersetzenden Korrektur-Pull-Request verlinkt, geschlossen, sobald dieser Weg für jedes Paket, das sie anheben, einen Korrektur-Pull-Request hat; bis dahin bleiben sie offen.

Für Kundinnen und Kunden erfolgt die Umstellung vorerst auf Anfrage: Wende dich an den Support. Die eigenen Organisationen stellt fremforge selbst um. Die API ist PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane mit {"lane_owner": "security_lane"} (oder "renovate", um zurückzuwechseln), Scope dependency-updates:write; GET auf demselben Pfad liefert den aktuellen Wert sowie unsupported_ecosystems (ein Objekt, Ökosystem zur Anzahl offener behebbarer Befunde, die der Weg nicht behebt) und unsupported_total, sodass du vorher siehst, ob eine Umstellung abgewiesen würde. Die Übernahme wird abgewiesen, solange der Weg nicht handeln kann:

• Sicherheitskorrekturen sind Aus: 409 security-lane-lane-off. Wähle zuerst einen anderen Modus als Aus oder sende "acknowledge": ["no_security_prs"], um zu akzeptieren, dass überhaupt keine Sicherheits-Pull-Requests geöffnet werden.
• Offene Befunde in Ökosystemen, die der Weg nicht behebt (zum Beispiel CRAN oder Conan, die Renovates Alerts abdecken): 409 security-lane-unsupported-ecosystems, dessen unsupported_ecosystems die offenen behebbaren Befunde pro Ökosystem auflistet. Sende "acknowledge": ["unsupported_ecosystems"], um trotzdem umzustellen; diese Befunde erhalten dann keinen automatischen Pull Request.

Mit der Umstellung beginnen Pull Requests für Sicherheitskorrekturen, Wann Korrekturen gemergt werden zu folgen, in Organisationen, in denen sie bis dahin auf ein Review gewartet haben; siehe Mergen.

Die Umstellung wird im Audit-Log als dependency-updates.security-lane.enabled erfasst, das Zurückwechseln als dependency-updates.security-lane.disabled.

Audit

Jeder Schritt steht im Audit-Log: autofix.proposed, autofix.pr_opened, autofix.rejected (mit dem Grund), autofix.relocked (ein Lockfile-Commit aus deiner eigenen CI, mit dem Lauf), autofix.relock_refused (ein Job-Token, das nicht vom ausgelösten Lauf stammte), autofix.merged und autofix.closed, jeweils mit den Befundschlüsseln und engine: deterministic. autofix.proposed einer bekanntermaßen ausgenutzten Korrektur enthält zusätzlich knownExploitedCves. Eine Änderung der Einstellungen ist dependency-updates.security-fixes.updated.

KI-Korrekturen für SAST-Befunde

KI-generierte Korrekturen für SAST-Befunde haben jetzt eine eigene Seite: KI-Korrektur.

Siehe auch

• Abhängigkeits-Updates: beide Wege und der Bot.
• Mergen: Review, Mergen bei grünen Checks, das Merge-Fenster und der Release-Freeze.
• Fehlerbehebung: wenn kein Pull Request geöffnet wird.
• OSV-Empfehlungen: die Karten, an denen die Schaltfläche Korrektur-PR öffnen sitzt.
• Einrichtungs-Checkliste: deine Limits und Opt-ins auf einen Blick unter Sicherheit › Übersicht.