Een van de risico's van de softwaretoeleveringsketen is het lekken van geheimen. Er zijn overal in de softwaretoeleveringsketen geheimen; ontwikkelaars en de CI\CD-pijplijnen moeten geheimen gebruiken om toegang te krijgen tot de SCM, de pijplijn, de artefactregisters, de cloudomgevingen en externe services. En als er overal geheimen zijn, is het een kwestie van tijd totdat ze lekken.
Dit risico is goed onderkend, en veel raamwerken voor de toeleveringsketen van software pakken dit aan door geheim scannen en geheim zelfverlopen te vereisen.
Wat zou er mis kunnen gaan als u, als beveiligingsprofessional, deze vangrails heeft geplaatst?
Tijdens mijn onderzoek naar geheime scantools kwam ik deze week één antwoord tegen. Dit antwoord is simpel: omdat geheime scanners naar patronen van geheimen zoeken, kan de detectie mislukken als het geheime formaat verandert. En dit is precies wat er gebeurde toen GitHub een nieuwe beveiligingsfunctie introduceerde: de fijnkorrelige tokens. Deze bètafunctie is een van GitHub's manieren om de risico's op het lekken van geheimen te verminderen; het beperken van de machtigingen van de persoonlijke toegangstokens beperkt ook de risico's als deze geheimen in gevaar zouden komen.
Het blijkt dat het formaat van de nieuwe tokens een beetje anders is, terwijl het formaat van de oude tokens ongeveer zo was:
ghp_123456789012345678901234567890123456
Het nieuwe tokenformaat is als volgt:
github_pat_123456789012345678901234567890123456789012345678901234567890…
Zowel het voorvoegsel als de lengte van het geheim zijn verschillend.
En inderdaad, sommige geheime scanners slagen er niet in het nieuwe formaat te detecteren;
Om te experimenteren heb ik een repository gemaakt met een Dockerfile met een geheim en een workflow die de Trivy-actie uitvoert. Zo ziet de Dockerfile er aan het begin van het experiment uit:
Hieronder volgt een momentopname van de GitHub Secret Scanner, die het nieuw geformatteerde geheim detecteert:
Zoals we kunnen zien, detecteert de geheime scanner van GitHub het geheim, maar verschijnen er geen waarschuwingen in de sectie Code scannen.
Om te verifiëren dat de tooling correct is ingesteld, zal ik nu een klassiek geheim toevoegen aan de Dockerfile (zie hieronder) en de scan opnieuw uitvoeren. Nu krijgen we een waarschuwing voor het scannen van codes (alleen voor het klassieke geheim!)
De scanner van Github detecteert nu twee geheimen:
Ik heb een beveiligingsprobleem geopend voor Trivy; Het team van Trivy antwoordde dat dit geen kwetsbaarheid of beveiligingsprobleem is. Wat er nog moest gebeuren was een issue openen.
Dit experiment roept veel zorgen op;
- Waarom zou een GitHub-gebruiker vermoeden dat het tokenformaat zou worden gewijzigd vanwege een nieuwe functie?
- Gegeven het feit dat geheimen er uit moeten zien als willekeurige strings, waarom zou een GitHub-gebruiker zich dan überhaupt druk maken over het formaat van de geheimen?
- Moet GitHub verantwoordelijk zijn voor het informeren van zijn klanten over een dergelijke wijziging?
- Is deze mislukking van de geheime detectie een kwetsbaarheid van de fijnmazige geheimen van GitHub, een kwetsbaarheid van Trivy, of, zoals Aqua Security het ziet, helemaal geen kwetsbaarheid?
- Moet Aqua Security, het bedrijf achter Trivy, verantwoordelijk zijn voor het updaten ervan?
- Aangezien Trivy een open source-project is, geleverd zoals het is, zou iemand aansprakelijk zijn als er geheimen zouden lekken uit een pijpleiding die door Trivy wordt beschermd? Wie zou het zijn? GitHub? Aqua-beveiliging? De Trivy-gebruiker?
- Wat leert dit experiment ons over het vertrouwen in beveiligingstools die zijn geïnstalleerd om de toeleveringsketens van software te beschermen?
Ik laat deze vragen open.
Eén ding is echter duidelijk; het beschermen van de softwaretoeleveringsketen is ingewikkeld en we hebben een zeer professionele gemeenschap nodig om deze taak blijvend te kunnen volbrengen.
Dit bericht is mede geschreven door Avi Waxman, stagiair bij Scribe Security
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
