Beveiligingsfixes

Een beveiligingsfix maakt van een afhankelijkheidsbevinding een pull request. Klik op Fix-PR openen bij een bevinding of op een kaart onder Aanbevelingen, of roep de API aan, en de afhankelijkhedenbot van je organisatie opent één pull request in die repository. Die tilt het pakket naar de laagste uitgebrachte versie die elk openstaand advies erop oplost. Dit is de baan Beveiligingsfixes van Updates van afhankelijkheden, onder Beveiliging › Herstellen › Updates van afhankelijkheden.

Beveiligingsfixes dekken afhankelijkheden van npm (inclusief Yarn, pnpm en Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex en CRAN (R), en versies van CI-actions (GitHub Actions), in de manifesten die staan vermeld onder Ecosystemen en manifesten. Andere ecosystemen krijgen het antwoord not yet supported. De volledige lijst staat op Ondersteunde ecosystemen. Er komt geen AI-model aan te pas: de versieverhoging wordt berekend uit de adviesrecords van OSV.

Voor een kwetsbaarheid in een image dat naar je register is gepusht en die is meegekomen met de FROM-basis van het image, tilt Fix-PR voor basisimage openen die basis op, zodra fremforge heeft gecontroleerd dat de nieuwere basis de kwetsbaarheid niet meer heeft. Zie Verhogingen van het basisimage. Alles in deze repository herstellen vraagt in één keer om elk herstelbaar pakket in een repository: zie Alles herstelbare in een repository herstellen.

Beveiligingsfixes heetten tot 2026-10-14 AutoFix. AutoFix is geen productnaam meer: door AI gegenereerde fixes voor SAST-bevindingen heten AI-fix. De auditgebeurtenissen autofix.* en de verouderde API-paden dragen nog de oude naam. Pull requests die vóór de overstap zijn geopend, houden hun autofix/-branch; fremforge voegt het label security-fix toe aan de pull requests die nog openstaan.

Instellingen

Een eigenaar stelt deze in onder Beveiliging › Herstellen › Updates van afhankelijkheden › Beveiligingsfixes, of met PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Elk veld is optioneel in een PUT; een weggelaten veld houdt zijn waarde, en er wordt niets opgeslagen als een veld wordt geweigerd.

De modi:

• Uit (off): geen pull requests voor beveiligingsfixes, niet op klik en niet automatisch.
• Op klik (on_click): iemand vraagt erom, met Fix-PR openen, Alles in deze repository herstellen of Fix-PR voor basisimage openen, of via de API.
• Automatisch voor belangrijke bevindingen (auto_important): zoals op klik, en daarnaast opent fremforge ze zelf voor hoge en kritieke bevindingen die bereikbaar of bekend misbruikt zijn. Met Ook bevindingen waarvan de bereikbaarheid onbekend is aan tellen ook hoge en kritieke bevindingen zonder oordeel over de bereikbaarheid mee. Zie Automatische beveiligingsfixes.
• Automatisch voor alle hoge en kritieke (auto_high_critical): fremforge opent ze zelf voor elke hoge en kritieke bevinding die het kan herstellen, ongeacht de bereikbaarheid.
• Automatisch voor kritieke en bekend misbruikte (auto_critical_exploited): fremforge opent ze zelf voor elke kritieke bevinding, ongeacht de bereikbaarheid, en voor elke bekend misbruikte bevinding van welke ernst ook. Een hoge, gemiddelde of lage bevinding die niet bekend misbruikt is, wacht op een klik. Dit is de standaard voor een organisatie die op of na 2026-10-27 is aangemaakt; zie Nieuwe organisaties.

Het antwoord bevat ook alleen-lezen velden. configured is false zolang de organisatie de instellingen nooit heeft opgeslagen en de waarden de standaardwaarden zijn (voor een nieuwe organisatie de standaardwaarden waarmee ze is aangemaakt). lane_owner zegt wie beveiligings-pull-requests opent: renovate zolang de eigen beveiligings-pull-requests van gehost Renovate de organisatie nog bedienen, security_lane zodra deze baan het heeft overgenomen. high_blast_radius_exempt is true voor organisaties waarvan de beveiligings-pull-requests van Renovate zichzelf vóór 2026-10-14 samenvoegden en die zijn overgezet naar Samenvoegen als de checks slagen; zie Samenvoegen.

Een wijziging wordt in de auditlog vastgelegd als dependency-updates.security-fixes.updated, met de oude en nieuwe waarde van elk veld.

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"

Beveiligingsfixes hebben geen Versie-updates nodig. Het eerste verzoek om een fix (Fix-PR openen, Alles in deze repository herstellen, Fix-PR voor basisimage openen of POST .../security-fixes/requests), of het opslaan van een automatische modus, richt de afhankelijkhedenbot <org>-fremforge-bot-deps van je organisatie in, met Versie-updates uitgeschakeld. Een repository die zich heeft afgemeld voor updates van afhankelijkheden krijgt geen fix-pull-requests, en een gearchiveerde of gespiegelde repository wordt geweigerd (repo_archived).

Wat er gebeurt als je op Fix-PR openen klikt

1. fremforge verzamelt elke openstaande bevinding op de standaardbranch voor hetzelfde pakket in dezelfde repository. Eén pull request sluit ze allemaal.
2. Het berekent de doelversie. Voor elke geïnstalleerde versie is dat de laagste uitgebrachte versie buiten elk getroffen bereik van elk openstaand advies. De pull request neemt de hoogste daarvan, zodat hij de hele groep oplost.
3. Er start een gerichte run van gehost Renovate, als de afhankelijkhedenbot van je organisatie. Die is beperkt tot dat ene pakket en die ene versie. Elke andere afhankelijkheid blijft ongemoeid.
4. Renovate opent de pull request op een branch security-fix/<package>-<version>. Runs voor beveiligingsfixes gaan voor gewone Renovate-runs, dus dit duurt meestal minder dan 15 minuten. De pull request krijgt het label security-fix. Heeft de repository dat label nog niet, dan maakt fremforge het vóór de run eenmalig aan; een label dat al bestaat, blijft zoals het is. Kan een label niet worden aangemaakt, dan wordt de pull request zonder label geopend.
5. fremforge controleert de pull request voordat hij openblijft. Die mag alleen de manifesten en lockfiles van het ecosysteem wijzigen (zie de tabel hieronder), en in een manifest alleen de regel van dat pakket. Een wijziging aan een ander bestand, een nieuwe directe afhankelijkheid, een verhoging van een ander pakket, een gedeelde versie, of een lockfile waarvan de pakketten nu uit een andere index komen, sluit de pull request en verwijdert de branch. Dat geldt ook voor een mislukte vernieuwing van de lockfile: een pull request met een verouderde lockfile zou niet bouwen.

De bevinding toont daarna Herstel voorgesteld: #N met de status van de pull request: open, samengevoegd of gesloten.

Elke kopie, op de fixversie. Een lockfile kan meerdere kopieën van één pakket bevatten: een directe, en oudere die genest zijn onder andere afhankelijkheden. Voordat een pull request als fix telt, leest fremforge de lockfiles bij de head van de pull request en controleert het elke kopie van het pakket die erin staat tegen de gefixte versie. Dat geldt voor package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock, Cargo.lock, go.mod en packages.lock.json van NuGet, zowel voor losse als voor gebundelde fixes. Een pre-release van de gefixte versie telt als lager dan die versie.

• Elke kopie op of boven de fix: de pull request lost het pakket op.
• Sommige kopieën gefixt, een oudere achtergebleven: de pull request blijft open en de console noemt de kopieën die achterblijven (in de API het veld lock_copies_left van het verzoek, met reason target_partly_reached). Herstel voorgesteld verschijnt alleen bij de bevindingen van de kopieën die hij oplost; de andere houden hun knop Fix.
• Geen enkele kopie op de fix, bijvoorbeeld een transitieve kopie die met haar ouder is meegegaan, maar naar een versie die nog steeds kwetsbaar is: het pakket maakt geen deel uit van de pull request. Het verzoek ervoor eindigt als target_not_reached, en de transitieve fix pint het afzonderlijk vast. Een pull request zonder enig gefixt pakket wordt gesloten.

Een lockfile-formaat dat hier niet staat, wordt gecontroleerd zoals voorheen: de pull request moet het pakket in de lockfile wijzigen.

Wat deze controle niet doet:

• Alleen de lockfiles die de pull request wijzigt, worden gelezen. Als een andere lockfile in de repository, een die de pull request ongemoeid laat, nog een kwetsbare versie bevat, blijft die bevinding na het samenvoegen open. Ze wordt niet als opgelost geclaimd: haar knop Fix blijft staan.
• Een achtergebleven kopie wordt na het samenvoegen hersteld, niet tegelijk. Zolang de pull request openstaat, wordt een nieuw verzoek voor hetzelfde pakket geweigerd omdat er al een openstaat, dus Fix op een kopie die de pull request achterlaat, start nog niets. Vraag het na het samenvoegen en de volgende scan opnieuw aan.
• Dezelfde versie, direct en genest. Een bevinding wordt geïdentificeerd aan de hand van pakket en versie, niet aan de hand van de plek in de boom waar de kopie zit. Verplaatst de pull request de directe kopie, maar zit dezelfde oude versie nog genest onder een andere afhankelijkheid, dan is die bevinding niet opgelost. Het verzoek eindigt dan als target_not_reached en de pull request wordt gesloten. De transitieve fix weigert een pakket dat je manifest direct noemt, dus pin de geneste kopie zelf vast (bijvoorbeeld met een overrides-regel van npm).

De Renovate-instellingen van je repository

De eigen renovate.json van een repository (of .renovaterc, of de sleutel renovate in package.json) bepaalt de versie-updates ervan. Een beveiligingsfix houdt ze niet tegen. Een run voor een beveiligingsfix negeert in de repository:

• packageRules, inclusief een regel met "enabled": false voor het pakket;
• ignoreDeps;
• ignorePaths en includePaths. Alleen node_modules en bower_components worden overgeslagen;
• enabledManagers. De run gebruikt de managers voor het ecosysteem van de bevinding.

Wil je een pakket buiten de beveiligingsfixes houden, leg dan een uitzondering vast voor de bevindingen ervan: negeer ze met een reden en bij voorkeur een vervaldatum, of vraag een goedgekeurde uitzondering aan. Een bevinding met een uitzondering staat niet open, dus er wordt geen fixverzoek voor gedaan, en Fix-PR openen antwoordt met security-fix-not-open. Anders dan een blokkeerregel in een bestand is een uitzondering zichtbaar op de pagina Uitzonderingen, noemt ze wie haar heeft gemaakt en waarom, en vervalt ze op haar vervaldatum.

Twee instellingen gelden nog wel:

• Een "enabled": false op het hoogste niveau in renovate.json schakelt Renovate uit voor de hele repository, beveiligingsfixes inbegrepen.
• packageRules van een repository die registryUrls of andere opzoekinstellingen zetten, gelden niet voor een run voor een beveiligingsfix. De run zoekt pakketten op via de eigen instellingen van je organisatie en de dependency proxy.

Bekend misbruikte kwetsbaarheden eerst

Wanneer een advies dat een verzoek oplost een CVE heeft die als actief misbruikt staat vermeld, in de EU Vulnerability Database (EUVD) van ENISA of de Known Exploited Vulnerabilities-catalogus (KEV) van CISA, wordt de fix als de dringendste behandeld:

• Hij draait als eerste. Zijn Renovate-run gaat voor elk ander verzoek om een beveiligingsfix in de wachtrij, ongeacht de volgorde waarin ze zijn aangevraagd.
• Hij staat vooraan bij Alles herstellen. Een batch van Alles in deze repository herstellen laat bekend misbruikte pakketten vóór de andere toe, daarna op ernst, zodat bij het bereiken van een limiet een minder dringend pakket afvalt.
• Hij wacht niet op de release-leeftijd. Je Release-leeftijd houdt andere fixes tegen, maar een versie die een bekend misbruikte kwetsbaarheid oplost, wordt meteen voorgesteld.
• De pull request zegt het. De titel eindigt op known exploited, bijvoorbeeld fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), de beschrijving begint met de CVE’s en de lijsten die ze noemen, en de pull request krijgt ook het label known-exploited, op dezelfde manier aangemaakt als security-fix.

