Branch-beskyttelse

Branch-beskyttelse på fremforge følger upstream-modellen i Forgejo: regler knyttes til branches via glob-mønstre, håndhæver krav til review, status og historik og blokerer skrivninger, der bryder dem. fremforge tilføjer standarder for hele organisationen, så den samme sikkerhedsprofil gælder for alle repositorier, uden at konfigurationen pr. repo glider fra hinanden.

Organisationens standarder og tilsidesættelser pr. repo

Sikkerhed › Politikker › Repository-regler fastsætter de regler, der gælder for alle repositorier i organisationen. Et nyt repository får, når det oprettes, én regel for hvert mønster i organisationens liste over beskyttede branches (main, master, release/* som standard), plus sin standardbranch, hvis intet mønster dækker den. Det gælder også et tomt repository, for eksempel et oprettet med POST /api/v1/orgs/{org}/repos: det er beskyttet med det samme, og kun standardfilerne venter, til det har sin første commit. Når du gemmer standarderne, anvendes de straks på organisationens eksisterende repositorier, og en afstemning, der kører hver time, gennemfører den samme kørsel som sikkerhedsnet. På et repository uden beskyttelse opretter den organisationens regler og, hvis organisationen har gemt sine repository-regler, sætter repoets standard-merge-metode og sletning af branch efter merge til organisationens værdier. På et repository med egne regler tilføjer den regler for de mønstre fra organisationen, som repoet mangler, og ændrer ellers kun de få indstillinger, der er nævnt under Hvad organisationens standard ændrer i eksisterende regler. Den overskriver aldrig en regel, som en repo-administrator har sat. Repositorier, der allerede har beskyttelse, men er gledet til et svagere niveau end organisationens standard, vises af afvigelsesdetektoren som en advarsel i stedet for at blive rullet tilbage automatisk (se nedenfor).

Organisationer, der aldrig har gemt repository-regler

En organisation, der aldrig har gemt Repository-regler, får fremforges basislinje ved oprettelse og i den timevise kørsel, som om den havde gemt den: en pull request er påkrævet med 1 godkendelse, forældede godkendelser afvises, fremforges påkrævede tjek gælder, force-push er blokeret, og ejere er omfattet, på main, master, release/* og repoets standardbranch. Indtil 28. oktober 2026 fik sådan en organisations repositorier en main-regel, der tillod direkte push, ved oprettelse og intet fra den timevise kørsel.

For at ændre det skal du åbne Sikkerhed › Politikker › Repository-regler, sætte det, du ønsker, og gemme: dine gemte regler erstatter basislinjen. Vil du slet ikke have, at fremforge anvender beskyttelse, så fjern fluebenet ved Anvend branch-beskyttelse på nye repoer og gem. Organisationen udelades så af den timevise kørsel, og dens repositorier beholder de regler, de allerede har.

Tomme repositorier

En regel, der kræver en pull request, afviser også det push, der ville oprette branchen, og et tomt repository har ingen branch, en pull request kunne rettes mod. Så længe et repository er tomt, er dets regler derfor komplette, men accepterer stadig et direkte push. Push din første commit til standardbranchen som normalt. Så snart fremforge modtager det push, inden for få sekunder, bliver reglerne kun-pull-request ligesom i alle andre repositorier, så et andet direkte push afvises.

Tilsidesættelser pr. repo ligger på repoets indstillingsside (/<org>/<repo>/settings/branches). Tilsidesæt kun, når repoet har en reel undtagelse fra politikken; de fleste teams sætter organisationens standard én gang og rører aldrig regler på repo-niveau.

Indstillinger, der svarer direkte til Forgejo

• Kræv en pull request. Direkte push til den beskyttede branch afvises (Forgejos enable_push: false), så en pull request er den eneste vej ind. Det er det, der gør påkrævede reviews og tjek bindende: et direkte push springer den pull request over, de er knyttet til. Slået til i fremforges basislinje. fremforges egen automatisering (afhængighedsopdateringer, AutoFix, efterudfyldning af .gitattributes) åbner også pull requests, så den fortsætter med at virke på en branch, der kun tager imod pull requests.

• Kræv reviews af pull requests før merge. Sæt et minimumsantal reviewere (typisk 1 eller 2). Afvis forældede reviews ved push, så godkendelser på autopilot ikke overlever en force-amend.

• Kræv, at statustjek består før merge. Angiv de statuskontekster, der skal melde succes. fremforges standard for organisationen kræver syv, og kræver du kun nogle af dem, kan de andre ikke blokere en merge:

  • fremforge/sast: statisk analyse
  • fremforge/dep-scan: sårbarheder i afhængigheder
  • fremforge/license-scan: licenspolitik
  • fremforge/image-scan: sårbarheder og secrets i repositoryets container-images og filer
  • fremforge/cosign-verify: signaturverifikation af images, der er fastlåst med digest (kun til orientering: det består altid; se Image-signaturer)
  • fremforge/secret-scan: registrering af committede secrets
  • fremforge/release-age: holder en automatisk pull request med afhængighedsopdateringer tilbage, indtil hver version, som dens lockfil opløser til, har været udgivet i mindst din organisations release-alder (3 dage, medmindre en ejer har ændret det; 24 timer for en rettelse, som en gennemgået advisory nævner, sporet for sikkerhedsrettelser)

  Et ottende, fremforge/iac-scan (fejlkonfiguration i infrastructure-as-code, se IaC-scanning), rapporterer på alle pull requests siden 17. oktober 2026 og bliver påkrævet organisation for organisation, så ingen pull request, der blev åbnet før det fandtes, venter på det. Indtil det er påkrævet for din organisation, rapporterer det uden selv at blokere; du kan til enhver tid selv tilføje det til dine påkrævede tjek.

  Organisationens standard kræver alle syv; sætter du påkrævede tjek manuelt, skal du angive alle syv, og fremforge/iac-scan, hvis du vil have det til at blokere. fremforge/release-age blokerer kun automatiske pull requests med afhængighedsopdateringer og kun, indtil deres versioner når release-alderen; på en pull request åbnet af en person rapporterer det nye versioner uden at holde pull requesten tilbage. En scanner, du sætter til off for en organisation eller et repo, fjernes fra dens påkrævede tjek inden for en time, da en scanner, der er off, ikke rapporterer noget. Se Kør scanninger igen for, hvad hver af dem dækker.

• Kræv signerede commits. Når den er slået til, afvises usignerede commits på den beskyttede branch ved push. Se Cosign for commit-signering med kortlivede Sigstore-certifikater.

• Kræv lineær historik. Når den er slået til, deaktiverer fremforge merge-commits på repoet: merges sker kun som squash eller rebase, så den beskyttede branch bevarer en lineær historik.

• Bloker force-push. Afviser --force på den beskyttede branch fuldstændigt.

• Bloker sletning af branch. En beskyttet branch kan ikke slettes; det følger af, at der er knyttet en regel for branch-beskyttelse til den, og er ikke en separat indstilling. Så længe branchen er beskyttet, afvises sletning af den.

Indstillinger, fremforge tilføjer

• Håndhæv også beskyttelse for organisationens ejere/administratorer. En indstilling pr. tenant på administrationssiden for repositorier, “Håndhæv også beskyttelse for organisationens ejere/administratorer” (Forgejos apply_to_admins), som er slået til som standard. Når den er slået til, skal en pull request åbnet af en ejer af organisationen have de påkrævede godkendelser ligesom alle andres; når den er slået fra, frafaldes antallet af godkendelser for pull requests, som en ejer åbner. Indstillingen styrer kun godkendelser. Påkrævede statustjek gælder for alle pull requests, og en ejer af organisationen kan som repo-administrator stadig bevidst merge forbi dem med Forgejos force merge (“merge anyway” i merge-boksen eller force_merge i merge-API’et). Det er nødudgangen for et tjek, der hænger eller er forkert; den merger en ændring, som tjekkene ikke har godkendt, så brug den sparsomt. Vil du helt forhindre, at et fremforge-tjek blokerer, så sæt dets scanner til audit eller off for organisationen eller repoet i stedet. Vil du forhindre, at afhængighedsfund, der ikke er nåbare, blokerer fremforge/dep-scan, findes der en politik, du selv skal slå til: se Reachability: bloker ikke på ikke-nåbare fund, og læs om risikoen først.
• Kræv gennemgang fra kodeejere. Sætter Forgejos Block merge on official review requests på reglerne for den beskyttede branch. Når en pull request åbnes, får en CODEOWNERS-fil (i repoets rod, i docs/, .forgejo/ eller .gitea/) Forgejo til at anmode ejerne af de ændrede stier om et review; med denne indstilling slået til kan pull requesten ikke merges, så længe nogen af disse anmodninger stadig er åbne, så kodeejerne skal gennemgå den. To ting er værd at vide: den blokerer på enhver åben anmodning om review til en officiel reviewer, også en, du selv tilføjer; og en kodeejer, der ikke må godkende på branchen (for eksempel en, der ikke er ejer, når godkendelser er begrænset til Owners-teamet), er ikke en officiel reviewer, så anmodningen til vedkommende blokerer ikke. Uden en CODEOWNERS-fil anmodes ingen automatisk, og indstillingen ændrer ingenting.
• Tilladelsesliste over statustjek, som fremforge udsender. De syv kanoniske navne er angivet ovenfor. De holdes ét sted internt, delt mellem installationen ved oprettelse og den timevise efterudfyldning, så det sæt, et nyt repo får, og det sæt, efterudfyldningen håndhæver, ikke kan glide fra hinanden.
• Afvigelsesdetektor. En separat daglig gennemgang markerer ethvert repo, hvis branch-beskyttelse mangler eller er svagere end organisationens standard; svagere betyder færre påkrævede godkendelser eller et påkrævet tjek, som standarden kræver, og som repoet ikke har. (Efterudfyldningen ovenfor kører hver time og udfylder kun repositorier uden beskyttelse; det er denne daglige gennemgang, der opdager et repo, der har beskyttelse, men er blevet løsnet.) Det vises som en særskilt advarsel i administratorens klokke, “N repositorier med svækket branch-beskyttelse”, med link til administrationssiden for repositorier. Bortset fra indstillingerne i næste afsnit registrerer og advarer den kun: fremforge ruller ikke svækkede indstillinger tilbage automatisk, fordi en repo-ejers eksplicitte indstillinger vinder. Brug advarslen til at beslutte, om du vil følge op med repoets ejer.

Hvad organisationens standard ændrer i eksisterende regler

På et repo, der allerede har sin egen beskyttelse, lader fremforge reglerne være, bortset fra disse, som hver ændres for sig uden at røre reglens øvrige indstillinger:

• fremforges påkrævede tjek tilføjes og fjernes for en scanner, der er sat til off.
• Håndhæv også beskyttelse for organisationens ejere/administratorer følger organisationens indstilling i begge retninger.
• Kræv en pull request gør, når organisationen har den slået til, også eksisterende regler til kun-pull-request. En regel, der angiver, hvem der må pushe (en tilladelsesliste for push med brugere, teams eller deploy-nøgler), forbliver som den er: det er et bevidst valg at lade nogen pushe, og afvigelsesdetektoren bliver ved med at rapportere det.
• Kræv gennemgang fra kodeejere slås, når organisationen har den slået til, til i eksisterende regler.
• Manglende mønstre. Der oprettes en regel for et mønster fra organisationen (eller standardbranchen), som repoet ikke har en regel for. Oprettelsen ændrer aldrig en eksisterende regel.

De sidste to strammer kun. Slår du en af dem fra på organisationsniveau, holder den op med at blive anvendt på nye regler; regler, der allerede har den, beholder den, indtil en repo-administrator ændrer dem i repoets branch-indstillinger.

Kun regler på organisationens mønstre for beskyttede branches (og standardbranchen) berøres. Hver ændring er opført pr. repository i revisionshændelsen repo-defaults.branch-protection.retro-applied. Indtil 28. oktober 2026 tilføjede fremforge aldrig en regel for et mønster, som en repo-administrator havde efterladt ubeskyttet; det gør den nu, så vil du holde en branch ubeskyttet, skal du fjerne dens mønster fra organisationens liste over beskyttede branches.

Fjernet: standardskabelon for repositorier

Siden for repositorier havde tidligere feltet Default repository template. Det blev fjernet 14. oktober 2026, fordi det blev gemt, men aldrig anvendt: repositorier oprettes i Forgejo, og Forgejo kan kun generere et nyt repository fra en skabelon, ikke fylde et, som et medlem allerede har oprettet. Vil du starte repositorier fra en skabelon, så markér kilderepositoryet som skabelon i dets indstillinger, og vælg det i Forgejos formular New Repository, eller kald POST /api/v1/repos/{template_owner}/{template_repo}/generate. API’et afviser nu en værdi for default_template_repo med removed-setting.

Sådan sætter du det op

1. Åbn Sikkerhed › Politikker › Repository-regler.
2. Vælg branch-globmønsteret (typisk main eller main, master, release/*).
3. Sæt indstillingerne ovenfor. Gem.
4. Ændringen registreres i revisionsloggen som repo-defaults.branch-protection.updated. En tilbagevirkende anvendelse på eksisterende repositorier uden beskyttelse logges som repo-defaults.branch-protection.retro-applied, og nulstilling af organisationens standarder til fremforges basislinje logges som repo-defaults.reset-baseline.

Se også

• Scorecard: branch-beskyttelse bestemmer OpenSSF-scoren Branch-Protection.
• Godkendelsespolitik: den bredere sikkerhedsprofil (signerede commits, SSH-transport, MFA).
• Cosign: implementeringen af påkrævede signerede commits.