Sikkerhedspolitikker

Sikkerhed › Politikker rummer de regler, din organisation håndhæver. Siderne med fund viser, hvad der er fundet. Politikfanerne afgør, hvad et fund blokerer, og hvad et push, en merge, en download eller en pull må. Kun en ejer af organisationen kan ændre en politik, og hver ændring skrives til revisionsloggen.

Fanerne

Fanerne med fund viser fund; hvad en scanner gør, sættes her. Fanen Undtagelser under Fund er stedet, hvor et fund accepteres for en tid, med eller uden en anden persons godkendelse.

Scannere

Sikkerhed › Politikker › Scannere rummer hver scanners indstillinger. Indtil 2026-10-15 lå de øverst på scannerens fane med fund, som nu viser fundene først og én linje med scannerens tilstand og et link hertil.

• SAST: til eller fra, og den alvorlighed (info, warning, error), ved hvilken tjekket fremforge/sast fejler.
• Afhængigheder: til eller fra, og den alvorlighed (low til critical), ved hvilken tjekket fremforge/dep-scan fejler.
• Licenser: om pull requests licensscannes. Hvad et licensfund betyder, afgøres af licenspolitikken.
• Hemmelighedsscanning: om pull requests, der tilføjer en secret, blokeres.
• Container-images: scanningen af images og pull-spærringen ligger under Image-politikker.

En gemning, der afvises, for eksempel en alvorlighed, der ikke er et af valgene, vender tilbage til scannerens afsnit og siger hvorfor. API’et og Terraform-ressourcerne er uændrede: PUT /orgs/{org}/code-security/{scanner}/settings og fremforge_*_settings-ressourcerne.

Udgivelsesalder

Sikkerhed › Politikker › Udgivelsesalder er ét antal dage, 0 til 14, for hvor længe en ny version skal have været udgivet, før din organisation tager den i brug. Indtil 2026-10-16 var det fire indstillinger fire steder. Nu sætter den alle fire:

Intet ændrede sig af sig selv. Hvert sted beholdt sin egen værdi. Hvor de er forskellige, viser siden hver værdi i dag, og hvad en gemning ville sætte, og foreslår værdien fra sikkerhedsrettelser. Intet skrives, før en ejer gemmer, og Gem tilbydes kun for det tal, hvis ændringer siden har vist.

En rettelse af en kendt udnyttet sårbarhed venter stadig ikke i tjekket på pull requests, i sikkerhedsrettelser eller ved en download gennem afhængighedsproxyen. Pakker i dit eget registry venter stadig.

Sikkerhedsrettelsessporet i tjekket på pull requests

I tjekket fremforge/release-age venter en version, der retter en sårbarhed, som din base-branch har, uanset alvorlighed, 24 timer i stedet for din udgivelsesalder. En version kvalificerer sig kun, når alt dette gælder:

• Din base-branch opløser en tidligere version af pakken, og pull requesten fjerner den.
• En advisory berører den tidligere version og navngiver en rettet version, der er lig med eller lavere end den nye. En udgivelse, der blot hævder at rette noget, kvalificerer sig ikke.
• Advisory’en er gennemgået, uanset alvorlighed: en GitHub-advisory, som GitHub har gennemgået, eller en post fra økosystemets egen database (RustSec, Go-sårbarhedsdatabasen, PyPA). Den blev udgivet og gennemgået mindst 24 timer før tjekket. En pakke og en advisory, der udgives samme dag, kvalificerer sig derfor aldrig.
• Ingen post om ondsindede pakker matcher den nye version. Matchning af malware lempes aldrig for sporet.

En ny transitiv afhængighed, som kun rettelsen har bragt ind, får de samme 24 timer i et af to tilfælde:

• En advisory navngiver også den som rettelse, efter samme regler som ovenfor.
• Rettelsens egne folk udgiver den. Den npm-bruger, der udgav versionen, skal være kendt og skal være vedligeholder af rettelsen. Derudover skal et af disse også være sandt:
  • Alle afhængighedens vedligeholdere vedligeholder også rettelsen.
  • Afhængigheden og rettelsen erklærer det samme kilderepository, som et monorepos pakker gør.

