Säkerhetspolicyer

Säkerhet › Policyer innehåller de regler som din organisation upprätthåller. Fyndsidorna visar vad som hittades. Policyflikarna avgör vad ett fynd blockerar, och vad en push, en merge, en nedladdning eller en pull får göra. Bara en organisationsägare kan ändra en policy, och varje ändring skrivs till granskningsloggen.

Flikarna

Fyndflikarna visar fynd; vad en skanner gör ställs in här. Fliken Undantag under Fynd är där ett fynd accepteras under en tid, med eller utan godkännande från en andra person.

Skannrar

Säkerhet › Policyer › Skannrar innehåller varje skanners inställningar. Fram till 2026-10-15 låg de högst upp på skannerns fyndflik, som nu visar sina fynd först och en rad med skannerns status och en länk hit.

• SAST: på eller av, och den allvarlighetsgrad (info, warning, error) vid vilken kontrollen fremforge/sast underkänns.
• Beroenden: på eller av, och den allvarlighetsgrad (low till critical) vid vilken kontrollen fremforge/dep-scan underkänns.
• Licenser: om pull requests licensskannas. Vad ett licensfynd betyder avgörs av licenspolicyn.
• Hemlighetsskanning: om pull requests som lägger till en hemlighet blockeras.
• Container-images: skanningen av images och pull-spärren finns under Image-policyer.

En sparning som avvisas, till exempel en allvarlighetsgrad som inte är ett av alternativen, kommer tillbaka till skannerns avsnitt och säger varför. API:t och Terraform-resurserna är oförändrade: PUT /orgs/{org}/code-security/{scanner}/settings och resurserna fremforge_*_settings.

Versionsålder

Säkerhet › Policyer › Versionsålder är ett antal dagar, 0 till 14, för hur länge en ny version måste ha varit publicerad innan din organisation tar in den. Fram till 2026-10-16 var det fyra inställningar på fyra ställen. Nu ställer den in alla fyra:

Inget ändrades av sig självt. Varje ställe behöll sitt eget värde. Där de skiljer sig visar sidan varje värde i dag och vad en sparning skulle ställa in, och föreslår värdet för säkerhetsfixar. Inget skrivs förrän en ägare sparar, och Spara erbjuds bara för det tal vars ändringar sidan har visat.

En fix för en känd utnyttjad sårbarhet väntar fortfarande inte i kontrollen i pull requests, i säkerhetsfixar eller för en nedladdning via beroendeproxyn. Paket i ditt eget register väntar fortfarande.

Spåret för säkerhetsfixar i kontrollen i pull requests

I kontrollen fremforge/release-age väntar en version som åtgärdar en sårbarhet som din basbranch har, oavsett allvarlighetsgrad, 24 timmar i stället för din versionsålder. En version kvalificerar sig bara när allt det här gäller:

• Din basbranch löser upp en tidigare version av paketet, och pull requesten tar bort den.
• Ett säkerhetsmeddelande berör den tidigare versionen och namnger en åtgärdad version som är lika med eller lägre än den nya. En release som bara påstår sig åtgärda något kvalificerar sig inte.
• Säkerhetsmeddelandet är granskat, oavsett allvarlighetsgrad: ett GitHub-säkerhetsmeddelande som GitHub har granskat, eller en post från ekosystemets egen databas (RustSec, Gos sårbarhetsdatabas, PyPA). Det publicerades, och granskades, minst 24 timmar före kontrollen. Ett paket och ett säkerhetsmeddelande som publiceras samtidigt samma dag kvalificerar sig därför aldrig.
• Ingen post om skadligt paket matchar den nya versionen. Matchningen mot skadlig kod lättas aldrig upp för spåret.

Ett nytt transitivt beroende som bara fixen drog in får samma 24 timmar i något av två fall:

• Ett säkerhetsmeddelande namnger det också som en fix, enligt samma regler som ovan.
• Fixens egna personer publicerar det. Den npm-användare som publicerade den versionen måste vara känd och måste vara underhållare av fixen. Utöver det måste också något av följande gälla:
  • Varje underhållare av beroendet underhåller också fixen.
  • Beroendet och fixen deklarerar samma källrepository, som paketen i ett monorepo gör.

