Eines der Risiken der Software-Lieferkette ist die Offenlegung von Geheimnissen. Überall in der Software-Lieferkette lauern Geheimnisse. Entwickler und die CI\CD-Pipelines müssen Geheimnisse verwenden, um auf den SCM, die Pipeline, die Artefaktregister, die Cloud-Umgebungen und externe Dienste zuzugreifen. Und wenn es überall Geheimnisse gibt, ist es eine Frage der Zeit, bis sie ans Licht kommen.
Dieses Risiko ist gut erkannt und viele Software-Lieferketten-Frameworks begegnen ihm, indem sie das Scannen von Geheimnissen und den Selbstablauf von Geheimnissen erfordern.
Was könnte also schiefgehen, wenn Sie als Sicherheitsexperte diese Leitplanken eingerichtet haben?
Als ich diese Woche nach geheimen Scan-Tools recherchierte, stieß ich auf eine Antwort. Diese Antwort ist einfach: Da Geheimscanner nach Mustern von Geheimnissen suchen, kann die Erkennung fehlschlagen, wenn sich das Geheimformat ändert. Und genau das geschah, als GitHub eine neue Sicherheitsfunktion einführte – die feinkörnige Token. Diese Beta-Funktion ist eine von GitHubs Möglichkeiten, das Risiko der Weitergabe von Geheimnissen zu verringern. Durch die Einschränkung der Berechtigungen der persönlichen Zugriffstoken werden auch die Risiken einer Kompromittierung dieser Geheimnisse begrenzt.
Es stellt sich heraus, dass das Format der neuen Token etwas anders ist, während das Format der alten Token etwa so war:
ghp_123456789012345678901234567890123456
Das neue Token-Format sieht wie folgt aus:
github_pat_123456789012345678901234567890123456789012345678901234567890…
Sowohl das Präfix als auch die Länge des Geheimnisses sind unterschiedlich.
Und tatsächlich können einige geheime Scanner das neue Format nicht erkennen;
Zum Experimentieren habe ich ein Repo mit einer Docker-Datei mit einem Geheimnis und einem Workflow erstellt, der die Trivy-Aktion ausführt. So sieht das Dockerfile zu Beginn des Experiments aus:
Es folgt ein Schnappschuss des GitHub Secret Scanners, der das neu formatierte Geheimnis erkennt:
Wie wir sehen können, erkennt der Secret-Scanner von GitHub das Secret, im Abschnitt „Code-Scanning“ werden jedoch keine Warnungen angezeigt.
Um zu überprüfen, ob das Tool richtig eingestellt ist, füge ich jetzt ein klassisches Geheimnis zur Docker-Datei hinzu (siehe unten) und führe den Scan erneut aus. Jetzt erhalten wir eine Code-Scan-Benachrichtigung (nur beim klassischen Geheimnis!)
Der Scanner von Github hingegen erkennt nun zwei Geheimnisse:
Ich habe ein Sicherheitsproblem für Trivy eröffnet; Das Team von Trivy antwortete, dass es sich hierbei weder um eine Schwachstelle noch um ein Sicherheitsproblem handele. Es blieb nur noch, ein Problem zu eröffnen.
Dieses Experiment wirft viele Bedenken auf;
- Warum sollte ein GitHub-Benutzer vermuten, dass das Token-Format aufgrund einer neuen Funktion geändert wird?
- Warum sollte sich ein GitHub-Benutzer angesichts der Tatsache, dass Geheimnisse wie zufällige Zeichenfolgen aussehen sollen, überhaupt um das Format der Geheimnisse kümmern?
- Sollte GitHub dafür verantwortlich sein, seine Kunden über eine solche Änderung auf dem Laufenden zu halten?
- Ist dieser Fehler bei der Erkennung von Geheimnissen eine Schwachstelle der feinkörnigen Geheimnisse von GitHub, eine Schwachstelle von Trivy oder, wie Aqua Security es sieht, überhaupt keine Schwachstelle?
- Sollte Aqua Security, das Unternehmen hinter Trivy, für die Aktualisierung verantwortlich sein?
- Da es sich bei Trivy um ein Open-Source-Projekt handelt, das so bereitgestellt wird, wie es ist, würde jemand haftbar gemacht werden, wenn Geheimnisse aus einer von Trivy geschützten Pipeline durchgesickert wären? Wer würde es sein? GitHub? Aqua-Sicherheit? Der Trivy-Benutzer?
- Was lehrt uns dieses Experiment über das Vertrauen in Sicherheitstools, die zum Schutz von Software-Lieferketten installiert werden?
Ich lasse diese Fragen offen.
Eines ist jedoch klar; Der Schutz der Software-Lieferkette ist kompliziert und wir brauchen eine hochprofessionelle Community, um dieser Aufgabe dauerhaft gerecht zu werden.
Dieser Beitrag wurde mitverfasst von Avi Waxman, Praktikant bei Scribe Security
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
