Secrets im Source Code – unterschätztes Risiko mit echten Folgen

Secrets wie API-Keys, Datenbank-Passwörter oder private Zertifikate haben im Quellcode nichts verloren. Trotzdem passiert genau das ständig. Die Konsequenzen sind oft richtig teuer oder öffnen Angreifern Tür und Tor.

Ein klassisches Beispiel aus der Realität, was jeder bereits gehört hat: Entwickler laden versehentlich AWS-Access-Keys in ein öffentliches GitHub-Repository. Innerhalb weniger Minuten fanden Bots die Keys und missbrauchten sie, um auf fremde Kosten virtuelle Maschinen hochzufahren. Am Ende standen fünf- bis sechsstellige Rechnungen.

Heute durchsuchen spezialisierte Crawler automatisch Plattformen wie GitHub, GitLab oder Bitbucket nach solchen Leaks. Wird ein Secret öffentlich, dauert es oft nur Sekunden, bis es aktiv ausgenutzt wird. Auch in privaten Repositories ist man nicht sicher. Sie können versehentlich freigegeben, kopiert oder von Insidern kompromittiert werden. Besonders gefährlich: Selbst wenn ein Secret später aus dem Code entfernt wird, bleibt es oft in der Git-Historie erhalten. Alte Clones oder Forks haben weiterhin Zugriff darauf. Das nachträgliche Bereinigen der Historie ist aufwendig und oft nicht unbedingt zuverlässig. Wer es trotzdem versucht, findet von GitHub eine detaillierte Anleitung dazu.

Secrets im Code erkennen

Ein wichtiger Schritt in Richtung mehr Sicherheit ist es, Secrets frühzeitig aufzuspüren, am besten bevor diese committet wurden. Dabei sollte auf verschiedene Arten von sensiblen Daten geachtet werden. Einige Beispiele sind:

• Private Keys wie SSH-Schlüssel
• Private Zertifikate zum Beispiel PFX-Dateien
• Passwörter in SQL-Connection-Strings
• Azure Shared Access Keys für Storage Accounts oder Service Bus

Wird ein Secret in einem Repository gefunden, ist es wichtig, schnell zu handeln. Das bedeutet, den Code zu bereinigen und das Secret zu rotieren. Das kann je nach Art des Secrets und der betroffenen Systeme sehr aufwendig sein. Um solche Leaks zu entdecken, gibt es unterschiedliche Ansätze.

Strategien zur Secret-Erkennung

Die wichtigste Maßnahme ist, Secrets gar nicht erst lokal im Code oder auf der Entwicklermaschine abzulegen. Moderne Anwendungen laden sensible Informationen bei Bedarf sicher aus zentralen Services wie Azure Key Vault oder AWS Secrets Manager oder speichern diese lokal außerhalb des Repositories mit Funktionen wie dem User Secrets Configuration Provider in .NET. Dadurch reduziert sich das Risiko, dass ein Secret versehentlich ins Repository oder in ein Deployment gelangt. Eine weitere effektive Strategie ist die Minimierung oder der vollständige Verzicht auf Passwörter und Schlüssel im Code. Azure bietet hierfür Möglichkeiten wie Workload Identity Federation, Managed Identities oder Service Principals, die den Einsatz von Secrets überflüssig machen. Diese Ansätze sind nicht nur sicherer, sondern auch einfacher zu handhaben, da sie den Zugriff auf Ressourcen über Identitäten steuern, die von der Cloud-Plattform verwaltet werden. Dadurch entfällt die Notwendigkeit, Passwörter oder Schlüssel im Code zu speichern.

Werkzeuge zur Erkennung von Secrets

Secrets im Code können schwerwiegende Sicherheitsprobleme verursachen, wenn sie unentdeckt bleiben. Um solche Risiken zu minimieren, stehen verschiedene spezialisierte Tools zur Verfügung, die entweder nahtlos in den Entwicklungsprozess integriert oder als eigenständige Anwendungen genutzt werden können. Diese Werkzeuge helfen dabei, sensible Daten frühzeitig zu erkennen und zu entfernen, bevor sie Schaden anrichten können.

Yelp Detect-Secrets ist ein Python-basiertes Werkzeug, das neue Commits analysiert und versucht, mögliche Secrets zu erkennen. Es nutzt heuristisch erstellte reguläre Ausdrücke, um Änderungen in Commits zu überprüfen und neue Secrets zu identifizieren. Dadurch wird vermieden, dass jedes Mal das gesamte Repository oder die gesamte Git-Historie durchsucht werden muss, was die Performance deutlich verbessert. Yelp Detect-Secrets bietet den Vorteil, neue Commits schnell und effizient auf Secrets zu prüfen, da es sich auf spezifische reguläre Ausdrücke stützt und Open Source ist. Allerdings fehlen automatische Validierungen, und für eine optimale Nutzung sind manuelle Konfigurationen sowie zusätzliche Anpassungen für CI/CD-Integrationen erforderlich.