Ett deklarerat repo räcker aldrig på egen hand. Fältet repository i en package.json är vad utgivaren än skriver där, så vem som helst kan göra anspråk på någon annans repo. Ett beroende vars utgivare är okänd väntar alltid.

Annars väntar det hela din versionsålder, och pull requesten väntar med det. Varje annan ny version i pull requesten behåller din versionsålder. Spåret gör aldrig kontrollen strängare. Med en versionsålder på 1 dag eller 0 ändras ingenting.

Kontrollens status namnger varje version som passerade genom spåret och det säkerhetsmeddelande den åtgärdar, till exempel 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Varje sådan version skriver code-security.release_age.waived_security_fix_lane till granskningsloggen, med paket, version, säkerhetsmeddelanden, den fix som drog in den och pull requesten. Nedladdningar via beroendeproxyn och hostad Renovate behåller sina egna regler. Pakettyper med en egen minimiålder i paketpolicyn behåller den, och sidan listar dem. När paketpolicyn inte är i läget Tvinga registreras en nedladdning som är för ny bara.

En sak täcks inte: för npm, pnpm och Yarn 1 löser hostad Renovate upp låsfilen via fremforges versionsåldersvy av npm-registret, som håller 3 dagar för varje organisation. Med en längre versionsålder håller kontrollen fremforge/release-age ändå kvar pull requesten tills varje version i låsfilen är gammal nog.

Via API:t: GET/PUT /orgs/{org}/release-age (policy:read, policy:write) med {"days": 7, "package_policy_version": 12}, och POST /orgs/{org}/release-age/preview med {"days": 7} för vad en PUT skulle ändra, per ställe. PUT kontrolleras mot paketpolicyns version, som när en paketpolicy sparas, och svarar 409 policy-version-conflict när den har ändrats. Varje ändring skriver security.release_age.updated till granskningsloggen, bredvid händelserna för de inställningar den ändrade.

Image-policyer

Säkerhet › Policyer › Image-policyer har två delar. Båda låg tidigare längst ned på Fynd › Container-images.

• Skanning och pull-spärr. Slår på eller av skanningen av images och anger blockeringsåtgärden: none, warn eller block_pull. Med block_pull avvisas en pull av en image med ett fynd som inte är avfärdat och som ligger på eller över din blockeringströskel, och kontrollen fremforge/image-scan underkänns. Se Policyreglage.
• Image-signaturer vid pull. Vems cosign-signaturer du litar på (en lista över betrodda signerare, nycklar eller den publika Sigstore), vilka images det gäller och om en osignerad pull bara registreras (shadow) eller avvisas (enforce). Se Image-signaturer.

Repo-regler

Säkerhet › Policyer › Repo-regler är en sida för de regler som varje repo i organisationen måste följa.

• Branch-skydd (#org-baseline). Den regel som varje nytt repo får för sina skyddade brancher: krävda godkännanden, granskning enligt CODEOWNERS, statuskontroller, linjär historik och resten. När du sparar tillämpas standardvärdena direkt på befintliga repon. Se Branch-skydd.
• Commit-signering (#commit-signing). En inställning: när den är på kräver standardbranchen i varje repo signerade commits, och nya repon får samma krav genom standardvärdena ovan. Om en äldre inställning gjorde att de två inte stämmer överens säger sidan det; när du sparar commit-signeringen förs de samman igen. Se Kräv signerade commits.
• Organisationsövergripande låsning (#actions-gate): Actions bara på skyddade brancher. När den är på körs ett arbetsflöde bara på en skyddad branch, så en push till någon annan branch kan inte köra kod med organisationens hemligheter. Se Actions bara på skyddade brancher.

De gamla adresserna fungerar fortfarande: _admin/repo-defaults och inställningarna för commit-signering och Actions under Org › Repon och Bygg och driftsätt › Miljöer länkar eller omdirigerar nu hit.

API och Terraform

Den fullständiga listan, med scopes och fält, finns i API-referensen och på sidan om Terraform-providern.