Een CVE telt als het het eigen id van het advies is of een van de aliassen ervan (een GHSA- of PYSEC-advies heeft meestal een CVE-alias). Beide lijsten worden gespiegeld en dagelijks vernieuwd. Of een verzoek bekend misbruikt is, wordt bepaald op het moment dat het wordt gedaan; de API geeft het terug als known_exploited_cves. Met Samenvoegen als de checks slagen wordt zo’n fix ook buiten je merge-venster ingeschakeld; zie Samenvoegen. De limieten blijven gelden.

Automatische beveiligingsfixes

Met Automatisch voor belangrijke bevindingen, Automatisch voor alle hoge en kritieke of Automatisch voor kritieke en bekend misbruikte opent fremforge dezelfde pull requests als een klik op Fix-PR openen of Fix-PR voor basisimage openen, zonder dat iemand klikt, voor elke bevinding die aan al deze voorwaarden voldoet:

1. Ze staat open op de standaardbranch: niet genegeerd, niet gemeld op een pull request.
2. Haar ernst is hoog of kritiek. Gemiddelde en lage bevindingen worden alleen automatisch hersteld met Automatisch voor kritieke en bekend misbruikte, en alleen als ze bekend misbruikt zijn.
3. Met Automatisch voor belangrijke bevindingen: ze is bereikbaar (haar oordeel over de bereikbaarheid is reachable) of ze is bekend misbruikt (een CVE ervan staat in ENISA EUVD of CISA KEV), of, met Ook bevindingen waarvan de bereikbaarheid onbekend is aan, ze heeft geen oordeel of een onbekend oordeel. Een bekend misbruikte bevinding komt in aanmerking, ook als ze onbereikbaar is. Met Automatisch voor alle hoge en kritieke komt elke hoge en kritieke bevinding in aanmerking. Met Automatisch voor kritieke en bekend misbruikte komt een kritieke bevinding in aanmerking ongeacht de bereikbaarheid, een bekend misbruikte bevinding bij elke ernst, en verder niets.
4. fremforge kan haar deterministisch herstellen: een afhankelijkheid in een gedekt ecosysteem en manifest met een uitgebrachte fix, of een image-bevinding die een verhoging van het basisimage oplost.

