Een toegangssleutel kan buiten de eigen ontwikkelomgeving belanden zonder dat iemand bewust bedrijfsinformatie wil delen. Een voorbeeldproject, een publieke foutmelding of een persoonlijke fork kan al genoeg zijn. Wie alleen de eigen repositories controleert, heeft daardoor niet automatisch zicht op alle plekken waar gevoelige gegevens terechtkomen.
GitHub heeft op 1 juli public monitoring voor secret scanning aangekondigd als publieke preview voor daarvoor in aanmerking komende Enterprise Cloud-klanten. De functie helpt gelekte sleutels op publieke onderdelen van GitHub aan een organisatie te koppelen. Het uitgangspunt is dat een organisatie ook relevante meldingen moet kunnen krijgen wanneer het lek buiten de eigen repositories ontstaat.
Voor ontwikkelteams is vooral de opvolging van zo’n melding belangrijk. Het verwijderen van een bestand maakt een eenmaal gedeelde sleutel niet vanzelf weer veilig. Een duidelijk draaiboek beschrijft daarom wie de sleutel intrekt, welke vervanging nodig is en hoe gecontroleerd wordt of de oude toegang is gebruikt. Ook systemen die de sleutel legitiem gebruiken, moeten na een wijziging blijven werken.
Een goede aanpak begint eerder: plaats geheimen niet in broncode, beperk hun rechten en houd bij waarvoor ze worden gebruikt. Oefen daarnaast het vervangen van sleutels. Detectie wordt pas echt waardevol wanneer een team een melding snel kan omzetten in een gecontroleerde herstelactie.