Drei überraschende Fälle von Secrets Exposure und wie man sie vermeidet

10. September 2025 – Unternehmen konzentrieren sich bei der Bekämpfung der Secrets Exposure auf die Repositories ihrer Anwendungen und ihre CI/CD-Pipelines. Doch die Gefahr lauert auch an anderen Stellen. Cycode, der Pionier im Bereich Application Security Posture Management (ASPM), schildert drei reale Fälle, bei denen sich die offengelegten Secrets nicht im Quellcode versteckten.

Bei der Anwendungsentwicklung geht es nicht ohne sogenannte Secrets. Neben herkömmlichen Zugangsdaten wie Passwörtern und Benutzernamen für Datenbanken gibt es sie auch in Form von API-Keys, Zertifikaten, Tokens, IDs oder URLs. In der Regel schleichen sie sich aus Bequemlichkeit in den Quellcode einer Applikation ein, weil Entwickler ihr den Zugang etwa zu einer Datenbank oder einem Cloud-Service ohne komplizierte Sicherheitsmaßnahmen geben möchten. Vergessen sie dann, diese sensiblen Informationen beim Einchecken in das Live-Repository wieder aus dem Quellcode zu entfernen, ist die Secrets Exposure perfekt. Ähnliche Szenarien sind über die gesamte CI/CD-Pipeline möglich – vom Source Code Management über Build- und Testing-Umgebungen bis hin zum Deployment. Doch Secrets Exposure droht auch weit jenseits von Code-Repositories, wie die folgenden drei Szenarien zeigen:

Risikovorfall #1: AWS-Zugangsdaten in Slack

Als das Cybersecurity-Team eines Fintech-Startups entdeckte, dass Hacker die Cloud-Umgebung des Unternehmens kompromittiert hatten, gingen sie sofort auf die Suche nach der Ursache. Die fanden sie allerdings nicht im Quellcode einer Anwendung, sondern in der Kommunikationsplattform Slack: Ein Entwickler hatte die Zugangsdaten zu AWS in einem privaten Channel gepostet. Dieser hatte unglücklicherweise eine Webhook-Integration, die Nachrichten über einen externen Service protokollierte. So kam es, dass dieses Secret auch für unbefugte Dritte offengelegt wurde.

Risikovorfall #2: Hartkodierte Secrets in Jira

Das Engineering-Team eines SaaS-Unternehmens nutzte Jira zum Tracking von Bugs und Problemen in der IT-Infrastruktur. Bei der Bearbeitung eines Incident hängte ein Entwickler eine Konfigurationsdatei an ein Ticket. An sich nichts Ungewöhnliches, sie enthielt allerdings einen sogenannten Database Connecting String – eine Zeichenkette mit sensiblen Zugangsdaten für die Verbindung der Anwendung zur Datenbank. Da Jira solche Dateien sehr lange vorhält und praktisch jeder im Unternehmen Zugriff auf das Ticketsystem hatte, lagen diese sensiblen Informationen monatelang offen. Die Konfigurationsdatei wurde erst bei einer standardmäßigen Sicherheitsübung entdeckt.

Risikovorfall #3: API-Keys in Microsoft Teams

Ein Anbieter von Enterprise-Software integrierte Microsoft Teams mit verschiedenen DevOps-Tools, um automatisierte Benachrichtigungen über Deployments zu erhalten. Die Entwickler des Unternehmens posteten gelegentlich API-Keys in Teams-Nachrichten, um fehlerhafte Builds zu analysieren. Da Microsoft Teams Logs von Nachrichten unbegrenzt speichert und keine native Scanning-Funktion zum Auffinden von Secrets beinhaltet, lagen diese Zugangsdaten de facto im Klartext ab und waren für jeden mit Zugriff auf die Chat-Historie frei verfügbar.

Holistische Secrets Detection ist ein Muss

Diese Fälle von Secrets Exposure zeigen, dass Unternehmen, die Anwendungen entwickeln, unbedingt elaborierte Secrets-Scanner benötigen. Eine ganzheitliche Application Security Platform (ASP) durchsucht nicht nur den Quellcode oder die unterschiedlichen Tools einer CI/CD-Pipeline nach möglichen Exposures, sondern findet Secrets zuverlässig in sämtlichen Bereichen eines Unternehmens. Gute Plattformen bieten KI-basierte Secrets Scanner, die nicht nur nach regelbasierten Methoden arbeiten oder via regulären Ausdrücken (RegEx) nach Secrets suchen, sondern speziell auf das Auffinden von Secrets trainiert sind. Das ist insofern wichtig, da RegEx-Muster und regelbasierte Scanner zwar klassische Secrets wie API-Keys oder Tokens erkennen können. Bei generischen Secrets, die keinen festen Regeln folgen und auch außerhalb eines Quellcodes vorkommen, sind sie allerdings oft wirkungslos oder gar kontraproduktiv. Die Folge sind in vielen Fällen eine hohe Anzahl False Positives, die den Entwicklern und Cybersecurity-Teams Zeit für wertschöpfende Aufgaben stehlen.

Eine ASP mit exzellenter Secrets Detection weitet den Suchbereich über Repositories hinaus auf Non-Code-Tools wie Slack, Microsoft Teams, Jira, Confluence und Co. aus. Sie scannt Nachrichten und Dateien, die Entwickler über diese Tools teilen, in Echtzeit und markiert sie unmittelbar, sodass die Verantwortlichen ohne Zeitverlust handeln können. Überdies gibt eine fortschrittliche ASP zu jeder gefundenen Sicherheitsverletzung einen vollständigen Kontext, inklusive exaktem Speicherort des Secrets, dem Autor und weiteren Metadaten, was den Aufwand zur Behebung der Exposure maßgeblich verkürzt.

„Unternehmen müssen sich im Klaren darüber sein, dass nicht nur Anwendungen selbst anfällig für die Secrets Exposure sind“, warnt Jochen Koehler, Vice President of EMEA Sales bei Cycode. „Durch die immer größere Tool-Landschaft und die extensive Nutzung von Kollaborations-Apps lauert die Gefahr einer Offenlegung sensibler Daten quasi überall. Daher benötigen sie eine intelligente Lösung, die sämtliche, innerhalb des Software Development Lifecycles eingesetzte Applikationen durchforstet. Nur so bleiben Geheimnisse auch wirklich geheim.“

Dieses Listicle und Bildmaterial in höherer Auflösung können unter www.pr-com.de/companies/cycode abgerufen werden.