Lassen Sie mich Ihnen eine wahre Geschichte erzählen. Ein Entwickler hat gegen 21:00 Uhr einen Rails-Code in sein Github-Repo geschoben und sich schlafen gelegt. Am nächsten Morgen wachte er mit einer schockierenden Mail über die Spesenabrechnung des AWS-Kontos auf. Berichten zufolge waren es 4900 US-Dollar, was viel zu viel war als seine durchschnittlichen Ausgaben von 2 US-Dollar pro Tag.

Als er sich die RCA ansah, fand er heraus, dass Somebody 20 c3.8xlarge EC2-Instanzen in jeder Region hochgefahren hatte, was sich in nur einer Nacht auf 2600 US-Dollar an Berechnung summierte. Diese wurden alle für das Kryptowährungs-Mining verwendet. Wie also hat dieser 'So mebody ' auf Ressourcen zugegriffen und diese hochgefahren?

Interessanterweise wurde beobachtet, dass im Code, der in das Repo verschoben wurde, keine Geheimnisse preisgegeben wurden, der Entwickler jedoch vor einigen Tagen fälschlicherweise einen geheimen Schlüssel in seinen Code übernommen hatte und Bots diesen Zugriffsschlüssel crawlen konnten. Können Sie sich den Alptraum vorstellen?

Kleinere Fehler, größere Wirkung!

Laut einem Bericht von GitGuardian „ wurden im Jahr 2022 auf GitHub 10 Millionen neue Secrets-Vorkommen aufgedeckt . Das ist eine Steigerung von 67 % im Vergleich zu 2021.“

Sie könnten denken, dass wer Hard-Code-Geheimnisse (Verschlüsselungsschlüssel, API-Token und Anmeldedaten) macht? es könnte ein unerfahrener Entwickler sein? Häufige Codeüberprüfungen können diese Kultur reduzieren. Aber stellen Sie sich das heutige schnelllebige Agile SDLC mit VCS, CI/CD, Cloud vor, wo Code häufig und konsequent geklont, verzweigt, verzweigt, kopiert, geteilt und an mehrere lokale bis Unternehmenssysteme gesendet wird und ein einziger Fehler zu beispiellosen Konsequenzen führen kann. Derselbe Bericht stellt auf schockierende Weise fest, dass „ 1 von 10 GitHub-Codeautoren im Jahr 2022 ein Geheimnis preisgegeben haben “.

Geheimnisse sind sehr beängstigend, da es sich nicht um eine Runtime-Schwachstelle handelt. Letztendlich bedeutet dies, dass Ihre Anwendung nicht im laufenden Zustand sein muss, um anfällig zu werden. Wenn Sie sich gerade in Ihrem Code-Repository befinden, ist Ihre Anwendung offengelegt und bereit, ausgenutzt zu werden. Der CWE-798 „ Use of Hard-coded Credentials“ gehört zu den Top 15 der Liste der gefährlichsten Software-Schwächen . Selbst die häufigsten Anwendungsschwachstellen wie XML External Entity (XXE), Server-Side Request Forgery (SSRF) und Cross-Site Request Forgery (CSRF) erfordern, dass Ihre Anwendung im laufenden Zustand ist, um angreifbar zu werden.

In welchen Phasen von SDLC können Geheimnisse aufgedeckt werden?

Geheimnisse können von Einzelpersonen als Form der Einbettung in den Quellcode oder als Konfigurationsdateien aufgerufen werden. In jeder Phase der CI/CD-Pipeline können die Geheimnisse offengelegt werden, sei es durch die Codeerstellungsphase oder durch die Bereitstellung in einer Testumgebung oder durch ein Automatisierungsskript.

Wie vermeidet man Hard Coding Secrets?

Vorbeugen ist immer besser als heilen. Zu verhindern, dass die Geheimnisse beim Zeroth-Schritt preisgegeben werden, wäre die am meisten gesuchte Notwendigkeit. Es kann mit Denkweisen, Praktiken und Werkzeugen umgesetzt werden.

Zuerst müssen wir die Phasen analysieren und identifizieren, in denen die Geheimnisse aufgerufen werden können, und das variiert von Organisation zu Organisation, von Projekt zu Projekt. Aber von Anfang an können wir die Sicherheit so weit wie möglich nach links verschieben. Nach der Identifizierung müssen wir geeignete Kontrollmechanismen einführen, um zu verhindern, dass Geheimnisse durch die Codebasis preisgegeben werden.

• Durch die IDE-Plug-ins können wir Geheimnisse zum Zeitpunkt des Codes erkennen, der sich auf der Workstation des Entwicklers befindet.
• Wir können Git-Hooks verwenden, um Geheimnisse in den Phasen Pre-Commit, Post-Commit, Pre-Push, Pre-Receive und Post-Receive zu erkennen.
• Die Geheimnisse können durch die statischen Tests mit SAST-Tools erkannt werden
• Post-Build-Software-Kompositionsanalyse und Binär-Scan beinhalten auch die Geheimerkennung.
• Interaktive Anwendungssicherheitstests (IAST) müssen auch nach Geheimnissen suchen.
• Das Scannen von Docker-Images und K8S-YAML-Dateien sollten Teil der Überprüfungen sein.

Also, jetzt (wenn nicht gestern!) ist der beste Zeitpunkt, um gegenüber einer sicherheitsgehärteten Organisation für „ absolut keine hartcodierten Geheimnisse“ zu bürgen .