Zurück zur Startseite

The Regulatory Framework for Code Secret Leakage

Published April 6, 2026 · Reading time approx. 5 minutes

Dr. Alexander Krause
Dr. Alexander Krause IT Security Consultant & Researcher at CISPA Helmholtz Center for Information Security

An API key slips into a Git repository. Happens all the time, most people think. It's just a test key. Three years later, an auditor reviews the compliance documentation — and that harmless accident turns into a real problem. The article "Der regulatorische Rahmen für Code Secret Leakage" (Krause & Krause, DuD 2026) systematically examines which legal obligations apply when code secrets leak and how to translate often abstract regulatory requirements into concrete technical measures.

Code Secrets: More Than Just Passwords

API keys, auth tokens, cryptographic keys, service passwords, CI/CD credentials — these are all code secrets. They connect software components to third-party services like databases, cloud storage, or analytics platforms. What they share: they need to be available at runtime in program code.

That's exactly what makes them vulnerable. If you need a secret to run code, you're tempted to hardcode it. The OWASP Top 10 list hardcoded credentials under #2 ("Cryptographic Failures"). Version control systems like Git, sharing platforms like GitHub Gists or Pastebin do the rest: a single careless commit is enough.

Consequences range from trivial to catastrophic. Read access to telemetry data? Annoying. Full access to production systems? Business-ending.

Why Is Code Secret Leakage a GDPR Problem?

The GDPR requires controllers to adequately protect personal data (Art. 32). Technical and organizational measures are mandatory, and the standard is risk-based. Nothing new here.

The real difficulty with code secret leakage: it's an abstract, indirect risk. A leaked API key doesn't contain personal data. But it can open access to systems that process such data. Mapping this connection in threat modeling is the first step — and exactly where many organizations fail.

Art. 32 demands measures reflecting the "state of the art." That doesn't mean the latest technology but rather known, proven, and commercially available methods. Secret vaults and pre-commit scanners clearly fall into this category. If you don't use them, you'd better have a good reason documented.

Privacy by Design (Art. 25) only applies to controllers, not to processors or manufacturers. That's a gap the Cyber Resilience Act partially closes. Regarding liability, Art. 82 kicks in: controllers and processors are jointly liable. A secret leak at your service provider becomes your problem too.

Cyber Resilience Act: Putting Manufacturers on the Hook

The CRA targets products with digital elements and primarily addresses manufacturers. Its scope is limited though: it only applies when software is part of a marketed product with functional dependency. SaaS is excluded. Internal-only software too.

Still worth engaging with. Companies implementing CRA requirements for their products often improve security in areas the CRA doesn't directly cover. Spillover effects, if you will.

NIS-2: Supply Chain in the Spotlight

The NIS-2 Directive applies to public and private entities in critical sectors, medium-sized enterprises and up. It demands a risk-based approach with an "all-hazards" perspective.

In practice: security in development and maintenance, effectiveness assessments, training, crypto concepts, access controls. The real innovation is mandatory supply chain security consideration. Companies must account for the "overall quality of products and cybersecurity practice of suppliers." A supplier that can't manage its secrets becomes a compliance risk for the contracting party.

What Do ISO 27001 and OWASP Actually Require?

ISO 27001 gets explicit in two places: A.8.25 ("Secure development lifecycle") requires code scans and repository configuration. A.8.28 ("Secure coding") explicitly forbids hardcoded secrets. If you're ISO 27001 certified and still have secrets in your code, you have an audit problem.

The TeleTrusT handbook on the state of the art addresses unintentional source code disclosure but stays vague on implementation. OWASP ASVS V.1.6 delivers more concrete requirements: architectural crypto specifications and a documented key management policy.

Technical and Organizational Measures

The article rates protective measures by effectiveness — from (+) to (+++):

  • Externalize secrets (+++): Secret vaults and environment variables instead of hardcoded values. Requires upfront investment in personnel, licenses, and infrastructure.
  • Block secrets (+++): No hardcoded secrets in code, proper .gitignore configuration.
  • Monitoring (+/++): Secret scanners at various stages — IDE plugin, pre-commit hook, push hook, or server-side. Most effective when developers see them in their IDE from day one.
  • Encryption (+++): Encrypt secrets shared via repositories. Store the decryption key externally.
  • Rotation (++): Regularly invalidate and reissue secrets. Short-lived secrets minimize post-leak risk.
  • Training and awareness (+++): Continuous developer education. Extend coding conventions with security measures.
  • Access management (+/++): Enforce least privilege consistently. Consider the qualitative dimension too — managers often have higher permissions but less technical know-how.
  • Self-hosted infrastructure: Self-hosted GitLab prevents accidental publication on external platforms.

Where Do Measures Hit Their Limits?

Secret vaults work well but are complex to set up and maintain. Secret scanners produce high false-positive rates — developers disable them or ignore the warnings. External secret files can themselves become leaks if they're part of the codebase. A misconfigured .gitignore syncs secrets to the server instead of keeping them out.

And then there are cases where theory breaks down: provisioning scripts (Ansible, Vagrant) can't load secrets at runtime. They need them beforehand.

The core problem remains human. Lack of competence and convenience on the developer side, insufficient resource allocation from management. Most developers don't pay attention until after the first incident.

Conclusion: From Open Legal Text to Concrete Action

GDPR, NIS-2, CRA, and ISO 27001 deliberately keep their requirements abstract. The challenge for organizations is breaking these open-ended mandates down to the concrete risk of code secret leakage. The article provides a practical path: conduct risk analysis, clarify responsibilities, embed effective measures across development and operations.

The human factor remains the central challenge. And at the same time, the biggest lever.

Full publication: Krause & Krause, "Der regulatorische Rahmen für Code Secret Leakage — Perspektiven aus IT-Sicherheit und Compliance", DuD 50, pp. 103–108, 2026.

This article is an AI-generated summary of the scientific publication "Der regulatorische Rahmen für Code Secret Leakage" (DuD, 2026). The content has been editorially reviewed.

Want to make your software development legally compliant against secret leakage? Contact me for consulting on risk analysis, technical measures, and compliance documentation.