Branch-skydd

Branch-skydd på fremforge följer Forgejos modell uppströms: regler kopplas till brancher via globmönster, ställer krav på granskning, status och historik, och blockerar skrivningar som bryter mot dem. fremforge lägger till organisationsövergripande standardvärden så att samma hållning gäller för varje repo utan att konfigurationen per repo glider isär.

Organisationsstandard kontra åsidosättningar per repo

Säkerhet › Policyer › Repo-regler anger reglerna som gäller för varje repo i organisationen. Ett nytt repo får en regel för varje mönster i organisationens lista över skyddade brancher (main, master, release/* som standard), plus sin standardbranch om inget mönster täcker den, när det skapas. Det gäller även ett tomt repo, till exempel ett som skapats med POST /api/v1/orgs/{org}/repos: det skyddas direkt, och bara standardfilerna utelämnas tills det har en första commit. När du sparar standardvärdena tillämpas de direkt på organisationens befintliga repon, och en avstämning som körs varje timme gör samma genomgång som skyddsnät. På ett repo utan skydd skapar den organisationens regler och, om organisationen har sparat sina repo-regler, sätter repots standardsätt att merga och borttagning av branch efter merge till organisationens värden. På ett repo med egna regler lägger den till regler för de organisationsmönster som repot saknar, och ändrar annars bara de få inställningar som listas under Vad organisationsstandarden ändrar i befintliga regler. Den skriver aldrig över en regel som en repo-administratör har satt. Repon som redan har skydd men har glidit till något svagare än organisationsstandarden lyfts fram av avvikelsedetektorn som ett larm i stället för att återställas automatiskt (se nedan).

Organisationer som aldrig har sparat repo-regler

En organisation som aldrig har sparat Repo-regler får fremforges grundnivå, när repot skapas och vid genomgången varje timme, som om den hade sparat den: en pull request krävs, med 1 godkännande, inaktuella godkännanden avfärdas, fremforges obligatoriska kontroller, force-push blockeras och ägare omfattas, på main, master, release/* och repots standardbranch. Fram till 28 oktober 2026 fick en sådan organisations repon en main-regel som tillät direkt push när de skapades, och ingenting från genomgången varje timme.

För att ändra det öppnar du Säkerhet › Policyer › Repo-regler, ställer in det du vill och sparar: dina sparade regler ersätter grundnivån. Om du inte vill att fremforge ska tillämpa något skydd alls avmarkerar du Tillämpa branch-skydd på nya repon och sparar. Organisationen lämnas då utanför genomgången varje timme, och dess repon behåller de regler de redan har.

Tomma repon

En regel som kräver en pull request nekar också den push som skulle skapa branchen, och ett tomt repo har ingen branch som en pull request kan rikta sig mot. Så länge ett repo är tomt är dess regler därför kompletta men accepterar ändå en direkt push. Pusha din första commit till standardbranchen som vanligt. Så snart fremforge tar emot den pushen, inom några sekunder, blir reglerna enbart för pull requests som i alla andra repon, så att en andra direkt push nekas.

Åsidosättningar per repo finns på repots inställningssida (/<org>/<repo>/settings/branches). Åsidosätt bara när repot har ett verkligt policyundantag; de flesta team ställer in organisationsstandarden en gång och rör aldrig reglerna på repo-nivå.

Inställningar som motsvarar Forgejo direkt

Kräv en pull request. Direkta push till den skyddade branchen nekas (Forgejos enable_push: false), så en pull request är enda vägen in. Det är det som gör obligatoriska granskningar och kontroller bindande: en direkt push hoppar över den pull request de är kopplade till. Påslaget i fremforges grundnivå. fremforges egen automatisering (uppdateringar av beroenden, AutoFix, efterfyllnaden av .gitattributes) öppnar också pull requests, så den fortsätter att fungera på en branch som bara tar emot pull requests.
Kräv granskning av pull requests före merge. Ange ett minsta antal granskare (vanligtvis 1 eller 2). Avfärda inaktuella granskningar vid push så att ett slentriangodkännande inte överlever en force-amend.
Kräv att statuskontroller går igenom före merge. Ange de statuskontexter som måste rapportera framgång. fremforges organisationsstandard kräver sju, och om du bara kräver några av dem kan de övriga inte blockera en merge:
- fremforge/sast: statisk analys
- fremforge/dep-scan: sårbarheter i beroenden
- fremforge/license-scan: licenspolicy
- fremforge/image-scan: sårbarheter och hemligheter i repots container-images och filer
- fremforge/cosign-verify: signaturverifiering av images som är låsta med digest (informativ: den går alltid igenom; se Image-signaturer)
- fremforge/secret-scan: upptäckt av incheckade hemligheter
- fremforge/release-age: håller tillbaka en automatisk pull request för uppdatering av beroenden tills varje version som dess låsfil löser upp har varit publicerad i minst organisationens release-ålder (3 dagar om inte en ägare har ändrat det; 24 timmar för en fix som ett granskat säkerhetsmeddelande anger, spåret för säkerhetsfixar)
En åttonde, fremforge/iac-scan (felkonfiguration i infrastruktur som kod, se IaC-skanning), rapporterar på varje pull request sedan 17 oktober 2026 och blir en obligatorisk kontroll organisation för organisation, så att ingen pull request som öppnades innan den fanns väntar på den. Tills den är obligatorisk för din organisation rapporterar den utan att blockera på egen hand; du kan själv lägga till den bland dina obligatoriska kontroller när som helst.
Organisationsstandarden kräver alla sju; om du ställer in obligatoriska kontroller för hand, lista alla sju, och fremforge/iac-scan om du vill att den ska blockera. fremforge/release-age blockerar bara automatiska pull requests för uppdatering av beroenden, och bara tills deras versioner når release-åldern; på en pull request som öppnats av en person rapporterar den färska versioner utan att hålla tillbaka pull requesten. En skanner som du sätter till off för en organisation eller ett repo tas bort från dess obligatoriska kontroller inom en timme, eftersom en avstängd skanner inte rapporterar något. Se Köra om skanningar för vad var och en omfattar.
Kräv signerade commits. När det är påslaget nekas osignerade commits på den skyddade branchen vid push. Se Cosign för commit-signering med kortlivade Sigstore-certifikat.
Kräv linjär historik. När det är påslaget stänger fremforge av merge-commits i repot: merge sker bara med squash eller rebase, så att den skyddade branchen behåller en linjär historik.
Blockera force-push. Nekar --force på den skyddade branchen helt.
Blockera borttagning av branch. En skyddad branch kan inte tas bort. Det följer av att ha en branch-skyddsregel kopplad, och är inte en separat inställning. Så länge branchen är skyddad nekas borttagningar av den.

Inställningar som fremforge lägger till

Tillämpa skyddet även för organisationens ägare/administratörer. En inställning per tenant på administrationssidan för repon, “Tillämpa skyddet även för organisationens ägare/administratörer” (Forgejos apply_to_admins), som är påslagen som standard. Påslagen behöver en pull request som öppnats av en organisationsägare de obligatoriska godkännandena precis som alla andras; avstängd frångås kravet på antal godkännanden för pull requests som en organisationsägare öppnar. Inställningen styr bara godkännanden. Obligatoriska statuskontroller gäller för varje pull request, och en organisationsägare kan, som repo-administratör, fortfarande medvetet merga förbi dem med Forgejos force merge (“merge anyway” i merge-rutan, eller force_merge i merge-API:t). Det är nödutgången för en kontroll som har fastnat eller blivit fel; den mergar en ändring som kontrollerna inte har godkänt, så använd den sparsamt. Om du vill att en fremforge-kontroll inte ska blockera alls sätter du i stället dess skanner till audit eller off för organisationen eller repot. För att beroendefynd som inte är nåbara inte ska blockera fremforge/dep-scan finns en valfri policy: se Nåbarhet: blockera inte på ej nåbara fynd, och läs om risken först.
Kräv granskning från kodägare. Sätter Forgejos Block merge on official review requests på de skyddade branchreglerna. När en pull request öppnas gör en CODEOWNERS-fil (i repots rot, i docs/, .forgejo/ eller .gitea/) att Forgejo begär granskning från ägarna till de ändrade sökvägarna; med den här inställningen påslagen kan pull requesten inte mergas medan någon av de begäranden är öppen, så kodägarna måste granska den. Två saker att känna till: den blockerar på varje öppen granskningsbegäran till en officiell granskare, även en som du lägger till för hand; och en kodägare som inte får godkänna på branchen (till exempel någon som inte är ägare när godkännanden är begränsade till teamet Owners) är inte en officiell granskare, så hens begäran blockerar inte. Utan en CODEOWNERS-fil begärs ingen automatiskt och inställningen ändrar ingenting.
Tillåtelselista för statuskontroller som fremforge skickar. De sju kanoniska namnen listas ovan. De hålls på ett enda ställe internt, gemensamt för installationen när repot skapas och efterfyllnaden varje timme, så att uppsättningen ett nytt repo får och uppsättningen efterfyllnaden tillämpar inte kan glida isär.
Avvikelsedetektor. En separat daglig skanning efter luckor flaggar varje repo vars branch-skydd saknas eller är svagare än organisationsstandarden, där svagare betyder färre obligatoriska godkännanden eller en obligatorisk kontroll som standarden kräver och repot saknar. (Efterfyllnaden ovan körs varje timme och fyller bara i repon utan skydd; den här dagliga skanningen är det som märker ett repo som har skydd men har lättats upp.) Det visas som ett eget larm i administratörens klocka, “N repon med försvagat branch-skydd”, som länkar till administrationssidan för repon. Bortsett från inställningarna i nästa avsnitt upptäcker och larmar den bara: fremforge återställer inte försvagade inställningar automatiskt, eftersom en repo-ägares uttryckliga inställningar har företräde. Använd larmet för att avgöra om du ska följa upp med repots ägare.

Vad organisationsstandarden ändrar i befintliga regler

I ett repo som redan har eget skydd lämnar fremforge reglerna i fred, med undantag för följande, som var och en ändras för sig utan att någon annan inställning i regeln påverkas:

fremforges obligatoriska kontroller läggs till, och tas bort för en skanner som är satt till off.
Tillämpa skyddet även för organisationens ägare/administratörer följer organisationens inställning, åt båda hållen.
Kräv en pull request, när organisationen har det påslaget, gör även befintliga regler till enbart pull requests. En regel som anger vem som får pusha (en tillåtelselista för push med användare, team eller deploy-nycklar) lämnas som den är: det är ett medvetet val att låta någon pusha, och avvikelsedetektorn fortsätter att rapportera det.
Kräv granskning från kodägare, när organisationen har det påslaget, slås på i befintliga regler.
Saknade mönster. En regel skapas för ett organisationsmönster (eller standardbranchen) som repot inte har någon regel för. Att skapa den ändrar aldrig en befintlig regel.

De två sista skärper bara. Stänger du av någon av dem på organisationsnivå slutar den att tillämpas på nya regler; regler som redan har den behåller den tills en repo-administratör ändrar dem i repots branchinställningar.

Bara regler på organisationens skyddade branchmönster (och standardbranchen) berörs. Varje ändring listas, per repo, i granskningshändelsen repo-defaults.branch-protection.retro-applied. Fram till 28 oktober 2026 lade fremforge aldrig till en regel för ett mönster som en repo-administratör hade lämnat oskyddat; det gör den nu, så för att hålla en branch oskyddad tar du bort dess mönster från organisationens lista över skyddade brancher.

Borttaget: standardmall för repon

Sidan för repon hade tidigare fältet Default repository template. Det togs bort 2026-10-14 eftersom det sparades men aldrig tillämpades: repon skapas i Forgejo, och Forgejo kan bara generera ett nytt repo från en mall, inte fylla ett som en medlem redan har skapat. För att starta repon från en mall markerar du källrepot som mall i dess inställningar och väljer det i Forgejos formulär New Repository, eller anropar POST /api/v1/repos/{template_owner}/{template_repo}/generate. API:t nekar nu ett värde för default_template_repo med removed-setting.

Ställa in det

Öppna Säkerhet › Policyer › Repo-regler.
Välj branchens globmönster (vanligtvis main eller main, master, release/*).
Ställ in alternativen ovan. Spara.
Ändringen registreras i granskningsloggen som repo-defaults.branch-protection.updated. En retroaktiv tillämpning på befintliga repon utan skydd loggas som repo-defaults.branch-protection.retro-applied, och en återställning av organisationens standardvärden till fremforges grundnivå loggas som repo-defaults.reset-baseline.

Se även

Scorecard: branch-skydd styr OpenSSF-poängen Branch-Protection.
Autentiseringspolicy: den bredare hållningen (signerade commits, SSH-transport, MFA).
Cosign: implementationen av krav på signerade commits.

Aviseringar om fynd Daglig sammanfattning av varningar