Beveiligingsbeleid

Beveiliging › Beleid bevat de regels die je organisatie afdwingt. De bevindingenpagina’s tonen wat er is gevonden. De beleidstabbladen bepalen wat een bevinding blokkeert, en wat een push, een merge, een download of een pull mag doen. Alleen een eigenaar van de organisatie kan een beleid wijzigen, en elke wijziging wordt naar het auditlog geschreven.

De tabbladen

De bevindingentabbladen tonen bevindingen; wat een scanner doet, stel je hier in. Het tabblad Uitzonderingen onder Bevindingen is waar een bevinding tijdelijk wordt geaccepteerd, met of zonder goedkeuring van een tweede persoon.

Scanners

Beveiliging › Beleid › Scanners bevat de instellingen van elke scanner. Tot 2026-10-15 stonden ze boven aan het bevindingentabblad van de scanner, dat nu eerst de bevindingen toont en één regel met de status van de scanner en een link hierheen.

• SAST: aan of uit, en de ernst (info, warning, error) waarbij de controle fremforge/sast faalt.
• Afhankelijkheden: aan of uit, en de ernst (low tot critical) waarbij de controle fremforge/dep-scan faalt.
• Licenties: of pull requests op licenties worden gescand. Wat een licentiebevinding betekent, bepaalt het licentiebeleid.
• Secret-scanning: of pull requests die een secret toevoegen, worden geblokkeerd.
• Containerimages: de imagescan en de pull-blokkade staan onder Imagebeleid.

Een opslagactie die wordt geweigerd, bijvoorbeeld een ernst die niet een van de keuzes is, keert terug naar het gedeelte van de scanner en vermeldt waarom. De API en de Terraform-resources zijn ongewijzigd: PUT /orgs/{org}/code-security/{scanner}/settings en de fremforge_*_settings-resources.

Release-leeftijd

Beveiliging › Beleid › Release-leeftijd is één aantal dagen, van 0 tot 14, voor hoe lang een nieuwe versie gepubliceerd moet zijn voordat je organisatie haar overneemt. Tot 2026-10-16 waren dat vier instellingen op vier plekken. Nu stelt dit ene getal alle vier in:

Er veranderde niets vanzelf. Elke plek hield haar eigen waarde. Waar ze verschillen, toont de pagina elke huidige waarde en wat een opslag zou instellen, en stelt ze de waarde van de beveiligingsfixes voor. Er wordt niets geschreven totdat een eigenaar opslaat, en Opslaan wordt alleen aangeboden voor het getal waarvan de pagina de gevolgen heeft getoond.

Een fix voor een kwetsbaarheid waarvan bekend is dat ze wordt misbruikt, wacht nog steeds niet in de controle op pull requests, bij beveiligingsfixes, of bij een download via de dependency proxy. Pakketten in je eigen register wachten wel.

Het spoor voor beveiligingsfixes in de controle op pull requests

In de controle fremforge/release-age wacht een versie die een kwetsbaarheid oplost die je basisbranch heeft, van welke ernst ook, 24 uur in plaats van je release-leeftijd. Een versie komt alleen in aanmerking als dit allemaal geldt:

• Je basisbranch gebruikt een eerdere versie van het pakket, en de pull request verwijdert die.
• Een advisory treft die eerdere versie en noemt een gefixte versie op of onder de nieuwe. Een release die alleen beweert iets op te lossen, komt niet in aanmerking.
• De advisory is gereviewd, ongeacht de ernst: een GitHub-advisory die GitHub heeft gereviewd, of een record uit de eigen database van het ecosysteem (RustSec, de Go-kwetsbaarhedendatabase, PyPA). Ze is minstens 24 uur vóór de controle gepubliceerd en gereviewd. Een pakket en een advisory die op dezelfde dag samen zijn gepubliceerd, komen dus nooit in aanmerking.
• Er past geen record van een kwaadaardig pakket op de nieuwe versie. Het vergelijken met malware wordt voor het spoor nooit versoepeld.

Een nieuwe transitieve afhankelijkheid die alleen door de fix is binnengekomen, krijgt in een van deze twee gevallen dezelfde 24 uur:

• Een advisory noemt haar ook als fix, volgens dezelfde regels als hierboven.
• De eigen mensen van de fix publiceren haar. De npm-gebruiker die die versie heeft gepubliceerd, moet bekend zijn en een maintainer van de fix zijn. Daarnaast moet ook een van deze voorwaarden gelden:
  • Elke maintainer van de afhankelijkheid onderhoudt ook de fix.
  • De afhankelijkheid en de fix declareren dezelfde bronrepository, zoals de pakketten van een monorepo doen.

