Sikkerhetspolicyer

Sikkerhet › Policyer inneholder reglene organisasjonen din håndhever. Funnsidene viser hva som ble funnet. Policyfanene bestemmer hva et funn blokkerer, og hva en push, en merge, en nedlasting eller en pull har lov til å gjøre. Bare en eier av organisasjonen kan endre en policy, og hver endring skrives til revisjonsloggen.

Fanene

Funnfanene viser funn; hva en skanner gjør, settes her. Fanen Unntak under Findings er der et funn godtas for en periode, med eller uten godkjenning fra en annen person.

Skannere

Sikkerhet › Policyer › Skannere inneholder innstillingene for hver skanner. Fram til 2026-10-15 lå de øverst i funnfanen for skanneren, som nå viser funnene først og én linje med skannerens tilstand og en lenke hit.

• SAST: av eller på, og alvorlighetsgraden (info, warning, error) der sjekken fremforge/sast feiler.
• Avhengigheter: av eller på, og alvorlighetsgraden (low til critical) der sjekken fremforge/dep-scan feiler.
• Lisenser: om pull requests skannes for lisenser. Hva et lisensfunn betyr, bestemmes av lisenspolicyen.
• Skanning etter secrets: om pull requests som legger til en secret, blokkeres.
• Containerimager: imageskanningen og pull-sperren ligger under Image policies.

En lagring som avvises, for eksempel en alvorlighetsgrad som ikke er et av valgene, kommer tilbake til skannerens seksjon og forteller hvorfor. API-et og Terraform-ressursene er uendret: PUT /orgs/{org}/code-security/{scanner}/settings og ressursene fremforge_*_settings.

Utgivelsesalder

Sikkerhet › Policyer › Utgivelsesalder er ett antall dager, 0 til 14, for hvor lenge en ny versjon må ha vært publisert før organisasjonen din tar den i bruk. Fram til 2026-10-16 var dette fire innstillinger på fire steder. Nå setter den alle fire:

Ingenting endret seg av seg selv. Hvert sted beholdt sin egen verdi. Der de er ulike, viser siden hver verdi i dag og hva en lagring ville satt, og foreslår verdien for sikkerhetsrettelser. Ingenting skrives før en eier lagrer, og Save tilbys bare for det tallet siden har vist endringene for.

En rettelse for en kjent utnyttet sårbarhet venter fortsatt ikke i sjekken på pull requests, i sikkerhetsrettelser eller ved nedlasting gjennom avhengighetsproxyen. Pakker i ditt eget register venter fortsatt.

Sporet for sikkerhetsrettelser i sjekken på pull requests

I sjekken fremforge/release-age venter en versjon som retter en sårbarhet basebranchen din har, uansett alvorlighetsgrad, 24 timer i stedet for utgivelsesalderen din. En versjon kvalifiserer bare når alt dette gjelder:

• Basebranchen din løser opp en tidligere versjon av pakken, og pull requesten fjerner den.
• Et sårbarhetsvarsel berører den tidligere versjonen og navngir en rettet versjon som er lik eller lavere enn den nye. En utgivelse som bare påstår at den retter noe, kvalifiserer ikke.
• Sårbarhetsvarselet er gjennomgått, uansett alvorlighetsgrad: et GitHub-varsel som GitHub har gjennomgått, eller en post fra økosystemets egen database (RustSec, Go-sårbarhetsdatabasen, PyPA). Det ble publisert, og gjennomgått, minst 24 timer før sjekken. En pakke og et sårbarhetsvarsel som publiseres samme dag, kvalifiserer derfor aldri.
• Ingen post om ondsinnede pakker matcher den nye versjonen. Matching av skadevare lempes aldri på for sporet.

En ny transitiv avhengighet som bare rettelsen trakk inn, får de samme 24 timene i ett av to tilfeller:

• Et sårbarhetsvarsel navngir den også som en rettelse, etter de samme reglene som over.
• Rettelsens egne folk publiserer den. npm-brukeren som publiserte den versjonen, må være kjent og må være vedlikeholder av rettelsen. I tillegg må ett av disse også stemme:
  • Alle vedlikeholdere av avhengigheten vedlikeholder også rettelsen.
  • Avhengigheten og rettelsen deklarerer det samme kilderepositoryet, slik pakkene i et monorepo gjør.

