Branchbeskyttelse

Branchbeskyttelse på fremforge følger upstream-modellen i Forgejo: regler knyttes til brancher med et glob-mønster, håndhever krav til gjennomgang, status og historikk, og blokkerer skrivinger som bryter dem. fremforge legger til standarder for hele organisasjonen, slik at den samme sikkerhetsprofilen gjelder for hvert repository uten at konfigurasjonen glir fra hverandre per repository.

Standarder for organisasjonen kontra overstyringer per repository

Sikkerhet › Policyer › Regler for repositoryer setter reglene som gjelder for hvert repository i organisasjonen. Et nytt repository får én regel for hvert mønster i organisasjonens liste over beskyttede brancher (main, master, release/* som standard), pluss standardbranchen hvis ingen mønstre dekker den, når det opprettes. Dette gjelder også et tomt repository, for eksempel et som er opprettet med POST /api/v1/orgs/{org}/repos: det beskyttes med en gang, og bare standardfilene utelates til det har en første commit. Når du lagrer standardene, brukes de med en gang på organisasjonens eksisterende repositoryer, og en avstemmingsjobb kjører den samme runden hver time som et sikkerhetsnett. På et repository uten beskyttelse oppretter den organisasjonens regler og, hvis organisasjonen har lagret repository-reglene sine, setter repositoryets standard merge-stil og sletting av branch etter merge til organisasjonens verdier. På et repository med egne regler legger den til reglene for alle organisasjonsmønstre som repositoryet mangler, og endrer ellers bare de få innstillingene som står under Hva organisasjonens standard endrer på eksisterende regler. Den overskriver aldri en regel som en repository-administrator har satt. Repositoryer som allerede har beskyttelse, men som har glidd over til noe svakere enn organisasjonens standard, meldes av avviksdetektoren som et varsel i stedet for å tilbakestilles automatisk (se nedenfor).

Organisasjoner som aldri har lagret repository-regler

En organisasjon som aldri har lagret Regler for repositoryer, får fremforges grunnoppsett, ved opprettelse og i timesrunden, som om den hadde lagret det: en pull request er påkrevd, med 1 godkjenning, utdaterte godkjenninger forkastes, fremforges påkrevde sjekker, force-push blokkeres og eiere er inkludert, på main, master, release/* og repositoryets standardbranch. Fram til 28. oktober 2026 fikk repositoryene i en slik organisasjon en main-regel som tillot direkte push ved opprettelse, og ingenting fra timesrunden.

For å endre det åpner du Sikkerhet › Policyer › Regler for repositoryer, setter det du vil ha, og lagrer: de lagrede reglene dine erstatter grunnoppsettet. For at fremforge ikke skal bruke noen beskyttelse i det hele tatt, fjerner du haken for Bruk branchbeskyttelse på nye repositoryer og lagrer. Organisasjonen holdes da utenfor timesrunden, og repositoryene beholder reglene de allerede har.

Tomme repositoryer

En regel som krever en pull request, avviser også pushen som ville ha opprettet branchen, og et tomt repository har ingen branch som en pull request kan rettes mot. Så lenge et repository er tomt, er reglene derfor komplette, men godtar fortsatt en direkte push. Push den første commiten din til standardbranchen som vanlig. Så snart fremforge mottar den pushen, i løpet av sekunder, blir reglene bare for pull requests, som for alle andre repositoryer, så en ny direkte push avvises.

Overstyringer per repository ligger på innstillingssiden til repositoryet (/<org>/<repo>/settings/branches). Overstyr bare når repositoryet har et reelt unntak fra policyen – de fleste team setter organisasjonens standard én gang og rører aldri regler på repository-nivå.

Innstillinger som tilsvarer Forgejo direkte

• Krev en pull request. Direkte push til den beskyttede branchen avvises (Forgejos enable_push: false), så en pull request er eneste vei inn. Det er dette som gjør påkrevde gjennomganger og sjekker bindende: en direkte push hopper over pull requesten de er knyttet til. På i fremforges grunnoppsett. fremforges egen automatisering (avhengighetsoppdateringer, AutoFix, etterfyllingen av .gitattributes) åpner også pull requests, så den fortsetter å fungere på en branch som bare tar imot PR-er.

• Krev gjennomgang av pull requests før merge. Angi et minste antall godkjennere (vanligvis 1 eller 2). Forkast utdaterte gjennomganger ved push, slik at godkjenninger gitt uten å se ikke overlever en force-amend.

• Krev at statussjekker består før merge. Oppgi statuskontekstene som må rapportere suksess. fremforges organisasjonsstandard krever sju, og hvis du bare krever noen av dem, kan de andre ikke blokkere en merge:

  • fremforge/sast – statisk analyse
  • fremforge/dep-scan – sårbarheter i avhengigheter
  • fremforge/license-scan – lisenspolicy
  • fremforge/image-scan – sårbarheter og secrets i repositoryets containerimager og filer
  • fremforge/cosign-verify – signaturverifisering av imager som er låst med digest (informativ: den består alltid; se Image-signaturer)
  • fremforge/secret-scan – oppdagelse av committede secrets
  • fremforge/release-age – holder tilbake en automatisk pull request med avhengighetsoppdatering til hver versjon som låsefilen løser opp til, har vært publisert i minst organisasjonens utgivelsesalder (3 dager med mindre en eier har endret det; 24 timer for en rettelse som et gjennomgått sårbarhetsvarsel navngir, sporet for sikkerhetsrettelser)

  En åttende, fremforge/iac-scan (feilkonfigurasjon i infrastruktur som kode, se IaC-skanning), rapporterer på hver pull request siden 17. oktober 2026 og blir en påkrevd sjekk organisasjon for organisasjon, slik at ingen pull request som ble åpnet før den fantes, venter på den. Til den er påkrevd for organisasjonen din, rapporterer den uten å blokkere på egen hånd; du kan når som helst legge den til i de påkrevde sjekkene dine selv.

  Organisasjonsstandarden krever alle sju; hvis du setter påkrevde sjekker for hånd, lister du opp alle sju, og fremforge/iac-scan hvis du vil at den skal blokkere. fremforge/release-age blokkerer bare automatiske pull requests med avhengighetsoppdateringer, og bare til versjonene deres når utgivelsesalderen; på en pull request som en person har åpnet, rapporterer den ferske versjoner uten å holde PR-en tilbake. En skanner som du setter til off for en organisasjon eller et repository, fjernes fra de påkrevde sjekkene innen en time, siden en skanner som er off, ikke rapporterer noe. Se Kjøre skanninger på nytt for hva hver av dem dekker.

• Krev signerte commits. Når dette er på, avvises usignerte commits på den beskyttede branchen ved push. Se Cosign for commit-signering med kortlivede Sigstore-sertifikater.

• Krev lineær historikk. Når dette er slått på, deaktiverer fremforge merge-commits i repositoryet – merger skjer bare med squash eller rebase, så den beskyttede branchen beholder en lineær historikk.

• Blokker force-push. Avviser --force på den beskyttede branchen fullstendig.

• Blokker sletting av branch. En beskyttet branch kan ikke slettes – dette følger av at det finnes en regel for branchbeskyttelse, og er ikke en egen bryter. Så lenge branchen er beskyttet, avvises slettinger av den.

Innstillinger som fremforge legger til

• Håndhev beskyttelse også for eiere/administratorer av organisasjonen. En bryter per kunde på adminsiden Repos – «Enforce protection on org owners/admins too» (Forgejos apply_to_admins) – som er på som standard. Når den er på, trenger en pull request som en eier av organisasjonen har åpnet, de påkrevde godkjenningene som alle andre; når den er av, fravikes kravet til antall godkjenninger for pull requests som en eier av organisasjonen åpner. Bryteren styrer bare godkjenninger. Påkrevde statussjekker gjelder for alle pull requests, og en eier av organisasjonen kan, som administrator av repositoryet, fortsatt bevisst merge forbi dem med Forgejos force merge («merge anyway» i merge-boksen, eller force_merge i merge-API-et). Det er nødutgangen for en sjekk som har hengt seg opp eller tar feil; den merger en endring som sjekkene ikke har godkjent, så bruk den sparsomt. For å hindre at en fremforge-sjekk blokkerer i det hele tatt setter du heller skanneren til audit eller off for organisasjonen eller repositoryet. For å hindre at avhengighetsfunn som ikke er nåbare, blokkerer fremforge/dep-scan, finnes det en policy du må slå på selv: se Nåbarhet: ikke blokker på funn som ikke er nåbare, og les om risikoen først.
• Krev gjennomgang fra kodeeiere. Setter Forgejos Block merge on official review requests på reglene for den beskyttede branchen. Når en pull request åpnes, gjør en CODEOWNERS-fil (i roten av repositoryet, i docs/, .forgejo/ eller .gitea/) at Forgejo ber eierne av de endrede stiene om en gjennomgang; med denne innstillingen på kan pull requesten ikke merges så lenge noen av disse forespørslene fortsatt er åpne, så kodeeierne må gå gjennom den. To ting å vite: den blokkerer på enhver åpen forespørsel om gjennomgang til en offisiell gjennomgåer, også en du legger til for hånd; og en kodeeier som ikke kan godkjenne på branchen (for eksempel en som ikke er eier, når godkjenninger er begrenset til Owners-teamet), er ikke en offisiell gjennomgåer, så forespørselen til vedkommende blokkerer ikke. Uten en CODEOWNERS-fil blir ingen spurt automatisk, og innstillingen endrer ingenting.
• Tillatelsesliste for statussjekker som fremforge sender. De sju kanoniske navnene står over. De holdes på ett sted internt, delt mellom installasjonen ved opprettelse og etterfyllingen hver time, så settet et nytt repository får, og settet etterfyllingen håndhever, kan ikke gli fra hverandre.
• Avviksdetektor. En separat daglig gjennomgang markerer alle repositoryer der branchbeskyttelsen mangler eller er svakere enn organisasjonens standard – svakere betyr færre påkrevde godkjenninger, eller en påkrevd sjekk som standarden krever og repositoryet ikke har. (Etterfyllingen over kjører hver time og fyller bare inn repositoryer uten beskyttelse; denne daglige gjennomgangen er det som oppdager et repository som har beskyttelse, men som er blitt løsere.) Dette vises som et eget administratorvarsel i bjellen – «N repos with weakened branch protection» – som lenker til adminsiden Repos. Bortsett fra innstillingene som står i neste avsnitt, oppdager og varsler den bare: fremforge tilbakestiller ikke svekkede innstillinger automatisk, fordi de uttrykkelige innstillingene til en repository-eier vinner. Bruk varselet til å avgjøre om du vil følge opp med eieren av repositoryet.

Hva organisasjonens standard endrer på eksisterende regler

På et repository som allerede har sin egen beskyttelse, lar fremforge reglene være i fred bortsett fra disse, som hver endres for seg uten å røre noen annen innstilling i regelen:

• fremforges påkrevde sjekker legges til, og fjernes for en skanner som er satt til off.
• Enforce protection on org owners/admins too følger organisasjonens innstilling, begge veier.
• Krev en pull request, når organisasjonen har det på, gjør også eksisterende regler til bare PR. En regel som navngir hvem som kan pushe (en tillatelsesliste for push med brukere, team eller deploy-nøkler), blir stående som den er: det er et bevisst valg om å la noen pushe, og avviksdetektoren fortsetter å rapportere det.
• Krev gjennomgang fra kodeeiere, når organisasjonen har det på, slås på for eksisterende regler.
• Manglende mønstre. En regel opprettes for et organisasjonsmønster (eller standardbranchen) som repositoryet ikke har noen regel for. Å opprette den endrer aldri en eksisterende regel.

De to siste strammer bare inn. Slår du av en av dem på organisasjonsnivå, slutter den å brukes på nye regler; regler som allerede har den, beholder den til en repository-administrator endrer dem i repositoryets branch-innstillinger.

Bare regler på organisasjonens mønstre for beskyttede brancher (og standardbranchen) røres. Hver endring er listet, per repository, i revisjonshendelsen repo-defaults.branch-protection.retro-applied. Fram til 28. oktober 2026 la fremforge aldri til en regel for et mønster som en repository-administrator lot være ubeskyttet; nå gjør den det, så for å holde en branch ubeskyttet tar du mønsteret ut av organisasjonens liste over beskyttede brancher.

Fjernet: standard repository-mal

Repos-siden hadde tidligere et felt for Default repository template. Det ble fjernet 2026-10-14 fordi det ble lagret, men aldri tatt i bruk: repositoryer opprettes i Forgejo, og Forgejo kan bare generere et nytt repository fra en mal, ikke fylle et som et medlem allerede har opprettet. For å starte repositoryer fra en mal merker du kilderepositoryet som mal i innstillingene og velger det i Forgejos Nytt repository-skjema, eller kaller POST /api/v1/repos/{template_owner}/{template_repo}/generate. API-et avviser nå en verdi for default_template_repo med removed-setting.

Sette det opp

1. Åpne Sikkerhet › Policyer › Regler for repositoryer.
2. Velg branch-globen (vanligvis main eller main, master, release/*).
3. Sett bryterne over. Lagre.
4. Endringen registreres i revisjonsloggen som repo-defaults.branch-protection.updated. En tilbakevirkende bruk på eksisterende repositoryer uten beskyttelse logges som repo-defaults.branch-protection.retro-applied, og tilbakestilling av organisasjonens standarder til fremforges grunnoppsett logges som repo-defaults.reset-baseline.

Se også

• Scorecard – branchbeskyttelse styrer OpenSSF-poengsummen Branch-Protection.
• Autentiseringspolicy – den bredere sikkerhetsprofilen (signerte commits, SSH-transport, MFA).
• Cosign – implementasjonen av krav om signerte commits.