detect-secrets scan

Ein weiteres Tool ist git-secrets von AWS Labs. Es hängt sich direkt an Git Hooks und prüft bei jedem Commit oder Push automatisch auf typische AWS-spezifische Muster. Das macht es besonders für AWS-Nutzer attraktiv. Wer jedoch Secrets von anderen Cloud-Anbietern wie Azure oder GCP absichern möchte, muss zusätzliche Muster selbst ergänzen. Dies erhöht den Aufwand.

trufflehog ist eine flexible Alternative, die ganze Repositories oder einzelne Commits nach konfigurierbaren regulären Ausdrücken durchsuchen kann. Es klassifiziert über 800 Secret-Typen, prüft deren Gültigkeit und liefert detaillierte Analysen zu Zugriffsrechten und Berechtigungen und ob das Secret überhaupt aktiv nutzbar ist oder nicht. Es unterstützt auch die Anbindung an einen Secret Verification Server, der gefundene Treffer weiter verifiziert und damit die Zahl der Fehlalarme reduziert. Trufflehog bietet eine hohe Flexibilität und unterstützt zahlreiche Secret-Typen sowie deren Validierung, was die Fehlalarmquote reduziert. Allerdings kann die umfangreiche Konfigurierbarkeit für Einsteiger komplex wirken und erfordert eine gewisse Einarbeitungszeit.

trufflehog git file://repo

Security Code Scan richtet sich stärker an allgemeine Sicherheitsprobleme in C#-Anwendungen wie SQL Injection oder Cross-Site Scripting, unterstützt aber auch das Erkennen von Hardcoded Passwords. Wer den Analyzer sowieso schon nutzt, kann ihn auch für Secret-Scanning verwenden.

Gitleaks ist unsere Wahl zur Secret-Erkennung. Es lässt sich leicht in Projekte integrieren und unterstützt Plattformen wie Azure, AWS und GitHub. Gitleaks analysiert komplette Git-Historien und bietet flexible Konfigurationsmöglichkeiten. Die aktive Pflege macht es zu einer zuverlässigen Wahl. Für spezifische Anforderungen kann jedoch etwas Einarbeitung nötig sein, und die Analyse großer Repositories erfordert Zeit.

gitleaks git

gitleaks git --report-path gitleaks-report.json # This will save the report in a file called gitleaks-report.json
gitleaks git --baseline-path gitleaks-report.json --report-path findings.json

Integration von Secret-Scanning in den Entwicklungsprozess

Ein wirklich wirksamer Schutz entsteht nur, wenn Secret-Scanning fester Bestandteil des normalen Entwicklungsprozesses wird. Es reicht nicht, gelegentlich nachzusehen oder auf Glück zu hoffen. Zwei zentrale Stellschrauben helfen dabei, eine solide Absicherung zu erreichen.

Die erste Maßnahme ist der Einsatz von Gitleaks als Pre-Commit Hook. Damit wird jeder Commit noch auf der lokalen Maschine überprüft, bevor überhaupt ein Secret die Chance hat, ins Repository zu gelangen. Entwickler werden frühzeitig gewarnt und können Probleme sofort beheben. Solche Pre-Commit Hooks können sehr einfach mit Tools wie Husky eingerichtet werden.

{
  "husky": {
    "hooks": {
      "pre-commit": "gitleaks --path . --report-path gitleaks-report.json"
    }
  }
}

Die zweite wichtige Maßnahme ist die Integration von Gitleaks in die CI/CD Pipeline. Jeder Pull Request oder Merge Request wird automatisch gescannt. Nur wenn keine Secrets gefunden werden, geht der Code weiter in den nächsten Schritt. Diese zusätzliche Ebene sichert ab, dass auch bei lokalen Fehleinstellungen oder vergessenen Hooks keine sensiblen Daten unbemerkt live gehen.

Einige der genannten Tools bieten die Möglichkeit, einen Baseline-Report zu erstellen, der alle gefundenen Secrets enthält. Dieser Report dient dazu, die gefundenen Secrets zu validieren und zu bewerten, ob sie tatsächlich ein Problem darstellen. Anschließend werden nur noch neue Probleme gemeldet, die nicht im Baseline-Report enthalten sind. Dadurch lassen sich Fehlalarme vermeiden, und der Fokus wird auf wirklich kritische Probleme gelenkt. Entwickler müssen nur neue Funde validieren, was den Aufwand reduziert.