Wil je het eerst op een paar repository’s proberen, zet ze dan onder Repository’s. Een lege lijst dekt elke repository van de organisatie. De voorbeeldrepository voor beveiliging wordt nooit automatisch hersteld; een klik op Fix-PR openen werkt daar nog wel.

Nieuwe organisaties

Een organisatie die op of na 2026-10-27 is aangemaakt, begint met Automatisch voor kritieke en bekend misbruikte, en Wanneer fixes worden gemerged op Wachten op review: fix-pull-requests openen vanzelf, en geen enkele wordt zonder een mens samengevoegd. De limieten, bundeling en release-leeftijd houden hun standaardwaarden. Er wordt niets aangemeld voor Versie-updates: de afhankelijkhedenbot <org>-fremforge-bot-deps wordt pas aangemaakt wanneer de eerste bevinding in aanmerking komt. Een eigenaar kan op elk moment naar elke andere modus overstappen, inclusief Uit, of de modus verruimen. Organisaties die vóór 2026-10-27 zijn aangemaakt, houden de instelling die ze hadden.

Wanneer het in actie komt

fremforge controleert elke 10 minuten. Een bevinding wordt kort nadat ze in aanmerking komt voorgesteld: wanneer een scan een nieuwe bevinding meldt, wanneer haar oordeel bereikbaar wordt, of wanneer de dagelijkse vernieuwing van bekend misbruikte kwetsbaarheden een van haar CVE’s toevoegt. Bevindingen die al in aanmerking komen wanneer je het inschakelt, doen ook mee, binnen de limieten.

Wat hetzelfde blijft

Elk automatisch verzoek volgt precies het pad van een klik: één pull request per pakket (of per basisimage), de laagste versie die het oplost, de limieten van je organisatie, het wachten op de release-leeftijd, de weigering bij een gedeelde versie en de controles op de reikwijdte. In de lijst met verzoeken heeft zo’n verzoek "trigger": "policy", en de pull request vermeldt dat hij automatisch is geopend.

