DSPM existiert, weil sensible Daten nicht mehr stillstehen.
Jenseits der Datenbank befinden sich sensible Daten in Logs, Queues, SaaS-Tools, Support-Systemen, Analyse-Pipelines, Data Warehouses, Backups und jetzt auch in AI-Prompts und Vector Stores. Sie bewegen sich, weil die Anwendung sie bewegt. Eine E-Mail-Adresse eines Kunden könnte in einem Anmeldeformular beginnen, über eine API geleitet, in Postgres geschrieben, in einem Anwendungs-Log erscheinen, in Snowflake kopiert, in ein Support-Tool fließen, an Stripe gesendet und später vielleicht in einen AI-Workflow integriert werden. Und dies gilt als ein ziemlich normaler Workflow.
Wenn also von DSPM oder Data Security Posture Management die Rede ist, ist die Grundidee ziemlich einfach: Teams dabei helfen zu verstehen, wo sich sensible Daten befinden, um welche Art von Daten es sich handelt, wer oder was darauf zugreifen kann, wie sie geschützt sind und wo sie möglicherweise exponiert sind.
Die meisten Unternehmen haben keine perfekte Übersicht darüber, wo sich sensible Daten befinden. Sie wissen, dass sie Kundendaten, Zahlungsdetails, Tokens, Mitarbeiterdaten und jetzt alle Arten von AI-Kontext haben. Was sie nicht immer wissen, ist, wo all diese Daten gelandet sind, wer darauf zugreifen kann oder ob sie so gehandhabt werden, dass es ihren Sicherheits- und Compliance-Erwartungen entspricht.
Sichtbarkeit ist das Problem, das traditionelles DSPM zu lösen versucht.
Traditionelles DSPM beginnt dort, wo die Daten gelandet sind.
Traditionelles DSPM beginnt meistens mit dem Datenbestand. Das bedeutet in der Regel das Scannen von Speichersystemen und verbundenen Plattformen: S3-Buckets, Datenbanken, Data Warehouses, SaaS-Anwendungen und Backups.
Das Tool sucht nach sensiblen Daten, klassifiziert sie, prüft Berechtigungen und Offenlegung und hilft dem Sicherheitsteam, Prioritäten zu setzen. Es könnte Ihnen mitteilen, dass ein S3-Bucket PII enthält. Oder dass eine Warehouse-Tabelle zahlungsbezogene Daten hat. Oder dass eine Dateifreigabe zu breit zugänglich ist. Oder dass ein Backup Produktionskundendaten an einem Ort enthält, den seit einem Jahr niemand mehr angesehen hat.
Das ist offensichtlich nützlich. In modernen Umgebungen sind viele sensible Daten im Umlauf, und ein Großteil davon wird kopiert, repliziert, exportiert, protokolliert, synchronisiert, archiviert und vergessen. Traditionelles DSPM hilft Teams, dies zu finden. Es verschafft dem Sicherheitsteam einen besseren Überblick über den tatsächlichen Datenbestand, der über die umgebenden Cloud-Ressourcen hinausgeht.
Aber für Entwickelnde und AppSec-Teams ist das oft die zweite Hälfte der Geschichte.
Die erste Hälfte ist, wie die Daten dorthin gelangten.
Die fehlende Frage ist der Codepfad
Ein traditionelles DSPM-Tool könnte sagen: „PII wurde in diesem Log-Store gefunden.“
Aber die Entwickelnden müssen immer noch herausfinden, warum die PII dort ist, welcher Teil der Anwendung sie geschrieben hat, ob es beabsichtigt war und welche Änderung es tatsächlich beheben würde. Und dafür muss man den Code ansehen.
Die Anwendung sammelte die Daten, verarbeitete sie und entschied, welche Felder von einer API zurückgegeben werden sollten. Sie protokollierte dann den Request Body, übergab ein Token an einen Worker, sendete Kundenmetadaten an einen Anbieter und erstellte den Prompt, der sensiblen Kontext enthielt.
Die entwickelnden-nähere Frage sollte also über „Wo werden sensible Daten gespeichert?“ hinausgehen und eher lauten: „Welcher Codepfad hat die Offenlegung verursacht?“ Das ist die Shift-Left-Version von DSPM.
Code-basiertes DSPM beginnt mit der Anwendung anstatt mit der Speicherschicht. Es betrachtet APIs, ORM-Modelle, Logging-Aufrufe, Queue-Consumer, CI/CD-Workflows, AI-Integrationen und mehr. Ziel ist es zu verstehen, wie sensible Daten in das System gelangen, wie sie sich bewegen, wo sie gespeichert werden, wo sie das System verlassen und wo sie möglicherweise falsch gehandhabt werden.
Code-basiertes DSPM und Data Exposure Audits
Bei Aikido ist die klarste Art, unser code-basiertes DSPM zu beschreiben, es als Data Exposure Audit zu betrachten, was bedeutet, KI einzusetzen, um sensible Datenflüsse und Sicherheitsrisiken im Code zu finden.
Ein Data Exposure Audit deckt PII, PHI, PCI, Secrets, Tokens, Kundeninhalte und KI-bezogene Datenverarbeitung ab. Jedes Ergebnis enthält Nachweise und eine Behebung im Code, ohne direkte Verbindung zu den Datenspeichern.
Das Lesen des Codes kann auch schwachen Datenschutz aufdecken. Es kann ein sensibles Feld kennzeichnen, das unverschlüsselt gespeichert ist, einen hartcodierten Schlüssel im Quellcode, MD5, SHA1 oder Base64, die als Verschlüsselung verwendet werden, ein im Repo committetes Secret und sensible Daten, die über einen unsicheren Kanal gesendet werden.
Man kann dies auch anders betrachten. Traditionelles DSPM benötigt Zugriff auf Ihre tatsächlichen Daten und verbindet sich mit S3-Buckets, Datenbanken und Data Warehouses, um deren Inhalte zu scannen. Code-basiertes DSPM liest stattdessen den Code, der diese Daten erstellt und bewegt, sodass es niemals Zugriff anfordert oder etwas herunterlädt. Das Lesen aus dem Code senkt die Hürde für die Aktivierung, da kein neuer Produktionszugriff gewährt werden muss.
Das macht es auch schneller, da nichts gecrawlt werden muss. Es ist auch genauer, da es liest, wie ein Feld verwendet wird, anstatt anzunehmen, dass jede neunstellig Zahl eine Sozialversicherungsnummer ist. Das Ergebnis ist eine Karte, die zeigt, wo sensible Daten in Ihrer Architektur liegen und wie sie geschützt sind, vollständig aus dem Code erstellt.
In Aikido läuft dies als Teil der KI-Codeanalyse, sodass das Data Exposure Audit neben der restlichen Code-Überprüfung stattfindet und nicht als separate Datenzugriffs-Integration.
Wie sich die Qualität der Ergebnisse unterscheidet
Nehmen wir Logging als einfaches Beispiel.
Ein traditionelles DSPM-Produkt könnte Ihnen irgendwann mitteilen, dass PII in Anwendungs-Logs existiert. Auch das ist nützlich. Aber jetzt muss jemand die Quelle suchen.
Ein Code-basiertes Data Exposure Audit kann eine vollständigere Geschichte erzählen, indem es die Daten, den Codepfad, das Ziel, das Expositionsrisiko und die Behebung miteinander verbindet. Dies macht es für Entwickelnde nützlicher.
Zum Beispiel protokolliert der Checkout-Controller das vollständige billingDetails-Objekt, wenn die Zahlungsautorisierung fehlschlägt. Dieses Objekt enthält E-Mail, Telefonnummer, Rechnungsadresse und die letzten vier Ziffern der Karte. Die Logs werden an Datadog gesendet. Die Behebung besteht darin, diese Felder vor dem Logging zu redigieren und nur die Kunden-ID, die Zahlungsabsichts-ID und den Fehlercode beizubehalten.
Das sind sehr unterschiedliche Informationen im Vergleich zu dem, was Sie von einem traditionellen DSPM erhalten.
Dasselbe gilt für Secrets und Tokens. Nehmen wir ein SCM-Token, das zum Lesen von Code von GitHub, GitLab oder Bitbucket verwendet wird. Eine speicherorientierte Ansicht könnte fragen, ob das Token in der Datenbank verschlüsselt ist. Das ist jedoch nicht die ganze Geschichte.
Wo gelangt das Token in die Plattform? Ist es ein OAuth-Token, ein GitHub App-Token oder ein vom Benutzer übermitteltes PAT? Welche Scopes hat es? Wie wird es validiert? Wo wird es verschlüsselt? Wo wird es gespeichert? Wann wird es entschlüsselt? Wird es gecacht? Ist es in einer Clone-URL eingebettet? Wird es an einen Worker übergeben? Könnte es über Logs, Traces, Fehler, Prozessargumente oder Telemetrie lecken? Es ist ein Datensicherheitsproblem, aber der Code verrät uns, was wir über seine Bewegung wissen müssen.
Vom Dashboard zur Behebung
Hier wird Code-basiertes DSPM meiner Meinung nach interessant.
Die beste Version davon ist nicht ein weiteres Dashboard, das sagt: „Sie haben sensible Daten.“ Das weiß jeder. Die bessere Erfahrung besagt: Hier ist das Inventar sensibler Daten, hier ist der Fluss, hier ist das Expositionsrisiko, hier sind die relevanten Kontrollen und hier ist die Code-Änderung, die das Risiko reduziert.
Wenn der Code die Exposition verursacht hat, gehört die Behebung wahrscheinlich in den Code.
Der typische Workflow für Entwickelnde sollte daher sein:
- Sensible Felder vor dem Logging redigieren.
- Ein kleineres API-Antwortobjekt zurückgeben.
- Eine Tenant-Eigentumsprüfung hinzufügen.
- Tokens nicht mehr in URLs übergeben.
- Produktionsdaten maskieren, bevor sie in Staging wiederhergestellt werden.
- Verschlüsselung vor der Speicherung hinzufügen.
- Kundendaten aus einem LLM-Prompt entfernen.
- Löschlogik korrigieren, damit nachgelagerte Datensätze tatsächlich entfernt werden.
Die Entwickelnde möchte wissen, welcher spezifische Codepfad ein bestimmtes Datenexpositionsrisiko erzeugt und wie es behoben werden kann.
Dies macht auch die Verbindung zu Sicherheits- und Compliance-Frameworks wesentlich konkreter. Wird ein Token falsch gehandhabt, kann dies für die Authentifikatorverwaltung, den Übertragungsschutz, das Prinzip der geringsten Rechte und den Schutz von Audit-Logs relevant sein. Werden PII ohne Schwärzung protokolliert, kann dies für Datenschutz, Aufbewahrung, Datenminimierung und Überwachungskontrollen relevant sein. Werden Kundendaten ohne Maskierung in Staging kopiert, kann dies Zugriffssteuerung, Umgebungsseparation und Compliance-Verpflichtungen beeinträchtigen. Wenn Datensätze eine Löschanforderung überleben oder Daten über ihr Aufbewahrungsfenster hinaus existieren, ist dies direkt mit GDPR- und CCPA-Verpflichtungen verbunden und muss in der Lösch- und Aufbewahrungslogik selbst behoben werden.
Der Befund, der lediglich „Unsicheres Logging-Muster“ besagt, ist in seinem Nutzen ziemlich begrenzt. Aber etwas wie „Kunden-PII fließen über diesen Codepfad in Logs, was ein Datenexpositionsrisiko schafft, diese Kontrollen beeinträchtigt und durch Schwärzung dieser Felder vor dem Logging behoben werden kann“, ist umsetzbar.
Das ist ein wesentlich besserer Weg, Engineering, AppSec und Compliance in dasselbe Gespräch zu bringen.
Die einfache Version
Traditionelles DSPM ist immer noch wichtig. Es hilft Teams zu verstehen, wo sich sensible Daten in der realen Umgebung befinden. Es kann vergessene Buckets, exponierte Datenbanken, Shadow Data und überprivilegierte Speicher finden.
Aber codebasiertes DSPM ergänzt die fehlende Anwendungsebene. Es hilft zu erklären, wie sensible Daten dorthin gelangen, wie sie sich bewegen, wo der Expositionsmechanismus liegt und was Entwickelnde dagegen tun können.
Die einfache Version sieht also wie folgt aus:
Traditionelles DSPM findet sensible Daten dort, wo sie sich befinden.
Codebasiertes DSPM findet heraus, wie sensible Daten exponiert werden.
Ein Data Exposure Audit verbindet diesen Fluss zurück zum Code, zur Kontrolllücke und zur Behebung.
Das ist die Shift-Left-Version von DSPM. Und für Entwickelnde und AppSec-Teams ist es wahrscheinlich die Version, die Teams am meisten hilft.
Aikido bietet das erste seiner Art im codebasierten DSPM. Schützen und verfolgen Sie Ihre Daten, ohne Ihre Datenbanken verbinden zu müssen.
