GitHub maakt scannen naar secrets beschikbaar voor alle openbare repo's

GitHub blokkeert voortaan standaard alle informatie zoals api-sleutels en private en secret keys in openbare repository's. Ook andere identificeerbare en gevoelige informatie wordt voortaan geblokkeerd als gebruikers via git pushen naar een open repo. De functie was er eerder in bèta.

GitHub schrijft in een blogpost dat de functie genaamd 'push protection' voortaan breed beschikbaar is. Die beschikbaarheid geldt voor alle publieke repo's op het platform. Verder kunnen gebruikers de functie toepassen op private repo's als ze een Advanced Security-abonnement hebben.

Push protection scant iedere commit naar een openbare repo op de aanwezigheid van secrets of gevoelige informatie. Het gaat dan om api-keys, access tokens, secrets of wachtwoorden die in code zitten. Ook blokkeert GitHub standaard certificaten en andere mogelijk gevoelige informatie. GitHub zegt dat het samenwerkt met verschillende partijen om te zorgen dat het aantal valspositieve meldingen klein blijft. Het bedrijf werkt daarvoor samen met andere diensten als AWS en Google.

De functie werkt direct vanuit zowel IDE's met gui's als vanuit de command line als gebruikers tools als git gebruiken. Gebruikers die code pushen met secrets erin, krijgen dan een waarschuwing te zien. Die kan worden genegeerd, maar gebruikers moeten dan een reden invullen waarom het nodig is een secret in te vullen. Als ze dat doen binnen de repo van een grote organisatie, dan krijgen de beheerders daarvan een melding.

De functie kwam vorig jaar al uit in bèta, maar was toen alleen nog beschikbaar voor Advanced Security-gebruikers. Tijdens de bètaperiode zijn er 17.000 leaks tegengehouden, zegt GitHub.

Reacties (28)

[DaSt1986]

Goede dienst wel, maar ben erg benieuwd hoe GitHub bepaalt wat een secret is, en wat niet. Als ik een hexadecimale string van 32 characters gebruik voor het een of ander, kan het best zijn dat het geen secret is, maar GitHub dat wel denkt.

[The Zep Man]

Als ik een hexadecimale string van 32 characters gebruik voor het een of ander, kan het best zijn dat het geen secret is, maar GitHub dat wel denkt.

Je kan natuurlijk zien hoe die string met welke welke functies gebruikt wordt, en wat voor variabelenaam je eraan geeft. Geen systeem is perfect, maar met dat gecombineerd vang je al best wel veel af.

superSecretKey = "hunter2";
(...)
cipherText = encryptVerySecurely(plainText, superSecretKey);

Lijkt mij redelijk duidelijk wat het probleem is.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 12:50]

[Kees]

Totdat dat onderdeel is van een test die kijkt of je applicatie nog wachtwoorden kan vergelijken om mensen correct in te loggen.

Maar als ik de foutmelding goed lees dan krijg je ook de mogelijkheid om dat dan alsnog toe te staan

[Reactie gewijzigd door Kees op 1 augustus 2024 12:50]

[AchtungYall]

Dan kan hij zien dat het onderdeel is van een test?

[Christoxz]

maar ben erg benieuwd hoe GitHub bepaalt wat een secret is

De patterns kan je hier inzien:
https://docs.github.com/e...atterns#supported-secrets

Daarnaast kan je ook custom patterns aanmaken!
https://docs.github.com/e...terns-for-secret-scanning

Late edit, maar zie net dit:
Als bedrijf/service provider kan je je aanmelden om tussen de standaard scanning patterns te komen.
https://docs.github.com/e...-scanning-partner-program

[Reactie gewijzigd door Christoxz op 1 augustus 2024 12:50]

[Memori]

Dat laatste: Één stap verwijderd van automatische massa copyright claims op Github.

[watercoolertje]

Denk dat ze dat wel uit de context kunnen halen waar/hoe die variabele gebruikt wordt, met hun eigen CoPilot (AI) waarschijnlijk.

Het is gewoon een extra controlemiddel, je kunt in de screenshot zien dat je ondanks dat ze secrets vinden je het alsnog kan forceren, dus als je het wel bewust in de code hebt kan je het alsnog pushen.

Heb je het niet bewust in je code dan ben je behoed voor een lek in je applicatie (of die van een ander waar de key voor is).