• Hij wordt samengevoegd zoals jij hebt ingesteld. Zoals elke pull request voor een beveiligingsfix volgt hij Wanneer fixes worden gemerged; zie Samenvoegen.
• Hij gebruikt nooit AI. Alleen de deterministische engine draait automatisch. AI-fix begint altijd met de klik van een mens op één bevinding.
• Een piek wacht op zijn beurt. Wanneer de lijst met bekend misbruikte kwetsbaarheden een CVE toevoegt die veel van je repository’s hebben, opent fremforge wat je limieten toestaan, bekend misbruikte en kritieke eerst, en de rest later, naarmate pull requests worden samengevoegd of gesloten en het venster van 24 uur verschuift. Het opent nooit meer dan de limieten.
• Een gesloten pull request blijft gesloten. Als iemand een pull request voor een beveiligingsfix sluit zonder hem samen te voegen, opent fremforge hem niet opnieuw voor dezelfde bevindingen en dezelfde doelversie. Een nieuwe bevinding voor dat pakket die in aanmerking komt, of een nieuwere doelversie, is een nieuwe reden en kan worden voorgesteld. Een verzoek dat zonder pull request is geëindigd (bijvoorbeeld Wacht op de release-leeftijd), wordt na 24 uur opnieuw geprobeerd.

Automatisch gedane verzoeken worden vastgelegd als autofix.proposed met source: policy, de actor system:autofix-policy en qualifiedBy (known_exploited, reachable, unknown of severity).

Ecosystemen en manifesten

Nog niet gedekt, en dat staat bij de bevinding:

• Andere JVM-buildtools (Ivy, sbt): de bevinding toont Manifest niet ondersteund.
• bun.lockb, de binaire lockfile van Bun, die alleen Bun kan herschrijven. Voer eenmalig bun install --save-text-lockfile uit om over te stappen op bun.lock.
• Bun-pakketten die het manifest niet noemt: de run eindigt met no change.
• pub-pakketten die het manifest niet noemt: de run eindigt met no change.
• Bevindingen uit een geüploade SBOM (manifest sbom:<name>): er is geen bestand in de repository om te wijzigen. De bevinding toont Uit een SBOM.
• Conan (conan.lock): OSV, waaruit de afhankelijkheidsscan zijn adviezen leest, publiceert er geen voor Conan-pakketten, dus er is geen Conan-kwetsbaarheid om te herstellen.

Een pakket dat alleen een transitieve afhankelijkheid is (in de lockfile, maar niet in een manifest), wordt vanuit de root van je project vastgepind: een overrides-regel van npm, een <dependencyManagement>-regel van Maven, of de regel // indirect in go.mod. Zie Transitieve afhankelijkheden.

Vernieuwingen van de lockfile

De lockfile wordt vernieuwd door de pakketbeheerder zelf (uv lock, poetry lock, dotnet restore, cargo update, composer update --no-scripts --no-plugins, dart pub upgrade, bun install --ignore-scripts enzovoort), zonder ooit de eigen scripts of plug-ins van de repository uit te voeren, als de Renovate-bot van je organisatie, via dezelfde sandbox van gehost Renovate als bij de gewone updates. Een vernieuwing verplaatst pakketten nooit naar een andere index: een Python- of Cargo-lockfile waarvan de pakketten daarna uit een andere index zouden komen, wordt geweigerd. Mislukt de vernieuwing, bijvoorbeeld omdat de repository een privé-index noemt die de bot niet kan lezen, dan wordt de pull request gesloten als PR gesloten: lockfile mislukt in plaats van open te blijven staan met een verouderde lockfile.

De dependency proxy van je organisatie als index. Wanneer de manifesten, lockfiles of toolconfiguratie van de repository de eigen dependency proxy van je organisatie noemen (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...), authenticeert de vernieuwing zich daar als je Renovate-bot. Dat geldt voor elke Renovate-run van die repository, niet alleen voor fremforge. Het inloggegeven wordt gegeven voor precies de proxypaden van je organisatie die de repository noemt, en voor niets anders: een index van uv, Poetry of Pipenv en een bron in nuget.config krijgen het via de eigen afhandeling van inloggegevens van Renovate, Cargo via een credential provider die alleen antwoordt voor de Cargo-proxy van je organisatie. (Een Gradle-build wordt hier helemaal niet vernieuwd; zie Gradle.) Het inloggegeven staat in bestanden van die ene run, nooit in de repository, nooit in de omgeving en nooit in logs.

Gradle

fremforge voert nooit de build van je repository uit. Een Gradle-lockfile vernieuwen betekent je Gradle-wrapper en buildscripts uitvoeren, dus voor een Gradle-bevinding wordt het werk opgesplitst:

1. fremforge wijzigt alleen de versie. Renovate bewerkt build.gradle(.kts), de versiecatalogus of gradle.properties, met dezelfde controles op reikwijdte en gedeelde versies als bij elke pull request voor een beveiligingsfix, en opent de pull request zonder de lockfiles aan te raken. Geen enkele Renovate-run, van fremforge of gewoon, voert code uit de repository uit.
2. Je eigen CI vernieuwt de lockfiles. Heeft de build *.lockfile-bestanden of gradle/verification-metadata.xml, dan commit fremforge een gegenereerde workflow, .forgejo/workflows/fremforge-autofix-relock.yaml, op een wegwerpbranch autofix-relock/<request> (met [skip ci], zodat geen van je eigen workflows erop draait) en start die eenmalig op de gehoste runner van je organisatie (runs-on: fremforge): een kortstondige VM van die commit. Hij telt niet mee voor de CI-minuten van je organisatie: fremforge registreert de run die het heeft gestart en laat die buiten je verbruik en factuur. Hij neemt wel een van je gelijktijdige jobslots in beslag zolang hij draait. Je hoeft je repository niet te wijzigen. De run is zichtbaar op het tabblad Actions van de repository.
3. De job voert dezelfde commando’s uit die de Gradle-manager van Renovate zou uitvoeren: gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, en --write-verification-metadata wanneer de build afhankelijkheden verifieert. Hij kiest een JDK van de runner (21, anders 17), geeft de egress-proxy van de runner door aan de JVM en leest de dependency proxy van je organisatie met de eigen token van de job via de eigenschappen fremforgeUsername en fremforgePassword. Hij heeft geen schrijfrechten: zijn permissions zijn contents: read, packages: read en id-token: write.
4. fremforge controleert en commit het resultaat. De job stuurt de gewijzigde lock- en verificatiebestanden naar fremforge met een jobtoken voor de audience fremforge:autofix-relock, die fremforge alleen van die ene run accepteert. fremforge weigert alles wat geen Gradle-lock- of verificatiebestand van de opnieuw gelockte build is, een lockfile die nog steeds de kwetsbare versie vastlegt, of een branch die intussen is gewijzigd. Daarna voegt het de bestanden als één commit van je Renovate-bot toe aan de pull request voor de beveiligingsfix, zodat de CI van je pull request erop draait, controleert het dat de pull request niets anders wijzigt dan Gradle-buildbestanden en lockfiles, en verwijdert het de wegwerpbranch. De status fremforge/autofix-relock op de pull request linkt naar de run.