Et erklæret repository er aldrig nok i sig selv. Feltet repository i en package.json er det, udgiveren skriver der, så alle kan gøre krav på en andens repository. En afhængighed, hvis udgiver er ukendt, venter altid.

Ellers venter den din fulde udgivelsesalder, og pull requesten venter med. Alle andre nye versioner i pull requesten beholder din udgivelsesalder. Sporet gør aldrig tjekket strengere. Med en udgivelsesalder på 1 dag eller 0 ændres intet.

Tjekkets status navngiver hver version, der gik gennem sporet, og den advisory, den retter, for eksempel 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Hver sådan version skriver code-security.release_age.waived_security_fix_lane til revisionsloggen med pakken, versionen, advisories, den rettelse, der bragte den ind, og pull requesten. Downloads gennem afhængighedsproxyen og hostet Renovate beholder deres egne regler. Pakketyper med deres egen minimumsalder i pakkepolitikken beholder den, og siden viser dem. Når pakkepolitikken ikke er i tilstanden Håndhæv, registreres en download, der er for ny, kun.

Én ting er ikke dækket: for npm, pnpm og Yarn 1 opløser hostet Renovate lockfilen gennem fremforges udgivelsesaldersvisning af npm-registryet, som holder 3 dage for alle organisationer. Med en længere udgivelsesalder holder tjekket fremforge/release-age stadig pull requesten tilbage, indtil alle versioner i lockfilen 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, hvad en PUT ville ændre, pr. sted. PUT tjekkes mod pakkepolitikkens version, ligesom en gemning af pakkepolitikken, og svarer 409 policy-version-conflict, når den har flyttet sig. Hver ændring skriver security.release_age.updated til revisionsloggen ved siden af hændelserne for de indstillinger, den ændrede.

Image-politikker

Sikkerhed › Politikker › Image-politikker har to dele. Begge lå tidligere nederst på Fund › Container-images.

• Scanning og pull-spærring. Slår scanning af images til eller fra og sætter blokeringshandlingen: none, warn eller block_pull. Med block_pull afvises en pull af et image med et ikke-afvist fund på eller over din blokeringstærskel, og tjekket fremforge/image-scan fejler. Se Politikindstillinger.
• Image-signaturer ved hentning. Hvis cosign-signaturer du stoler på (én liste over betroede signerere, nøgler eller den offentlige Sigstore), hvilke images det gælder for, og om en pull uden signatur kun registreres (Skygge) eller afvises (Håndhæv). Se Image-signaturer.

Repository-regler

Sikkerhed › Politikker › Repository-regler er én side for de regler, som alle organisationens repositorier er underlagt.

• Branch-beskyttelse (#org-baseline). Den regel, hvert nyt repository får for sine beskyttede branches: påkrævede godkendelser, CODEOWNERS-review, statustjek, lineær historik og resten. En gemning anvender standarderne på eksisterende repositorier med det samme. Se Branch-beskyttelse.
• Commit-signering (#commit-signing). Én indstilling: når den er slået til, kræver standard-branchen i alle repositorier signerede commits, og nye repositorier får samme krav gennem standarderne ovenfor. Hvis en ældre indstilling har bragt de to ud af trit, siger siden det; en gemning af commit-signering bringer dem i trit igen. Se Kræv signerede commits.
• Organisationsdækkende lukning (#actions-gate): Actions kun på beskyttede branches. Når den er slået til, kører et workflow kun på en beskyttet branch, så et push til en anden branch ikke kan køre kode med organisationens secrets. Se Actions kun på beskyttede branches.

De gamle adresser virker stadig: _admin/repo-defaults samt indstillingerne for commit-signering og Actions under Organisation › Repositorier og Byg og udrul › Miljøer linker eller omdirigerer nu hertil.

API og Terraform

Den fulde liste med scopes og felter findes i API-referencen og på siden om Terraform-provideren.