Beispiel für Azure DevOps Pipeline mit Gitleaks

Um Gitleaks in einer Azure DevOps Pipeline zu integrieren, kannst du die Gitleaks Marketplace Extension verwenden. Diese Erweiterung lädt automatisch die neueste Version von Gitleaks herunter, führt den Scan durch und bietet eine vordefinierte Konfiguration, die auf die häufigsten Secrets abgestimmt ist. Alternativ kannst du auch eine eigene Konfigurationsdatei bereitstellen.

Ein wichtiger Vorteil der Extension ist, dass gefundene Secrets nicht in den Build-Logs erscheinen. Dadurch wird verhindert, dass sensible Informationen versehentlich in den Logs offengelegt werden.

Beispiel für eine Azure Pipeline mit Gitleaks

steps:
  - task: Gitleaks@3
    inputs:
      scanlocation: '$(Build.SourcesDirectory)'
      configtype: 'predefined'
      predefinedconfigfile: 'GitleaksUdmCombo.toml'
      scanmode: 'directory'
      reportformat: 'sarif'

Das Report-Format SARIF kann genutzt werden, um die Ergebnisse der Gitleaks-Scans direkt in Azure DevOps anzuzeigen. Mithilfe der Microsoft-Erweiterung SARIF SAST Scans Tab lassen sich die Scan-Ergebnisse übersichtlich darstellen und analysieren. Dies erleichtert es, potenzielle Sicherheitsprobleme zu identifizieren und entsprechende Maßnahmen zu ergreifen.

Neben den bereits erwähnten Tools bieten GitHub und Azure DevOps integrierte Lösungen zur Secret-Erkennung. Mit GitHub Advanced Security und GitHub Advanced Security for Azure DevOps können Secrets in Repositories automatisch erkannt und blockiert werden, bevor sie in den Code gelangen. Diese Lösungen sind besonders für Unternehmen geeignet, die bereits auf GitHub oder Azure DevOps setzen, da sie nahtlos in die bestehenden Workflows integriert werden können.

Ein großer Vorteil dieser Dienste ist die einfache Aktivierung und die umfassende Sicherheitsüberprüfung, die sie bieten. Allerdings sind sie kostenpflichtig und bieten möglicherweise weniger Flexibilität im Vergleich zu Open-Source-Alternativen wie Gitleaks oder Trufflehog. Unternehmen sollten daher sorgfältig abwägen, welche Lösung am besten zu ihren Anforderungen und ihrem Budget passt.

Fazit: Sicherheit beginnt beim ersten Commit

Secrets sind keine Nebensache, sie sind zentrale Sicherheitsbausteine jeder Anwendung. Wird ein Secret kompromittiert, geht es nicht nur um ein technisches Problem, sondern schnell um reale finanzielle Schäden, den Verlust von Kundenvertrauen und teure Wiederherstellungsmaßnahmen. Entwicklerteams müssen sich dieser Gefahr bewusst sein und dürfen das Thema nicht auf die leichte Schulter nehmen. Es reicht nicht, zu hoffen, dass schon nichts passiert. Schutz beginnt mit bewussten Entscheidungen und konsequenter Umsetzung.

Der einfachste und gleichzeitig effektivste Schutz ist die Kombination aus Secret-Scanning und zentralem Secrets Management. Wer von Anfang an dafür sorgt, dass Secrets niemals im Quellcode landen und stattdessen aus sicheren Diensten wie Azure Key Vault geladen werden, spart sich später viel Stress. Der Aufwand, diese Prozesse frühzeitig sauber aufzubauen, ist minimal im Vergleich zu dem Aufwand, den ein einziger Sicherheitsvorfall verursachen kann.

Private Repositories bieten dabei keinen echten Schutz. Auch vermeintlich sichere Projekte können durch Fehler, Fehlkonfigurationen oder interne Angriffe kompromittiert werden. Deshalb dürfen Secrets weder in aktuellen Code-Ständen noch in der Git-Historie auftauchen. Der Einsatz von Tools wie Gitleaks, die frühzeitig auf Probleme hinweisen, und die konsequente Nutzung sauber organisierter Secret Stores sind heute keine optionale Optimierung mehr, sondern Pflicht.

Sicherheit muss nicht kompliziert sein. Sie muss nur als natürlicher Teil der täglichen Entwicklungsarbeit verstanden und konsequent gelebt werden. Wer früh die richtigen Strukturen schafft, spart später viel Zeit, Geld und Nerven.

Wie schützt du deine Secrets aktuell und welche Tools haben sich für dich bewährt? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.