Een gedeclareerde repository is op zich nooit genoeg. Het veld repository in een package.json bevat wat de publisher er ook maar in zet, dus iedereen kan de repository van een ander claimen. Een afhankelijkheid waarvan de publisher onbekend is, wacht altijd.

Anders wacht ze je volledige release-leeftijd, en wacht de pull request mee. Elke andere nieuwe versie in de pull request houdt je release-leeftijd. Het spoor maakt de controle nooit strenger. Met een release-leeftijd van 1 dag of 0 verandert er niets.

De status van de controle noemt elke versie die via het spoor is gegaan en de advisory die ze oplost, bijvoorbeeld 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Elke zo’n versie schrijft code-security.release_age.waived_security_fix_lane naar het auditlog, met het pakket, de versie, de advisories, de fix die haar heeft binnengebracht en de pull request. Downloads via de dependency proxy en gehoste Renovate houden hun eigen regels. Pakkettypen met een eigen minimumleeftijd in het pakketbeleid houden die, en de pagina somt ze op. Als het pakketbeleid niet in de modus Afdwingen staat, wordt een download die te nieuw is alleen vastgelegd.

Eén ding is niet gedekt: voor npm, pnpm en Yarn 1 lost gehoste Renovate de lockfile op via de release-leeftijdweergave van fremforge op het npm-register, die voor elke organisatie 3 dagen aanhoudt. Met een langere release-leeftijd houdt de controle fremforge/release-age de pull request nog steeds tegen totdat elke versie in de lockfile oud genoeg is.

Via de API: GET/PUT /orgs/{org}/release-age (policy:read, policy:write) met {"days": 7, "package_policy_version": 12}, en POST /orgs/{org}/release-age/preview met {"days": 7} voor wat een PUT per plek zou wijzigen. De PUT wordt gecontroleerd tegen de versie van het pakketbeleid, net als het opslaan van een pakketbeleid, en antwoordt met 409 policy-version-conflict als die intussen is veranderd. Elke wijziging schrijft security.release_age.updated naar het auditlog, naast de gebeurtenissen van de instellingen die ze heeft gewijzigd.

Imagebeleid

Beveiliging › Beleid › Imagebeleid bestaat uit twee delen. Beide stonden vroeger onder aan Bevindingen › Containerimages.

• Scannen en pull-blokkade. Zet het scannen van images aan of uit en stelt de blokkeeractie in: none, warn of block_pull. Met block_pull wordt een pull van een image met een niet-genegeerde bevinding op of boven je blokkeerdrempel geweigerd, en faalt de controle fremforge/image-scan. Zie Beleidsinstellingen.
• Image-handtekeningen bij pull. Wiens cosign-handtekeningen je vertrouwt (één lijst van vertrouwde ondertekenaars, sleutels, of de openbare Sigstore), op welke images dat van toepassing is, en of een pull zonder handtekening alleen wordt vastgelegd (Schaduw) of geweigerd (Afdwingen). Zie Image-handtekeningen.

Repositoryregels

Beveiliging › Beleid › Repositoryregels is één pagina voor de regels waaraan elke repository van de organisatie zich moet houden.

• Branchbescherming (#org-baseline). De regel die elke nieuwe repository voor haar beschermde branches krijgt: vereiste goedkeuringen, review door CODEOWNERS, statuscontroles, lineaire geschiedenis en de rest. Opslaan past de standaarden meteen toe op bestaande repository’s. Zie Branchbescherming.
• Commit-ondertekening (#commit-signing). Eén instelling: als ze aanstaat, vereist de standaardbranch van elke repository ondertekende commits, en krijgen nieuwe repository’s dezelfde eis via de standaarden hierboven. Als een oudere instelling de twee uit de pas heeft gebracht, meldt de pagina dat; het opslaan van de commit-ondertekening brengt ze weer in lijn. Zie Ondertekende commits vereisen.
• Organisatiebrede vergrendeling (#actions-gate): Actions alleen op beschermde branches. Als die aanstaat, draait een workflow alleen op een beschermde branch, zodat een push naar een andere branch geen code met de secrets van de organisatie kan uitvoeren. Zie Actions alleen op beveiligde branches.

De oude adressen werken nog: _admin/repo-defaults en de instellingen voor commit-ondertekening en Actions onder Organisatie › Repositories en Bouwen en uitrollen › Omgevingen linken of verwijzen nu hierheen.

API en Terraform

De volledige lijst, met scopes en velden, staat in de API-referentie en op de pagina Terraform-provider.