Als gebruiker mag je er ook niet van uit gaan dat een ander je problemen oplost dus je moet altijd zelf verantwoording nemen, en dit is gewoon een extraatje erbovenop. Je stelt de vraag (imo) echter alsof developers hierop moeten (kunnen) vertrouwen, maar die hebben gewoon hun eigen verantwoordelijkheid!

[Reactie gewijzigd door watercoolertje op 1 augustus 2024 12:50]

[jaenster]

Inderdaad. Dit moet je zien als een cirkelzaag die zichzelf uitknalt als er een vinger tegen aan komt. Fantastisch dat deze techniek bestaat, maar dat betekend niet dat je nu klakkeloos om kan gaan met een cirkelzaag. Je moet nog altijd opletten.

[supersnathan94]

Nouja. Dingen zoals een .aws folder in je project, zaken als environment variabelen in .env files. Zijn best een hoop zaken die door applicaties als standaard keys zijn gedefinieerd en die kun je heel simpel met regex matching vinden.

Tools als Sonarqube doen dit immers al jaren, maar dan heb je het vaak al in VCS staan.

[Frappuccino]

Klopt de titel wel?

GitHub maakt scannen naar secrets beschikbaar voor alle openbare repo's

GitHub blokkeert voortaan standaard alle informatie zoals api-sleutels en private en secret keys in openbare repository's. Ook andere identificeerbare en gevoelige informatie wordt voortaan geblokkeerd als gebruikers via git pushen naar een open repo. De functie was er eerder in bèta.

[Reactie gewijzigd door Frappuccino op 1 augustus 2024 12:50]

[Victorppp]

Ja de titel klopt. Ze maken een functie beschikbaar die geheime informatie blokkeert tijdens een commit. Dus ze scannen op informatie die je liever geheim houdt en mocht je deze hebben stoppen ze de commit.

[curkey]

Het voorkomt hopelijk wel inderdaad die gehaaste vrijdagmiddag laat nog even snel want de borrel begint zo commit, waar je niet al te goed over hebt nagedacht.

[stuiterveer]

De commit niet, de push naar Github wel. Als je Github dus meer gebruikt als archief nadat je al alle andere dingen hebt gedaan kan het kwaad al geschied zijn. Dus het is an sich wel een goede functie, maar men moet er niet blindelings op vertrouwen.

[watercoolertje]

Uit de screenshot maak ik op dat ze wel per commit controleren, ookal push je dus 10 commits tegelijk, er staat vrij duidelijk welk bestand in welke commit het probleem is gevonden.

Dan zal je dus om het op te lossen je lokale repository moeten resetten naar een commit van voor het probleem. En dan alle wijzigingen opnieuw committen muv de key/wachtwoord/.env file of wat de melding ook was.

edit:
Staat ook gewoon in de tekst:

Push protection scant iedere commit naar een openbare repo op de aanwezigheid van secrets of gevoelige informatie.

[Reactie gewijzigd door watercoolertje op 1 augustus 2024 12:50]

[stuiterveer]

Staat ook gewoon in de tekst:

[...]

De vertaling die in het artikel staat is... jammer. Die functie heet letterlijk Push Protection, wat de nadruk geeft op specifiek pushen. De blogpost vanuit Github zelf legt ook veel meer de nadruk op problemen aan de hand van commits die gepushed worden en niet zozeer de commit zelf (al is dat natuurlijk de catalysator van het geheel).

