GitHubs nya ruleset-regel stoppar en pull request i två skilda lägen: medan secret scanning ännu inte är klar för PR:ens senaste commit och när PR:ens commits har introducerat en öppen varning av en mönstertyp som rulesetet valt. Ett grönt slutläge bevisar därför inte ensamt att båda spärrarna fungerar. Prova dem var för sig med ett syntetiskt värde och dokumentera även vem som kan kringgå regeln.
Regeln kompletterar push protection
GitHub lanserade Require secret scanning alerts are resolved i public preview den 9 september 2026. Regeln placeras i ett branch ruleset och kan riktas mot valda grenar i ett repository eller mot valda repositoryn från en organisation. De skyddade repositoryna behöver ha GitHub Secret Protection eller GitHub Advanced Security och secret scanning aktiverat.
Det här är inte samma kontrollpunkt som push protection. Push protection försöker stoppa en hemlighet när den pushas, innan den når repositoryt. Den nya regeln arbetar vid merge av en pull request och kan fånga ett fall som push protection inte kan eller inte har konfigurerats för. Behåll därför pushskyddet där det används; PR-regeln är ett extra lager, inte en ersättare.
Börja med en exakt mönstermatris
GitHub stöder tre kategorier i regeln: provider patterns, custom patterns och generic patterns. Provider patterns är standardvalet. Custom och generic måste väljas om de också ska blockera. AI-detected secrets stöds inte av regeln. Om teamet bara slår på kryssrutan och antecknar ”secret scanning blockerar merge” blir kontrollen alltså starkare formulerad än den faktiska konfigurationen.
Gör i stället en liten matris före provet. Skriv upp rulesetets namn, enforcement-status, målrepository, målgren och exakt vilka av de tre stödda kategorierna som är valda. Lägg till en rad för AI-detected med resultatet ”stöds inte”. Den raden hindrar senare läsare från att tolka ett lyckat provider-test som bevis för en kategori som regeln inte omfattar.
Skapa ett custom pattern med ett syntetiskt prefix som bara finns i testdata, exempelvis MB_TEST_SECRET_[A-Z0-9]{12}, och generera ett värde som inte kan autentisera mot någon tjänst. Mönstret ska vara tillräckligt specifikt för att inte träffa normal kod. Provet mäter GitHubs kontrollflöde, inte om en riktig leverantörsnyckel råkar gå att återkalla.
Steg 1: avgränsa rulesetet
- Välj ett testrepository eller en testgren som inte tar emot produktionsändringar.
- Kontrollera att secret scanning är aktiverat och att produktkravet är uppfyllt.
- Skapa eller redigera ett branch ruleset och välj Require secret scanning alerts are resolved.
- Välj custom patterns och det syntetiska testmönstret. Låt provider och generic stå enligt den planerade produktionspolicyn.
- Aktivera rulesetet först när målgrenen och bypass-listan är granskade. Ett ruleset med status Active börjar gälla direkt.
Spara konfigurationen som text eller skärmbild tillsammans med tidpunkt. Ett senare PR-resultat går annars inte att koppla till den kategori och bypass-lista som faktiskt gällde när provet kördes.
Steg 2: fånga scan-pending som ett eget resultat
Skapa en gren med en ofarlig filändring som inte matchar något valt secret pattern och öppna en pull request mot målgrenen. Direkt efter senaste pushen kontrollerar du mergeytan. Regeln ska kunna blockera medan secret scanning inte har slutförts för head-commit. Spara PR-länk, head-SHA, tidpunkt och den visade orsaken. När scanningen blir klar ska just pending-spärren försvinna.
Om du bara ser slutläget har du inte bevisat detta villkor. Gör en ny liten commit och observera övergången igen. Undvik att mäta sekunder eller sätta en tids-SLA från ett enskilt prov; källan lovar villkoret, inte en bestämd scanningstid.
Steg 3: skapa och ta bort en syntetisk träff
Lägg nu till ett värde som matchar testets custom pattern, till exempel i en fil under fixtures/, och pusha committen till samma PR. När scanningen är klar ska en öppen matchande alert blockera merge. Kontrollera att alerten pekar på testfilen och att mönsterkategorin är custom. Om den träffar ett annat mönster har du inte provat den avsedda regeln.
Gör därefter en ny commit som tar bort hela testvärdet. Det räcker inte för att öppna mergevägen. GitHubs dokumentation säger att secret scanning inte stänger alerten automatiskt när värdet tas bort. Öppna alerten, verifiera att den gäller det syntetiska värdet, välj en korrekt stängningsorsak och skriv en kommentar som hänvisar till testets PR och fix-commit. Först när alla blockerande alerts är stängda och scanningen för den nya head-committen är klar ska regeln sluta hindra merge.
| Läge | Förväntat resultat | Bevis att spara |
|---|---|---|
| Ny head-commit | Merge blockeras tills scanningen är klar. | PR, head-SHA, tidpunkt och pending-orsak. |
| Syntetisk match | Öppen custom-pattern-alert blockerar merge. | Alert-ID, fil, kategori och blockerad mergeyta. |
| Värdet borttaget | Alerten är fortfarande öppen och blockerar. | Fix-commit och oförändrad alertstatus. |
| Alert stängd, scan klar | Alerten blockerar inte längre merge. | Orsak, kommentar, ny head-SHA och grön mergeyta. |
Steg 4: prova bypass utan att normalisera den
Rulesets kan ge bypass till utvalda roller, team och appar. GitHub erbjuder också läget For pull requests only: aktören måste då öppna en PR, och ändringen får ett spår i pull request och audit log, men aktören kan välja att kringgå branch protections och mergea. Ett revisionsspår gör alltså inte undantaget riskfritt; det gör beslutet granskningsbart.
Ge bypass till en namngiven testaktör med minsta rimliga omfattning. Skapa en ny syntetisk alert, bekräfta att en vanlig utvecklare blockeras och låt sedan bypass-aktören öppna eller använda PR:en enligt er rutin. Spara vem som använde bypass, tidpunkt, motivering, PR, alert och var audit-log-händelsen återfinns. Återställ teständringen och ta bort tillfällig bypass efter provet.
Stoppa utrullningen om teamet inte kan svara på två frågor: vilka aktörer kan kringgå just detta ruleset, och vem granskar en faktisk bypass i efterhand? En bred adminroll som ”reserv” är inte ett dokumenterat incidentflöde.
Godkänn först när fyra separata bevis håller
Rulla därefter ut rulesetet stegvis till fler repositoryn och upprepa minst ett syntetiskt prov per målgrupp. Repository-mål, grenmatchning och valda mönster är en del av kontrollen; en korrekt regel som inte träffar den avsedda huvudgrenen skyddar ingenting där.
Håll isär mergekontroll och incidenthantering
Den här provplanen använder bara ogiltiga testvärden. Om scanningen hittar en verklig hemlighet ska du behandla den som komprometterad, rotera eller återkalla den och granska eventuell obehörig användning innan alerten stängs. Monkeybases guide om läckta hemligheter i en ärvd kodbas går igenom upptäckt och rotation. Här är målet smalare: att verifiera att PR-regeln faktiskt stoppar det som rulesetet säger.
På samma sätt ersätter regeln inte en bredare mergegrind. Status checks, tester, granskning och andra stoppregler behöver fortfarande ägas som ett sammanhängande flöde. I stoppregler före merge för AI-genererad kod finns ramen för den större CI-strategin; den här nyheten äger bara secret-scanning-villkoren och bypassprovet.
Källor
- GitHub Changelog: Block pull requests with exposed secrets from merging – lanseringsdatum, de två kontrollvillkoren, standardkategori, produktkrav och skillnaden mot push protection.
- GitHub Docs: Blocking pull request merges that contain secrets – prerequisites, stödda mönsterkategorier, undantaget för AI-detected secrets och konfigurationsstegen.
- GitHub Docs: Resolving alerts from secret scanning – att borttagen kod inte stänger alerten automatiskt och ordningen mellan stängd alert och slutförd scan.
- GitHub Docs: Creating rulesets for a repository – aktivt enforcement-läge, tillåtna bypassaktörer och spåret från PR-only-bypass.
Uppgifterna kontrollerades mot GitHubs primärkällor den 10 september 2026. Funktionen är public preview och kan ändras; kontrollera aktuell dokumentation och den effektiva ruleset-konfigurationen innan utrullning.