Een build zonder lockfiles krijgt alleen de versiewijziging, en er draait geen job.

Als de job mislukt, wordt geannuleerd, niets terugmeldt, of 90 minuten na de start nog niet klaar is (bijvoorbeeld als de runnerminuten van de organisatie op zijn), wordt de pull request gesloten als PR gesloten: lockfile mislukt, met een link naar de run. Review een Gradle-pull-request pas nadat de lockfile-commit is binnengekomen; tot dan zijn de lockfiles verouderd. Met Samenvoegen als de checks slagen wordt een Gradle-fix niet ingeschakeld zolang de vernieuwing van de lockfile in behandeling is of wordt gecommit; hij wordt ingeschakeld zodra de lockfile-commit binnen is en de checks slagen. Voeg je hem met de hand samen, wacht dan op de lockfile-commit.

RubyGems, Hex, CRAN en Composer-pakketten die composer.json niet noemt

Bundler leest de Gemfile en Mix leest mix.exs om ze te locken, en beide zijn code (Ruby, Elixir), dus fremforge voert Bundler of Mix nooit zelf uit. Voor het bijwerken van renv.lock is R nodig, dat fremforge noch Renovate uitvoert. Renovate werkt alleen de Composer-pakketten bij die composer.json noemt. Voor deze fixes wordt de lockfile in je eigen CI bijgewerkt, op dezelfde manier als een vernieuwing voor Gradle, en de pull request wordt pas geopend als die binnen is:

1. Je eigen CI werkt de lockfile bij. fremforge commit de gegenereerde workflow .forgejo/workflows/fremforge-autofix-relock.yaml op een wegwerpbranch autofix-relock/<request>, gemaakt vanaf de head van de basisbranch (met [skip ci]), en start die eenmalig op de gehoste runner van je organisatie, zonder dat hij meetelt voor je CI-minuten. In de map van de lockfile voert hij bundle lock --update <gem> --conservative --patch|--minor|--major --strict uit (het kleinste niveau dat de fix bereikt, met de Ruby uit .ruby-version of de lockfile en de Bundler-versie waarmee de lockfile is geschreven), mix deps.update <package> in het officiële elixir-image (de versie die je .tool-versions noemt, anders de huidige; je runners hebben geen Elixir), het R-script van fremforge in het rocker/r-ver-image op de R-versie die renv.lock vastlegt (zie CRAN hieronder), of composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Er wordt niets geïnstalleerd en er draait geen gem- of pakketscript. Hij heeft geen schrijfrechten. Zolang hij draait, toont de bevinding Herstel aangevraagd.
2. De release-leeftijd wordt in de job gecontroleerd. Tenzij de fix voor een bekend misbruikte kwetsbaarheid is, leest de job de publicatietijd van de vastgelegde versie op rubygems.org, hex.pm of repo.packagist.org, of, voor CRAN, uit het eigen veld Date/Publication van het pakket; een versie die jonger is dan de release-leeftijd van je organisatie, beëindigt het verzoek met Nog geen PR: te nieuw, en het wordt na 24 uur opnieuw geprobeerd.
3. fremforge controleert de lockfile en opent de pull request. De job stuurt de ene lockfile terug met een jobtoken voor die ene run. fremforge weigert een lockfile waarin iets anders is gewijzigd dan de vastgelegde versies (bronnen, platforms, afhankelijkheden, de Bundler-versie, de content-hash van Composer, een git- of pad-afhankelijkheid in mix.lock, in renv.lock alles behalve het eigen record van dat pakket), een die de gefixte versie niet vastlegt, of een die nog steeds de kwetsbare versie vastlegt. Daarna commit het de lockfile als je Renovate-bot op de branch voor de beveiligingsfix, gemaakt vanaf de basisbranch, opent het de pull request met de gebruikelijke titel, beschrijving en labels, en verwijdert het de wegwerpbranch. Vanaf dan is het een gewone pull request voor een beveiligingsfix.

Als de job mislukt, wordt geannuleerd, niets terugmeldt, of 90 minuten na de start nog niet klaar is, wordt er geen pull request geopend en eindigt het verzoek met Geen PR: lockfile bijwerken mislukt, met de reden en een link naar de run.

CRAN

Een CRAN-fix verplaatst één record van renv.lock en verder niets. De job installeert de versie van renv waarmee renv.lock is geschreven, zodat het bestand zijn formaat houdt, en leest de DESCRIPTION van de gefixte versie uit de pakketrepository die renv.lock noemt. Hij installeert nooit je project en voert nooit de code ervan uit. Hij weigert, en zegt waarom, wanneer:

• de gefixte versie een pakket nodig heeft (Depends, Imports of LinkingTo) dat renv.lock niet vastlegt, of vastlegt op een lagere versie dan nodig;
• de gefixte versie een andere R-versie nodig heeft dan die in renv.lock;
• de DESCRIPTION van je project het pakket begrenst tot onder de fix, bijvoorbeeld Imports: commonmark (<= 1.8);
• de gefixte versie jonger is dan de release-leeftijd van je organisatie.

Werk in elk van deze gevallen de pakketten samen met renv in je project bij (renv::update() en daarna renv::snapshot()). Anders krijgt het record de nieuwe versie, de afhankelijkheden ervan en de hash van renv, en accepteert fremforge het bestand alleen als elk ander record, de R-versie en de repository’s ongewijzigd zijn.

Gedeelde versies

Een versie die op één plek staat en door meerdere afhankelijkheden wordt gelezen, zoals een eigenschap in pom.xml (<logback.version>), een Gradle-variabele in gradle.properties of een regel in een versiecatalogus ([versions] logback = "1.5.12"), verplaatst al die afhankelijkheden wanneer ze wordt verhoogd. fremforge leest elke pom.xml, of elk Gradle-buildbestand en elke catalogus, in de pull request.

Een eigenschap in pom.xml wordt verhoogd als de verhoging voor elke lezer klopt. Elke andere afhankelijkheid die haar leest, moet openstaande kwetsbaarheden in de repository hebben (op de standaardbranch), op of onder de nieuwe versie zijn opgelost, en op die versie gepubliceerd zijn op de Maven-proxy van je organisatie. De pull request vermeldt die afhankelijkheden dan onder Also updated by this pull request en sluit hun bevindingen wanneer hij wordt samengevoegd. Als twee fixverzoeken dezelfde verhoging zouden doen, houdt het verzoek voor het pakket dat als eerste wordt gesorteerd haar, en eindigt het andere met PR gesloten: gedeelde versie, met de naam van het eerste.

Anders, en altijd bij een Gradle-variabele of catalogusregel, een fix voor een releasebranch of een versie die zo wordt gelezen dat fremforge haar niet aan een afhankelijkheid kan koppelen, wordt de pull request gesloten als PR gesloten: gedeelde versie, en zegt het veld detail van het verzoek welke lezer niet aan welke voorwaarde voldeed (geen openstaande kwetsbaarheid, geen gefixte versie, heeft een hogere versie nodig, niet gepubliceerd op de nieuwe versie). Verhoog de gedeelde versie dan zelf, zodat jij de versie voor allemaal kiest: de fix voor het kwetsbare pakket bestaat misschien niet als release van de andere (een bibliotheekfamilie brengt vaak een patchrelease van maar één artifact uit). Een versie die alleen het kwetsbare pakket leest, wordt gewoon verhoogd.

Alles herstelbare in een repository herstellen

Op Aanbevelingen heeft elke repository met twee of meer pakketten die fremforge nu kan herstellen een knop Alles in deze repository herstellen. Die vraagt om één pull request per pakket (en per basisimage, zie hieronder), of, in een repository die haar fixes bundelt, één per lockfile, bekend misbruikte eerst, daarna de hoogste ernst. De verzoeken worden samen toegelaten binnen je limieten: zodra een repository 3 openstaande pull requests voor beveiligingsfixes heeft, of je organisatie haar 20 verzoeken voor die dag heeft gebruikt, wordt de rest niet aangevraagd, en het resultaat zegt hoeveel er wel zijn aangevraagd. Een pakket waarvoor al een verzoek bestaat, wordt overgeslagen.

Met de API: POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests met {"repo": "<name>"} antwoordt 202 met één uitkomst per pakket (queued, of refused met een reason), of 200 als er niets in de wachtrij is gezet.

Gebundelde fixes

In een repository die onder Gebundelde repositories (grouped_repos) staat, gaan de fixes van één lockfile in één pull request, zoals Dependabot-groepen, in plaats van één per pakket. Elke andere repository houdt één pull request per pakket, en dat geldt standaard voor elke repository.

• Wat wordt gebundeld: pakketten van één lockfile (één ecosysteem, één manifest, één basisbranch) waarvan de fix binnen de geïnstalleerde hoofdversie blijft, in npm (met pnpm en Yarn), PyPI, Go, Cargo en NuGet. Er gaan maximaal 20 pakketten in één groep; meer leveren een tweede groep op.
• Wat niet: een fix die een nieuwe hoofdversie nodig heeft, een basisimage, een pin van een CI-action, en pakketten van Gradle, Maven, Composer, RubyGems, Hex en CRAN. Elk daarvan is zoals voorheen een eigen pull request.
• Wanneer: Alles in deze repository herstellen en automatische beveiligingsfixes. Een losse Fix-PR openen op één bevinding blijft één pull request voor dat pakket.
• Limieten: een groep telt als één pull request voor Open fix-pull-requests per repository en als één verzoek voor Fix-pull-requests per dag. Een pakket dat al een eigen verzoek heeft, of in de laatste 10 minuten is geprobeerd, blijft buiten de groep in plaats van herhaald te worden.
• Elk pakket houdt zijn eigen verzoek. De pull request noemt elk pakket met zijn gefixte versie, en de bevindingen van elk pakket worden gesloten wanneer hij wordt samengevoegd, net als bij een losse fix. Een pakket dat de run niet samen met de andere kon bijwerken, of alleen kon bijwerken naar een versie onder de fix (zie Elke kopie, op de fixversie onder Wat er gebeurt als je op Fix-PR openen klikt), blijft erbuiten en wordt in de pull request genoemd. Het houdt zijn eigen verzoek: een pakket dat op zijn release-leeftijd wacht, wordt later opnieuw aangevraagd, en een pakket dat het manifest niet noemt (een transitieve afhankelijkheid), wordt afzonderlijk vastgepind door de transitieve fix. Een buitengesloten pakket houdt de groep nooit op.
• In de console toont Activiteit een gebundelde pull request één keer, als Gebundeld · N pakketten met elk pakket en zijn versie. In de API draagt elk verzoek in een groep hetzelfde group_id (bij POST .../requests met repo, en bij GET .../requests).

