GitHub Push Protection instellen: grote pushes kunnen de scan ontwijken

|Auteur: Redactie van QUASA|5 min. leestijd
GitHub Push Protection instellen: grote pushes kunnen de scan ontwijken

Open in de repository Settings, ga onder Security and quality naar Advanced Security en schakel eerst Secret Protection en daarna Push protection in. De instelstappen voor een repository vermelden ook wie deze instellingen mag wijzigen. Push Protection blokkeert een push met een herkend, ondersteund geheim voordat die de repository bereikt en maakt een melding wanneer iemand de blokkade omzeilt.

Een geslaagde push bewijst niet dat de code vrij is van geheimen. De grenzen van de detectie omvatten mogelijke time-outs bij grote pushes; bij openbare repositories wordt een push van meer dan 50 MB door Push Protection overgeslagen. Richt daarom naast de blokkade ook de opvolging van secret-scanningmeldingen in.

Begin met een afgebakende pilot

Kies een repository met een duidelijke eigenaar en een beperkte groep bijdragers. Controleer wie de beveiligingsinstellingen kan wijzigen, wie meldingen ontvangt en wie een gevonden credential kan laten intrekken. Voor private en interne repositories van organisaties hangt de beschikbaarheid van Secret Protection af van het GitHub-abonnement en de ingeschakelde bescherming; controleer of de opties in deze repository zichtbaar zijn.

  1. Open de hoofdpagina van de pilotrepository en kies Settings.
  2. Ga onder Security and quality naar Advanced Security.
  3. Schakel Secret Protection in als die nog uitstaat en zet vervolgens Push protection aan.
  4. Wijs eigenaren aan voor geblokkeerde pushes, bypassverzoeken en meldingen na een push.

Leg vast welke repositories meedoen en controleer de instelling per repository. Daarmee weten bijdragers waar zij een blokkade kunnen verwachten. Spreek tegelijk af via welk kanaal zij een gevonden geheim melden, zodat de eigenaar snel toegang kan intrekken of de credential kan vervangen.

Test met een tijdelijk geheim zonder productierechten

Gebruik voor de proef een afgeschermde repository en een tijdelijke credential van een type dat Push Protection ondersteunt. Geef die credential minimale rechten en geen toegang tot productiediensten. Een willekeurige tekenreeks is geen betrouwbare test: herkenning hangt af van het geheimtype, het patroon en soms de geldigheid of versie van de credential.

Plaats de testcredential in een lokale commit en probeer de branch te pushen. Controleer of de push wordt geblokkeerd en of de melding de vindplaats aanwijst. Verwijder de waarde daarna uit alle commits waarin zij voorkomt en probeer opnieuw te pushen; een extra commit die alleen het huidige bestand opschoont, laat het geheim in eerdere commits staan.

Trek de testcredential na afloop in, ook wanneer de push onverwacht slaagt. Controleer in dat geval of het gekozen type door Push Protection wordt ondersteund en of de bescherming op de juiste repository actief was. Behandel de doorgelaten waarde als mogelijk blootgesteld totdat zij onbruikbaar is gemaakt.

Regel bypass voordat je opschaalt

Een blokkade kan door een bijdrager met een opgegeven reden worden omzeild. Met gedelegeerde bypass voor Push Protection wijs je rollen of teams aan die uitzonderingen beoordelen; stel die goedkeuringsroute al tijdens de pilot in. Andere bijdragers moeten dan een verzoek indienen in plaats van zelf een herkend geheim toe te laten.

Laat een verzoek uitleggen waarom de gevonden waarde veilig zou zijn en wie dat heeft vastgesteld. Een foutieve herkenning of een onschuldige testwaarde kan een onderbouwde uitzondering rechtvaardigen. Gaat het om een echte credential, laat de eigenaar haar intrekken of vervangen en verwijder de waarde uit de betrokken commits voordat de bijdrager opnieuw pusht.

Voor bredere invoering kan de organisatie een beveiligingsconfiguratie met Push Protection en bypassrechten maken en toepassen op geselecteerde repositories. Controleer daarna of de configuratie daadwerkelijk op die repositories actief is. Een volledige vrijstelling voor een account slaat de controle voor diens pushes over; reserveer die mogelijkheid voor bewust gekozen automatisering en leg vast wie daarvoor verantwoordelijk is.

Houd rekening met gemiste detectie bij grote pushes

Een omvangrijke import of complexe geschiedenis kan de controle laten stoppen voordat zij een geheim blokkeert. Splits grote wijzigingen waar dat werkbaar is in kleinere pushes, maar gebruik een geslaagde push nooit als bewijs dat alle geheimen zijn gevonden. Controleer na zo’n push de secret-scanningmeldingen: ook na een time-out kan nog een melding verschijnen.

Push Protection blokkeert slechts een deel van de patronen die secret scanning herkent. Oudere versies van bepaalde tokens kunnen buiten de blokkade vallen. Bij credentials die als paar worden herkend, moeten beide onderdelen in hetzelfde bestand aanwezig zijn. Een bypassverzoek zonder vindplaats kan bovendien wijzen op een push waarvoor de controle onvoldoende tijd had om de betrokken commit te bepalen.

Reageer op een geblokkeerd of later gevonden geheim

Bij een geblokkeerde push verwijder je de waarde uit de betrokken lokale commits en probeer je opnieuw. Is een echte credential al in GitHub terechtgekomen, achterhaal dan welke dienst haar uitgeeft en welke toepassingen haar gebruiken. Laat de eigenaar de credential intrekken of vervangen, werk afhankelijke toepassingen bij en beoordeel beschikbare toegangslogs op mogelijk misbruik. Alleen de regel uit het huidige bestand verwijderen maakt een eerder blootgestelde credential niet onbruikbaar.

Bekijk ook bestaande secret-scanningmeldingen en laat de repositorygeschiedenis beoordelen op oudere geheimen. Dat is afzonderlijk werk: het inschakelen van Push Protection voor nieuwe pushes verhelpt eerdere blootstelling niet. Wijs iedere vondst toe aan de eigenaar van de credential en controleer of dezelfde waarde elders is gebruikt voordat je de melding afsluit.

Beslis na intrekking of vervanging of ook de Git-geschiedenis moet worden herschreven. Dat kan gevolgen hebben voor branches, forks en lokale clones en vraagt coördinatie met bijdragers. Documenteer welke credential is vervangen, welke toepassingen zijn bijgewerkt en welke meldingen nog openstaan; zo blijft een latere bypassbeoordeling gebaseerd op de werkelijke status.

Lees ook:

Delen:

Abonneer je op onze nieuwsbrief

Ontvang het laatste nieuws over Web3, AI en crypto rechtstreeks in je inbox.

0