Sterker nog: Github kan maar beperkt commits scannen die nog niet gepushed zijn. Wijzig je code binnen de web interface of Github desktop client, dan kunnen ze inderdaad nog wel de commit zelf onderscheppen en hierop waarschuwen voordat het uberhaupt ergens terechtkomt (is dan nog maar de vraag of ze dat ook doen of dat het vooralsnog enkel de pushes controleert). Maar als je via een andere git client (bijvoorbeeld de standaard git packages binnen Linux distro's) een commit doet dan kan Github dat niet controleren tot het langs hen gepushed wordt.

[Falcon]

Ik zou op vrijmiddag helemaal geen commits meer toelaten in repo's

[curkey]

Dat is zeker het overwegen waard, mocht je bedrijfscultuur zodanig zijn ingericht dat de beergoggles vroeg worden uitgereikt.

Maar het was vooral bedoeld als metafoor voor de haastklus, waarbij je niet goed oplet en toch net iets meer in je set hebt zitten dan wat je dacht.

Tuurlijk, het zal niet bullet proof zijn, maar toch fijn als het wat nare situaties voorkomt zonder dat er al teveel ellende voor terugkomt.

[Falcon]

Aan de andere kant iets pushen is niet erg, zolang je maar geen PR naar Main gaat mergen met een PR review van een collega die op vrijdagmiddag met een biertje in de hand is gebeurd

[Reactie gewijzigd door Falcon op 1 augustus 2024 12:50]

[BCC]

Tja, als het in de brand staat op vrijdagmiddag zul je toch iets moeten

[Falcon]

Zolang het niet op PRD staat is er geen brand.

[SPee]

Aan de andere kant iets pushen is niet erg, zolang je maar geen PR naar Main gaat mergen met een PR review van een parttime werkende collega die op donderdagmiddag met een biertje in de hand is gebeurd

FTFY

Ik ben hierdoor een hele vrijdag bezig geweest samen met een applicatiebeheerder om een vreemde issue te onderzoeken. Uiteindelijk bleek dat een ander team een deployment (alvast) had uitgevoerd met een placeholder wachtwoord en daardoor werd het account continue voor enige tijd gelockt. En dat was een gedeeld account, waardoor het primaire systeem ook last van die tijdelijk lock had. Daar zit je dan met je 24/7 uptime. Lang leve DevOps! En een volledig team dat parttime op vrijdag vrij is!

[RoestVrijStaal]

Want door het pushen van remote branches gaat er wat stuk?

Met uitzondering van de master of als het brand mag pushen wel. In de master mergen "liever niet" en deployen al helemaal niet

[Reactie gewijzigd door RoestVrijStaal op 1 augustus 2024 12:50]

[LuCarD]

Waarom zou je niet mogen deployen en pushen naar de master/main branch? Als je daar niet comfortabel bij bent moet je eens goed kijken naar je CI/CD process.

Ik heb bij meerdere bedrijven gewerkt waar ik zonder angst kan pushen naar master/main het kan zijn dat ik de master/main branch stuk maak en dat mijn commit moet worden gerevert. Maar productie zou nooit een probleem moeten ervaren.

[RoestVrijStaal]

Nu komen we op het punt dat per bedrijf de release flow verschilt, maar ik doe een poging.

Je wilt niet urgente merge requests niet mergen op een vrijdag. Omdat je in geval van een hotfix op die vrijdag of weekend de master blockt.

En de master is leading, daarom heet het ook master.

[Reactie gewijzigd door RoestVrijStaal op 1 augustus 2024 12:50]

[SchizoDuckie]

Jammer weer dit. Het is weer echt het minimale wat ze hadden kunnen doen.
Het grootste probleem wat ik elke keer weer tegenkom bij Responsible Disclosures van lekkende secrets in Github repo's is het scenario "luie dev cloned even de private repository en pushed het naar een nieuwe net aangemaakte public repo"

En 3x raden wat er gebeurt als je een nieuwe repo aanmaakt: Secret scanning staat default uit.

[Blue_Airplane]

Hoezo is dit jammer?
Hadden ze wellicht nog meer mitigerende opties kunnen implementeren, wellicht maar dat is niet de taak van GitHub. Jij als developer bent uiteindelijk verantwoordelijk voor wat je pushed.
Dat GitHub hiervoor nu tooling beschikbaar stelt om er voor te zorgen dat jij als developer minder vaak de fout in gaat is alleen maar prettig. Niet alleen voor jou als developer natuurlijk maar ook voor GitHub, hun naam zal als het goed is minder vaak in verband gebracht worden met het "lekken" van sercrets.

Lang verhaal kort, je bent en blijft zelf verantwoordelijk voor wat je pusht, niet GitHub.

[comecme]

Maar hoe kun je dit dan fixen als je lokaal al commits hebt gedaan na dit secret en die hele riedel probeert te pushen? Je kunt wel een nieuwe commit doen waarin je het secret weer verwijdert, maar dan bevat je push nog steeds die eerdere commit mét het secret.

Klinkt ingewikkeld om te fixen.

Edit: als je normaal alleen in de IDE van Visual Studio werkt is dit best omslachtig inderdaad. Maar hoe je het kunt doen staat hier beschreven.

[Reactie gewijzigd door comecme op 1 augustus 2024 12:50]