Verhogingen van het basisimage

Voor een kwetsbaarheid in een image dat naar het register van je organisatie is gepusht, kan fremforge de FROM-basis van het image ophogen in de Dockerfile waarmee het is gebouwd. Fix-PR voor basisimage openen bij de bevinding (onder Beveiliging › Bevindingen › Containerimages) is er wanneer aan al het volgende is voldaan:

1. fremforge weet met welke repository en commit het image is gebouwd, op een van twee manieren:

   • het image noemt ze, met de OCI-labels org.opencontainers.image.source en org.opencontainers.image.revision (docker/metadata-action zet ze allebei). De labels gaan voor als ze aanwezig zijn;
   • of, zonder zulke labels, het image is gepusht door een fremforge Actions-run van een repository in je organisatie: het register van fremforge legt vast welke run elk manifest heeft gepusht, en de repository en commit zijn die van die run. Elke push van het image moet komen van Actions-runs van die ene repository; een image dat ook van elders is gepusht (een laptop, een andere CI), of door een run van een repository van een andere organisatie, wordt niet op deze manier toegeschreven.

   De bevinding zegt met welke repository en Dockerfile het image is gebouwd en hoe fremforge dat weet (“uit de labels van het image” of “uit de Actions-run die het heeft gepusht”), en de API ook (base_attribution bij elke image-bevinding).

2. fremforge heeft in die commit de Dockerfile gevonden op wiens FROM-basis het image is gebouwd: de lagen van het basisimage zijn de eerste lagen van je image.

3. Trivy plaatst het kwetsbare pakket in een van die basislagen, niet in een laag die je Dockerfile toevoegt.

4. De nieuwste basis van dezelfde lijn (dezelfde hoofdversie en tagvorm, of de nieuwere digest van dezelfde tag bij een zwevende tag), door fremforge gescand met dezelfde kwetsbaarheidsdatabase, heeft de kwetsbaarheid niet meer.

Deze analyse draait mee met de dagelijkse image-scan. De pull request wijzigt alleen die FROM-regel: de tag, en de digest die fremforge ervoor heeft gescand. Een wijziging aan een andere regel of een ander bestand, of een andere digest dan die fremforge heeft gescand, sluit hem. Elke openstaande bevinding van het image die dezelfde basis oplost, staat in één pull request.

Als er geen knop is, zegt de bevinding waarom:

Nadat je de pull request hebt samengevoegd en het opnieuw gebouwde image onder dezelfde tag hebt gepusht, vergelijkt fremforge het nieuwe image met het oude zodra het nieuwe is gescand. Elke bevinding van de oude digest die het nieuwe image niet meer heeft, wordt als opgelost door fremforge gesloten (fixed_source: security_fix), zolang de oude digest niet meer in gebruik is: hij heeft geen tag meer, hij zit niet in de laatste live-uitrol van een repository en omgeving, en niemand behalve de eigen bots van fremforge heeft hem in de laatste 7 dagen via digest gepulld. De bevindingen van de oude digest blijven onder die digest vermeld zolang het image in je register bestaat.

Is de oude digest nog in gebruik, dan wordt niets gesloten: de bevinding toont Opgelost in nieuwere image met de nieuwe digest, en zegt waarom ze openblijft (nog getagd, nog uitgerold, of recent gepulld). Ze sluit zodra de oude digest niet meer in gebruik is, en gaat weer open als die digest opnieuw in gebruik komt.

Na het samenvoegen

Wanneer de pull request is samengevoegd en de volgende scan van de standaardbranch een bevinding niet meer meldt, wordt de bevinding gesloten. Haar geschiedenis in het compliancerapport legt vast dat ze is opgelost door een beveiligingsfix (fixed_source: security_fix; rijen die vóór 2026-10-14 zijn vastgelegd, zeiden autofix). Een bevinding die is gesloten door een van de eigen beveiligings-pull-requests van gehost Renovate, wordt vastgelegd als fixed_source: renovate. Herstelmetrieken tellen beide.

Limieten

• Eén actief verzoek per (repository, pakket) op elke branch. Een tweede verzoek voor hetzelfde pakket op dezelfde branch krijgt als antwoord already requested. Een fix naar een beschermde releasebranch is een apart verzoek, los van dat voor de standaardbranch.
• Standaard maximaal 3 openstaande pull requests voor beveiligingsfixes per repository; 0 tot 10.
• Standaard maximaal 20 verzoeken per organisatie in elke 24 uur; 0 tot 50.
• Een gebundelde pull request telt voor beide als één.

Ze gelden voor klikken en automatische beveiligingsfixes samen. AI-fix heeft eigen limieten. Als er geen pull request wordt geopend, zie Probleemoplossing.

API