Et deklarert repository er aldri nok alene. Feltet repository i en package.json er det publiseringen skriver der, så hvem som helst kan påberope seg en annens repository. En avhengighet med ukjent utgiver venter alltid.

Ellers venter den hele utgivelsesalderen din, og pull requesten venter sammen med den. Alle andre nye versjoner i pull requesten beholder utgivelsesalderen din. Sporet gjør aldri sjekken strengere. Med en utgivelsesalder på 1 dag eller 0 endres ingenting.

Statusen for sjekken navngir hver versjon som gikk gjennom sporet og sårbarhetsvarselet den retter, for eksempel 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Hver slik versjon skriver code-security.release_age.waived_security_fix_lane til revisjonsloggen, med pakken, versjonen, sårbarhetsvarslene, rettelsen som trakk den inn og pull requesten. Nedlastinger gjennom avhengighetsproxyen og hostet Renovate beholder sine egne regler. Pakketyper med egen minstealder i pakkepolicyen beholder den, og siden lister dem. Når pakkepolicyen ikke er i modusen Enforce, blir en nedlasting som er for ny, bare registrert.

Én ting er ikke dekket: for npm, pnpm og Yarn 1 løser hostet Renovate opp låsefilen gjennom fremforges utgivelsesaldersvisning av npm-registeret, som holder 3 dager for alle organisasjoner. Med en lengre utgivelsesalder holder sjekken fremforge/release-age fortsatt igjen pull requesten til alle versjonene i låsefilen er gamle nok.

Via API-et: GET/PUT /orgs/{org}/release-age (policy:read, policy:write) med {"days": 7, "package_policy_version": 12}, og POST /orgs/{org}/release-age/preview med {"days": 7} for å se hva en PUT ville endret, per sted. PUT sjekkes mot pakkepolicyens versjon, som en lagring av pakkepolicyen, og svarer 409 policy-version-conflict når den har endret seg. Hver endring skriver security.release_age.updated til revisjonsloggen, ved siden av hendelsene for innstillingene den endret.

Imagepolicyer

Sikkerhet › Policyer › Imagepolicyer har to deler. Begge lå tidligere nederst under Funn › Containerimager.

• Skanning og pull-sperre. Slår imageskanning av eller på og angir blokkeringshandlingen: none, warn eller block_pull. Med block_pull avvises en pull av et image med et funn som ikke er avvist, på eller over blokkeringsterskelen din, og sjekken fremforge/image-scan feiler. Se Policybrytere.
• Imagesignaturer ved pull. Hvis cosign-signaturer du stoler på (én liste med klarerte signerere, nøkler eller den offentlige Sigstore), hvilke imager den gjelder for, og om en usignert pull bare registreres (shadow) eller avvises (enforce). Se Imagesignaturer.

Regler for repositoryer

Sikkerhet › Policyer › Regler for repositoryer er én side for reglene alle repositoryer i organisasjonen må følge.

• Branchbeskyttelse (#org-baseline). Regelen hvert nytt repository får for de beskyttede branchene sine: påkrevde godkjenninger, gjennomgang fra CODEOWNERS, statussjekker, lineær historikk og resten. Når du lagrer, brukes standardverdiene på eksisterende repositoryer med en gang. Se Branchbeskyttelse.
• Commit-signering (#commit-signing). Én innstilling: når den er på, krever standardbranchen i alle repositoryer signerte commits, og nye repositoryer får samme krav gjennom standardverdiene over. Hvis en eldre innstilling har fått de to ut av takt, sier siden fra; lagrer du commit-signering, bringes de i takt igjen. Se Require signed commits.
• Låsing for hele organisasjonen (#actions-gate): Actions bare på beskyttede brancher. Når den er på, kjører en workflow bare på en beskyttet branch, så en push til en annen branch ikke kan kjøre kode med organisasjonens secrets. Se Actions bare på beskyttede brancher.

De gamle adressene virker fortsatt: _admin/repo-defaults og innstillingene for commit-signering og Actions under Organisasjon › Repositoryer og Bygg og utrulling › Miljøer lenker eller videresender nå hit.

API og Terraform

Den fullstendige listen, med scopes og felter, finner du i API-referansen og på siden om Terraform-provideren.