Der regulatorische Rahmen für Code Secret Leakage

Veröffentlicht am 6. April 2026 · Lesezeit ca. 5 Minuten

Ein API-Key rutscht in ein Git-Repository. Passiert ständig, denken viele. Ist ja nur ein Testschlüssel. Drei Jahre später prüft ein Auditor die Compliance-Dokumentation — und aus dem harmlosen Versehen wird ein handfestes Problem. Der Artikel „Der regulatorische Rahmen für Code Secret Leakage" (Krause & Krause, DuD 2026) arbeitet systematisch auf, welche rechtlichen Pflichten bei geleakten Code Secrets greifen und wie sich die oft abstrakten Anforderungen in konkrete technische Maßnahmen übersetzen lassen.

Code Secrets: Mehr als nur Passwörter

API-Keys, Auth-Tokens, kryptographische Schlüssel, Service-Passwörter, CI/CD-Zugangsdaten — all das sind Code Secrets. Sie verbinden Softwarekomponenten mit Drittdiensten wie Datenbanken, Cloud-Speichern oder Analytics-Plattformen. Gemeinsam ist ihnen: Sie müssen zur Laufzeit im Programmcode verfügbar sein.

Genau das macht sie anfällig. Wer ein Secret braucht, um Code auszuführen, ist versucht, es direkt in den Quellcode zu schreiben. Die OWASP Top 10 listen hartcodierte Credentials unter Platz 2 („Cryptographic Failures"). Versionskontrollsysteme wie Git, Sharing-Plattformen wie GitHub Gists oder Pastebin tun ihr Übriges: Ein einziger unachtsamer Commit genügt.

Die Folgen reichen von trivial bis katastrophal. Lesezugriff auf Telemetriedaten? Ärgerlich. Vollzugriff auf Produktivsysteme? Existenzbedrohend.

Warum ist Code Secret Leakage ein DSGVO-Problem?

Die DSGVO verlangt von Verantwortlichen, personenbezogene Daten angemessen zu schützen (Art. 32). Technische und organisatorische Maßnahmen sind Pflicht, der Maßstab ist risikobasiert. So weit, so bekannt.

Die eigentliche Schwierigkeit bei Code Secret Leakage: Es handelt sich um ein abstraktes, indirektes Risiko. Ein geleakter API-Key enthält keine personenbezogenen Daten. Aber er kann den Zugang zu Systemen öffnen, die solche Daten verarbeiten. Diesen Zusammenhang im Threat Modeling abzubilden, ist der erste Schritt — und genau hier scheitern viele Organisationen.

Art. 32 fordert Maßnahmen nach dem „Stand der Technik". Das meint nicht die neueste Technologie, sondern bekannte, erprobte und am Markt verfügbare Verfahren. Secret Vaults und Pre-Commit-Scanner fallen klar in diese Kategorie. Wer sie nicht einsetzt, muss das begründen können.

Privacy by Design (Art. 25) richtet sich nur an Verantwortliche, nicht an Auftragsverarbeiter oder Hersteller. Das ist eine Lücke, die der Cyber Resilience Act teilweise schließt. Bei der Haftung greift Art. 82: Verantwortliche und Auftragsverarbeiter haften gesamtschuldnerisch. Ein Secret Leak beim Dienstleister wird damit auch zum Problem des Auftraggebers.

Cyber Resilience Act: Hersteller in der Pflicht

Der CRA zielt auf Produkte mit digitalen Elementen und adressiert primär Hersteller. Sein Anwendungsbereich ist allerdings begrenzt: Er greift nur, wenn Software Teil eines vermarkteten Produkts mit funktionaler Abhängigkeit ist. SaaS fällt nicht darunter. Rein intern genutzte Software ebenso wenig.

Trotzdem lohnt sich die Auseinandersetzung. Unternehmen, die CRA-Anforderungen für ihre Produkte umsetzen, verbessern oft auch die Sicherheit in Bereichen, die der CRA gar nicht direkt erfasst. Spillover-Effekte, wenn man so will.

NIS-2: Lieferkette im Fokus

Die NIS-2-Richtlinie betrifft öffentliche und private Einrichtungen in kritischen Sektoren ab mittlerer Unternehmensgröße. Sie verlangt einen risikobasierten Ansatz mit „All-Hazards"-Perspektive.

Konkret heißt das: Sicherheit in Entwicklung und Wartung, Wirksamkeitsbewertungen, Schulungen, Kryptokonzepte, Zugangskontrollen. Die eigentliche Neuerung liegt in der verpflichtenden Betrachtung der Lieferkettensicherheit. Unternehmen müssen die „Gesamtqualität der Produkte und Cybersicherheitspraxis der Zulieferer" berücksichtigen. Ein Zulieferer, der seine Secrets nicht im Griff hat, wird damit zum Compliance-Risiko für den Auftraggeber.

Was fordern ISO 27001 und OWASP konkret?

Die ISO 27001 wird an zwei Stellen explizit: A.8.25 („Secure development lifecycle") verlangt Code-Scans und Repository-Konfiguration. A.8.28 („Secure coding") verbietet hartcodierte Secrets ausdrücklich. Wer ISO-27001-zertifiziert ist und trotzdem Secrets im Code hat, hat ein Audit-Problem.

Das TeleTrusT-Handbuch zum Stand der Technik adressiert die unbeabsichtigte Offenlegung von Quellcode, bleibt aber vage in der Umsetzung. Der OWASP ASVS liefert mit V.1.6 konkretere Vorgaben: architektonische Kryptoanforderungen und eine dokumentierte Key-Management-Policy.

Technische und organisatorische Maßnahmen

Der Artikel bewertet verschiedene Schutzmaßnahmen nach ihrer Wirksamkeit — von (+) bis (+++):

• Secrets externalisieren (+++): Secret Vaults und Umgebungsvariablen statt hartcodierter Werte. Erfordert initiale Investitionen in Personal, Lizenzen und Infrastruktur.
• Secrets blockieren (+++): Keine hartcodierten Secrets im Code, saubere .gitignore-Konfiguration.
• Monitoring (+/++): Secret-Scanner in verschiedenen Stufen — als IDE-Plugin, Pre-Commit-Hook, Push-Hook oder serverseitig. Am wirksamsten, wenn Entwickler sie von Anfang an in der IDE sehen.
• Verschlüsselung (+++): Secrets, die über Repositories geteilt werden, verschlüsseln. Den Entschlüsselungskey extern lagern.
• Rotation (++): Secrets regelmäßig invalidieren und neu ausstellen. Kurzlebige Secrets minimieren das Risiko nach einem Leak.
• Schulung und Awareness (+++): Kontinuierliche Entwicklerschulung. Coding-Conventions um Sicherheitsmaßnahmen erweitern.
• Zugriffsmanagement (+/++): Least Privilege konsequent umsetzen. Auch die qualitative Dimension berücksichtigen — Führungskräfte haben oft höhere Berechtigungen, aber weniger technisches Know-how.
• Self-hosted Infrastruktur: Selbst gehostetes GitLab verhindert die versehentliche Veröffentlichung auf externen Plattformen.

Wo stoßen die Maßnahmen an ihre Grenzen?

Secret Vaults sind wirksam, aber aufwändig in Einrichtung und Betrieb. Secret-Scanner produzieren hohe False-Positive-Raten — Entwickler deaktivieren sie oder ignorieren die Warnungen. Externe Secret-Dateien können selbst zum Leak werden, wenn sie Teil der Codebase sind. Eine fehlkonfigurierte .gitignore synchronisiert Geheimnisse auf den Server statt sie zurückzuhalten.

Und dann gibt es Fälle, in denen die Theorie nicht greift: Provisionierungsscripte (Ansible, Vagrant) können Secrets nicht erst zur Laufzeit nachladen. Sie brauchen sie vorher.

Das Kernproblem bleibt menschlich. Fehlende Kompetenz und Bequemlichkeit auf Entwicklerseite, unzureichende Ressourcenbereitstellung durch das Management. Die meisten Entwickler werden erst nach dem ersten Vorfall aufmerksam.

Fazit: Vom offenen Normtext zur konkreten Maßnahme

DSGVO, NIS-2, CRA und ISO 27001 formulieren ihre Anforderungen bewusst abstrakt. Für Unternehmen besteht die Herausforderung darin, diese offenen Vorgaben auf das konkrete Risiko Code Secret Leakage herunterzubrechen. Der Artikel liefert dafür einen praktischen Pfad: Risikoanalyse durchführen, Verantwortlichkeiten klären, wirksame Maßnahmen in Entwicklung und Betrieb verankern.

Der menschliche Faktor bleibt die zentrale Herausforderung — und der größte Hebel.

Die vollständige Publikation: Krause & Krause, „Der regulatorische Rahmen für Code Secret Leakage — Perspektiven aus IT-Sicherheit und Compliance", DuD 50, S. 103–108, 2026.

Dieser Artikel ist eine KI-generierte Zusammenfassung der wissenschaftlichen Publikation „Der regulatorische Rahmen für Code Secret Leakage" (DuD, 2026). Die Inhalte wurden redaktionell geprüft.

Sie möchten Ihre Softwareentwicklung rechtssicher gegen Secret Leakage absichern? Kontaktieren Sie mich für eine Beratung — von der Risikoanalyse über technische Maßnahmen bis zur Compliance-Dokumentation.