• Een fix aanvragen POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:write (findings:write wordt ook geaccepteerd). De body noemt precies één van:

  • finding_id: één afhankelijkheidsbevinding. Eén pull request voor het pakket ervan. Antwoordt 202 met het id van het verzoek, de doelversie, de sleutels van de bevindingen die het dekt, known_exploited_cves (de CVE-id’s van bekend misbruikte kwetsbaarheden die het oplost; leeg als er geen zijn) en automerge.
  • repo: elk herstelbaar pakket in die repository, elk één pull request, of één per lockfile in een gebundelde repository. Antwoordt 202 met één uitkomst per pakket (queued met zijn group_id, null als het niet gebundeld is, of refused met een reason), of 200 als er niets in de wachtrij is gezet.
  • image_finding_id: een verhoging van het basisimage. Weigeringen zijn onder meer image_not_from_base, image_no_base_fix, image_source_unknown en image_not_attributed.

  Een weigering is problem+json met als type security-fix-<reason> en een veld reason, bijvoorbeeld no_fixed_version, ecosystem_not_supported, manifest_not_supported of sbom_finding. Elk daarvan wordt beschreven onder API-fouten.

• Verzoeken opvragen GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, scope dependency-updates:read, met de status en pull request van elk verzoek.

• Instellingen GET en PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings; zie Instellingen.

• Wie beveiligings-pull-requests opent GET en PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane; zie Overnemen van Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates bevat security_fixes_bot, true als de afhankelijkhedenbot voor beveiligingsfixes bestaat. Het veld enrolled daarin betekent dat Versie-updates aan staan.

• Tellers GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics: verzoeken, geopende, samengevoegde en gesloten pull requests, acceptatiegraad, pull requests die zonder goedkeurende review zijn samengevoegd, en bevindingen die door een beveiligingsfix zijn opgelost.

Elke afhankelijkheidsbevinding die GET /_app/api/v1/orgs/{org}/code-security/deps/findings teruggeeft, bevat autofix_eligible, autofix_unavailable_reason (waarom een bevinding met een fix niet wordt gedekt) en autofix, het laatste verzoek dat haar dekt. Elke image-bevinding van GET .../code-security/images/findings bevat dezelfde drie velden voor verhogingen van het basisimage.

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"

Verouderde API

Deze paden, velden en scopes blijven werken tot 2027-10-15. Tot dan bevat elk antwoord van een verouderd pad Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT en een Link-header met rel="successor-version" die de opvolger noemt.

Overnemen van Renovate

Totdat een organisatie overstapt, bedienen de eigen pull requests voor kwetsbaarheidsmeldingen van gehost Renovate haar naast deze baan (lane_owner: renovate). Wanneer de baan Beveiligingsfixes het overneemt (lane_owner: security_lane), opent Renovate alleen nog versie-updates, zodat elke fix één keer wordt voorgesteld. Openstaande beveiligings-pull-requests van Renovate worden gesloten, met een opmerking die naar de vervangende fix-pull-request linkt, zodra deze baan een fix-pull-request heeft voor elk pakket dat ze ophogen; tot dan blijven ze open.

Voor klanten gebeurt de overstap voorlopig op verzoek: vraag het aan support. fremforge zet zijn eigen organisaties zelf over. De API is PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane met {"lane_owner": "security_lane"} (of "renovate" om terug te schakelen), scope dependency-updates:write; GET op hetzelfde pad geeft de huidige waarde terug, en ook unsupported_ecosystems (een object van ecosysteem naar het aantal openstaande herstelbare bevindingen die de baan niet oplost) en unsupported_total, zodat je vooraf kunt zien of een overstap zou worden geweigerd. Overnemen wordt geweigerd tenzij de baan kan handelen:

• Beveiligingsfixes staan op Uit: 409 security-lane-lane-off. Kies eerst een andere modus dan Uit, of stuur "acknowledge": ["no_security_prs"] mee om te accepteren dat er helemaal geen beveiligings-pull-requests worden geopend.
• Openstaande bevindingen in ecosystemen die de baan niet oplost (bijvoorbeeld CRAN of Conan, die de meldingen van Renovate wel dekken): 409 security-lane-unsupported-ecosystems, waarvan unsupported_ecosystems de openstaande herstelbare bevindingen per ecosysteem opsomt. Stuur "acknowledge": ["unsupported_ecosystems"] mee om toch over te stappen; die bevindingen krijgen dan geen automatische pull request.

Bij de overstap gaan pull requests voor beveiligingsfixes Wanneer fixes worden gemerged volgen, in organisaties waar ze tot dan op review wachtten; zie Samenvoegen.

De overstap wordt in de auditlog vastgelegd als dependency-updates.security-lane.enabled, en terugschakelen als dependency-updates.security-lane.disabled.

Audit

Elke stap staat in de auditlog: autofix.proposed, autofix.pr_opened, autofix.rejected (met de reden), autofix.relocked (een lockfile-commit vanuit je eigen CI, met de run), autofix.relock_refused (een jobtoken die niet van de gestarte run was), autofix.merged en autofix.closed, elk met de sleutels van de bevindingen en engine: deterministic. autofix.proposed van een fix voor een bekend misbruikte kwetsbaarheid bevat ook knownExploitedCves. Een wijziging van de instellingen is dependency-updates.security-fixes.updated.

AI-fixes voor SAST-bevindingen

Door AI gegenereerde fixes voor SAST-bevindingen hebben een eigen pagina gekregen: AI-fix.

Zie ook

• Updates van afhankelijkheden: beide banen en de bot.
• Samenvoegen: review, samenvoegen als alles groen is, het merge-venster en de releasefreeze.
• Probleemoplossing: als er geen pull request wordt geopend.
• OSV-aanbevelingen: de kaarten waarop de knop Fix-PR openen staat.
• Checklist voor de inrichting: je limieten en aanmeldingen in één oogopslag op Beveiliging › Overzicht.