Branchbescherming

Branchbescherming op fremforge volgt het model van upstream Forgejo: regels worden via een glob-patroon aan branches gekoppeld, dwingen eisen af voor reviews, statussen en geschiedenis, en blokkeren schrijfacties die ze schenden. fremforge voegt daar standaarden voor de hele organisatie aan toe, zodat dezelfde instellingen voor elke repository gelden zonder dat configuraties per repository uit elkaar gaan lopen.

Standaarden van de organisatie versus overschrijvingen per repository

Beveiliging › Beleid › Repositoryregels stelt de regels in die voor elke repository in de organisatie gelden. Een nieuwe repository krijgt bij het aanmaken één regel voor elk patroon in de lijst met beschermde branches van de organisatie (standaard main, master, release/*), plus de standaardbranch als geen patroon die dekt. Dat geldt ook voor een lege repository, zoals een die is aangemaakt met POST /api/v1/orgs/{org}/repos: die is meteen beschermd, en alleen de standaardbestanden blijven weg totdat er een eerste commit is. Als je de standaarden opslaat, worden ze direct toegepast op de bestaande repository’s van de organisatie, en een reconciler die elk uur draait, doet dezelfde ronde als vangnet. Op een repository zonder bescherming maakt hij de regels van de organisatie aan en, als de organisatie haar repositoryregels heeft opgeslagen, stelt hij de standaard merge-stijl en het verwijderen van de branch na het samenvoegen in op de waarden van de organisatie. Op een repository met eigen regels voegt hij regels toe voor elk patroon van de organisatie dat de repository mist, en verandert hij verder alleen de paar instellingen onder Wat de standaard van de organisatie verandert aan bestaande regels. Hij overschrijft nooit een regel die een beheerder van de repository heeft ingesteld. Repository’s die al bescherming hebben maar zwakker zijn geworden dan de standaard van de organisatie, worden door de afwijkingsdetector als melding getoond in plaats van automatisch teruggezet (zie hieronder).

Organisaties die nooit repositoryregels hebben opgeslagen

Een organisatie die nooit Repositoryregels heeft opgeslagen, krijgt bij het aanmaken en in de uurlijkse ronde de fremforge-basislijn, alsof ze die had opgeslagen: een pull request is vereist, met 1 goedkeuring, verouderde goedkeuringen worden verworpen, de verplichte fremforge-checks, force-pushes geblokkeerd en eigenaren inbegrepen, op main, master, release/* en de standaardbranch van de repository. Tot 28 oktober 2026 kregen de repository’s van zo’n organisatie bij het aanmaken een main-regel waarop direct gepusht kon worden, en niets uit de uurlijkse ronde.

Om dat te veranderen open je Beveiliging › Beleid › Repositoryregels, stel je in wat je wilt en sla je op: je opgeslagen regels vervangen de basislijn. Wil je helemaal geen bescherming door fremforge laten toepassen, vink dan Branchbescherming toepassen op nieuwe repositories uit en sla op. De organisatie valt dan buiten de uurlijkse ronde, en haar repository’s houden de regels die ze al hebben.

Lege repository’s

Een regel die een pull request vereist, weigert ook de push die de branch zou aanmaken, en een lege repository heeft geen branch waarop een pull request zich kan richten. Zolang een repository leeg is, zijn de regels daarom compleet maar accepteren ze nog een directe push. Push je eerste commit zoals gewoonlijk naar de standaardbranch. Zodra fremforge die push ontvangt, binnen enkele seconden, worden de regels net als bij elke andere repository alleen-via-pull-request, zodat een tweede directe push wordt geweigerd.

Overschrijvingen per repository staan op de instellingenpagina van de repository (/<org>/<repo>/settings/branches). Overschrijf alleen als de repository een echte uitzondering op het beleid heeft; de meeste teams stellen de standaard van de organisatie één keer in en komen nooit aan regels op repositoryniveau.

Instellingen die direct overeenkomen met Forgejo

Pull request vereisen. Directe pushes naar de beschermde branch worden geweigerd (Forgejo’s enable_push: false), dus een pull request is de enige weg naar binnen. Dit maakt verplichte reviews en checks bindend: een directe push slaat de pull request over waaraan ze gekoppeld zijn. Staat aan in de fremforge-basislijn. De eigen automatisering van fremforge (afhankelijkheidsupdates, AutoFix, de backfill van .gitattributes) opent ook pull requests, dus die blijft werken op een branch die alleen pull requests toelaat.
Pull request-reviews vereisen vóór het samenvoegen. Stel een minimumaantal reviewers in (meestal 1 of 2). Verwerp verouderde reviews bij een push, zodat een goedkeuring op de automatische piloot een force-amend niet overleeft.
Statuschecks moeten slagen vóór het samenvoegen. Noem de statuscontexten die succes moeten melden. De standaard van fremforge voor de organisatie vereist er zeven, en als je er maar een deel van vereist, kunnen de andere een merge niet blokkeren:
- fremforge/sast: statische analyse
- fremforge/dep-scan: kwetsbaarheden in afhankelijkheden
- fremforge/license-scan: licentiebeleid
- fremforge/image-scan: kwetsbaarheden en secrets in de container-images en bestanden van de repository
- fremforge/cosign-verify: handtekeningverificatie van images die op digest zijn vastgepind (informatief: slaagt altijd; zie Image-handtekeningen)
- fremforge/secret-scan: detectie van gecommitte secrets
- fremforge/release-age: houdt een automatische pull request voor een afhankelijkheidsupdate vast totdat elke versie die het lockbestand oplost, minstens zo lang is gepubliceerd als de releaseleeftijd van je organisatie (3 dagen, tenzij een eigenaar dat heeft gewijzigd; 24 uur voor een fix die in een gereviewde advisory wordt genoemd, de security-fix-baan)
Een achtste, fremforge/iac-scan (misconfiguraties in infrastructure-as-code, zie IaC-scans), wordt sinds 17 oktober 2026 op elke pull request geplaatst en wordt per organisatie een verplichte check, zodat geen pull request die is geopend voordat hij bestond, erop wacht. Totdat hij voor je organisatie verplicht is, meldt hij zonder zelf te blokkeren; je kunt hem op elk moment zelf aan je verplichte checks toevoegen.
De standaard van de organisatie vereist alle zeven; als je verplichte checks met de hand instelt, noem ze dan alle zeven, en fremforge/iac-scan als je wilt dat die blokkeert. fremforge/release-age blokkeert alleen automatische pull requests voor afhankelijkheidsupdates, en alleen totdat hun versies de releaseleeftijd hebben bereikt; op een pull request die een persoon heeft geopend, meldt hij nieuwe versies zonder de PR vast te houden. Een scanner die je voor een organisatie of repository op off zet, wordt binnen het uur uit de verplichte checks gehaald, omdat een scanner op off niets plaatst. Zie Scans opnieuw uitvoeren voor wat elke scanner dekt.
Ondertekende commits vereisen. Als dit aanstaat, worden niet-ondertekende commits op de beschermde branch bij de push geweigerd. Zie Cosign voor commitondertekening met kortlevende Sigstore-certificaten.
Lineaire geschiedenis vereisen. Als dit aanstaat, schakelt fremforge merge-commits op de repository uit: samenvoegen kan alleen met squash of rebase, zodat de beschermde branch een lineaire geschiedenis houdt.
Force-pushes blokkeren. Weigert --force op de beschermde branch volledig.
Verwijderen van de branch blokkeren. Een beschermde branch kan niet worden verwijderd. Dat volgt uit het hebben van een branchbeschermingsregel en is geen aparte schakelaar. Zolang de branch beschermd is, worden verwijderacties erop geweigerd.

Instellingen die fremforge toevoegt

Bescherming ook afdwingen voor eigenaren/beheerders van de organisatie. Een schakelaar per tenant op de beheerpagina Repos, ‘Bescherming ook afdwingen voor eigenaren/beheerders van de organisatie’ (Forgejo’s apply_to_admins), die standaard aanstaat. Aan betekent dat een pull request die een eigenaar van de organisatie opent, net als die van ieder ander de verplichte goedkeuringen nodig heeft; uit betekent dat het aantal goedkeuringen vervalt voor pull requests die een eigenaar van de organisatie opent. De schakelaar gaat alleen over goedkeuringen. Verplichte statuschecks gelden voor elke pull request, en een eigenaar van de organisatie kan als beheerder van de repository er nog steeds bewust overheen samenvoegen met Forgejo’s force merge (‘merge anyway’ in het merge-vak, of force_merge in de merge-API). Dat is de nooduitgang voor een vastgelopen of foutieve check; je voegt dan een wijziging samen die de checks niet hebben goedgekeurd, dus gebruik hem spaarzaam. Wil je dat een fremforge-check helemaal niet blokkeert, zet de scanner dan voor de organisatie of de repository op audit of off. Wil je dat afhankelijkheidsbevindingen die niet bereikbaar zijn fremforge/dep-scan niet blokkeren, dan is er een opt-in-beleid: zie Bereikbaarheid: niet blokkeren op niet-bereikbare bevindingen, en lees eerst het risico.
Review door code-eigenaren vereisen. Zet Forgejo’s Block merge on official review requests aan op de regels van de beschermde branch. Wanneer een pull request wordt geopend, laat een CODEOWNERS-bestand (in de root van de repository, in docs/, .forgejo/ of .gitea/) Forgejo een review vragen aan de eigenaren van de gewijzigde paden; met deze instelling aan kan de pull request niet worden samengevoegd zolang een van die verzoeken nog openstaat, dus moeten de code-eigenaren hem reviewen. Twee dingen om te weten: hij blokkeert op elk openstaand reviewverzoek aan een officiële reviewer, ook een dat je met de hand toevoegt; en een code-eigenaar die op de branch niet mag goedkeuren (bijvoorbeeld iemand die geen eigenaar is wanneer goedkeuringen beperkt zijn tot het team Owners), is geen officiële reviewer, dus zijn verzoek blokkeert niet. Zonder CODEOWNERS-bestand wordt niemand automatisch gevraagd en verandert de instelling niets.
Allowlist van statuschecks voor checks die fremforge plaatst. De zeven canonieke namen staan hierboven. Intern staan ze op één plek, die wordt gedeeld door de installatie bij het aanmaken en de uurlijkse backfill, zodat de set die een nieuwe repository krijgt en de set die de backfill afdwingt niet uit elkaar kunnen lopen.
Afwijkingsdetector. Een aparte dagelijkse scan markeert elke repository waarvan de branchbescherming ontbreekt of zwakker is dan de standaard van de organisatie, waarbij zwakker betekent: minder verplichte goedkeuringen, of een check die de standaard vereist en de repository niet. (De backfill hierboven draait elk uur en vult alleen repository’s zonder bescherming aan; deze dagelijkse scan is wat een repository opmerkt die wel bescherming heeft maar is versoepeld.) Dit verschijnt als een aparte melding onder de bel in het beheer, ‘N repository’s met verzwakte branchbescherming’, die naar de beheerpagina Repos linkt. Afgezien van de instellingen in de volgende sectie is dit alleen detecteren en melden: fremforge zet verzwakte instellingen niet automatisch terug, want de expliciete instellingen van een repository-eigenaar gaan voor. Gebruik de melding om te beslissen of je het met de eigenaar van de repository opneemt.

Wat de standaard van de organisatie verandert aan bestaande regels

Op een repository die al eigen bescherming heeft, laat fremforge de regels met rust, behalve voor deze punten, die elk afzonderlijk worden gewijzigd zonder een andere instelling van de regel aan te raken:

De verplichte fremforge-checks worden toegevoegd, en weggehaald voor een scanner die op off staat.
Bescherming ook afdwingen voor eigenaren/beheerders van de organisatie volgt de instelling van de organisatie, in beide richtingen.
Pull request vereisen maakt, als de organisatie het aan heeft staan, ook bestaande regels alleen-via-pull-request. Een regel die noemt wie mag pushen (een push-allowlist van gebruikers, teams of deploy keys), blijft zoals hij is: dat is een bewuste keuze om iemand te laten pushen, en de afwijkingsdetector blijft hem melden.
Review door code-eigenaren vereisen wordt, als de organisatie het aan heeft staan, aangezet op bestaande regels.
Ontbrekende patronen. Er wordt een regel aangemaakt voor een patroon van de organisatie (of de standaardbranch) waarvoor de repository geen regel heeft. Dat aanmaken verandert nooit een bestaande regel.

De laatste twee maken alleen strenger. Als je een van beide op organisatieniveau uitzet, wordt het niet meer op nieuwe regels toegepast; regels die het al hebben, houden het totdat een beheerder van de repository ze wijzigt in de branchinstellingen van de repository.

Alleen regels op de patronen voor beschermde branches van de organisatie (en de standaardbranch) worden aangeraakt. Elke wijziging wordt per repository vermeld in het auditevent repo-defaults.branch-protection.retro-applied. Tot 28 oktober 2026 voegde fremforge nooit een regel toe voor een patroon dat een beheerder van een repository onbeschermd had gelaten; nu wel, dus als je een branch onbeschermd wilt houden, haal het patroon dan uit de lijst met beschermde branches van de organisatie.

Verwijderd: standaard-repositorytemplate

De pagina Repos had vroeger een veld Default repository template. Het is op 2026-10-14 verwijderd omdat het werd opgeslagen maar nooit toegepast: repository’s worden in Forgejo aangemaakt, en Forgejo kan alleen een nieuwe repository uit een template genereren, niet een repository vullen die een lid al heeft aangemaakt. Wil je repository’s vanuit een template starten, markeer de bronrepository dan als template in de instellingen ervan en kies die in het formulier Nieuwe repository van Forgejo, of roep POST /api/v1/repos/{template_owner}/{template_repo}/generate aan. De API weigert nu een waarde voor default_template_repo met removed-setting.

Instellen

Open Beveiliging › Beleid › Repositoryregels.
Kies de branch-glob (meestal main of main, master, release/*).
Stel de schakelaars hierboven in. Sla op.
De wijziging wordt in het auditlog vastgelegd als repo-defaults.branch-protection.updated. Een achteraf toegepaste wijziging op bestaande repository’s zonder bescherming wordt vastgelegd als repo-defaults.branch-protection.retro-applied, en het terugzetten van de standaarden van de organisatie naar de fremforge-basislijn als repo-defaults.reset-baseline.

Zie ook

Scorecard: branchbescherming bepaalt de OpenSSF-score Branch-Protection.
Authenticatiebeleid: de bredere instellingen (ondertekende commits, SSH-transport, MFA).
Cosign: de implementatie van verplicht ondertekende commits.

Imagescan Compliancerapport