# What is DSPM and how does it work? > Source: > Published: 2026-07-20 16:15:00+00:00 DSPM exists because sensitive data doesn’t sit still anymore. Beyond the database, sensitive data is in logs, queues, SaaS tools, support systems, analytics pipelines, data warehouses, backups, and now AI prompts and vector stores. It moves because the application moves it. A customer’s email address might start in a signup form, pass through an API, be written to Postgres, show up in an application log, be copied into Snowflake, flow into a support tool, be sent to Stripe, and then maybe be pulled into an AI workflow later. And this is considered a pretty normal workflow. So when people talk about DSPM, or Data Security Posture Management, the basic idea is pretty straightforward. Help teams understand where sensitive data is, what kind of data it is, who or what can access it, how it’s protected, and where it may be exposed. Most companies don’t have a perfect map of where sensitive data lives. They know they have customer data, payment details, tokens, employee data, and now all sorts of AI context. What they don’t always know is where all of that data has ended up, who can touch it, or whether it’s being handled in a way that matches their security and compliance expectations. Visibility is the problem traditional DSPM is trying to solve. ## Traditional DSPM starts where the data landed Traditional DSPM mostly starts with the data estate. That usually means scanning storage systems and connected platforms. S3 buckets, databases, data warehouses, SaaS apps, and backups. The tool looks for sensitive data, classifies it, checks permissions and exposure, and helps the security team prioritize what matters. It might tell you an S3 bucket contains PII. Or that a warehouse table has payment-related data. Or that a file share is too broadly accessible. Or that a backup has production customer records sitting in a place nobody has looked at in a year. That’s obviously useful. There’s a lot of sensitive data floating around in modern environments, and much of it is copied, replicated, exported, logged, synced, archived, and forgotten. Traditional DSPM helps teams find that. It gives the security team a better view of the actual data estate beyond just the cloud resources around it. But for developers and AppSec teams, that’s often the second half of the story. The first half is how the data got there. ## The missing question is the code path A traditional DSPM tool might say, “PII was found in this log store.” But the developer still has to figure out why the PII is there, what part of the application wrote it, whether it was intentional, and what change would actually fix it. And you need to look at the code for this. The application collected the data, processed it, and decided which fields to return from an API. It then logged the request body, passed a token to a worker, sent customer metadata to a vendor, and built the prompt that included sensitive context. So the more developer-native question should go beyond, “Where is sensitive data stored?” and be more like, “What code path created the exposure?” That’s the shift-left version of DSPM. Code-based DSPM starts with the application instead of the storage layer. It looks at APIs, ORM models, logging calls, queue consumers, CI/CD workflows, AI integrations, and more. The goal is to understand how sensitive data enters the system, how it moves, where it’s stored, where it leaves, and where it may be mishandled. ## Code-based DSPM and Data Exposure Audits At Aikido, I think the clearest way to describe our [code-based DSPM](https://www.aikido.dev/code/dspm) this is a **Data Exposure Audit**, which is to use AI to find sensitive data flows and security risks in code. A Data Exposure Audit is different. It looks at the code and asks how sensitive data flows through this application and where that flow creates risk. It covers PII, PHI, PCI, secrets, tokens, customer content, and AI-related data handling. Each result comes with evidence and a remediation in code without needing to connect directly to the datastores. Reading the code can also find weak data protection. It can flag a sensitive field stored without encryption, a hardcoded key in source, MD5 or SHA1 or base64 used as if it were encryption, a secret committed to the repo, and sensitive data sent over an insecure channel. There's another way to frame this. Traditional DSPM needs access to your actual data, connecting to S3 buckets, databases, and data warehouses to scan what's inside them. Code based DSPM reads the code that creates and moves that data instead, so it never requests access or downloads anything. Reading from code lowers the barrier to turning it on, since there's no new production access to grant. That also makes it faster, since there's nothing to crawl. It's more accurate too, since it's reading how a field gets used rather than assuming any nine-digit number is a Social Security number. The output is a map of where sensitive data lives in your architecture and how it's protected, built entirely from the code. In Aikido, this runs as part of the [AI Code Analysis](https://www.aikido.dev/code/code-audit), so the Data Exposure Audit sits alongside the rest of the code review rather than as a separate data-access integration ## How the quality of the findings differs Take logging as a simple example. A traditional DSPM product might eventually tell you that PII exists in application logs. Again, useful. But now somebody has to go hunt for the source. A code-based Data Exposure Audit can tell a more complete story by connecting the data, the code path, the destination, the exposure risk, and the fix. This makes it more useful for developers. For example, the checkout controller logs the full billingDetails object when payment authorization fails. That object includes email, phone number, billing address, and card last four digits. The logs are shipped to Datadog. The fix is to redact those fields before logging and keep only the customer ID, payment intent ID, and error code. That’s very different information than what you get from a traditional DSPM. The same thing applies to secrets and tokens. Take an SCM token used to read code from GitHub, GitLab, or Bitbucket. A storage-oriented view might ask whether the token is encrypted in the database. This isn't the whole story, though. Where does the token enter the platform? Is it an OAuth token, a GitHub App token, or a user-submitted PAT? What scopes does it have? How is it validated? Where is it encrypted? Where is it stored? When is it decrypted? Is it cached? Is it embedded in a clone URL? Is it passed to a worker? Could it leak through logs, traces, errors, process arguments, or telemetry? It’s a data security problem, but the code tells us what we need to know about its movement. **From dashboard to fix** This is where I think code-based DSPM gets interesting. The best version of this isn’t another dashboard that says, “You have sensitive data.” Everyone knows that. The better experience says, here’s the sensitive data inventory, here’s the flow, here’s the exposure risk, here are the relevant controls, and here’s the code change that reduces the risk. **If the code created the exposure, the fix probably belongs in the code.** The typical developer workflow should therefore be: - Redact sensitive fields before logging. - Return a smaller API response object. - Add a tenant ownership check. - Stop passing tokens in URLs. - Mask production data before restoring it into staging. - Add encryption before storage. - Remove customer data from an LLM prompt. - Fix deletion logic so downstream records are actually removed. The engineer wants to know which specific code path creates a specific data exposure risk and how to fix it. This also makes the connection to security and compliance frameworks much more concrete. If a token is mishandled, that may matter for authenticator management, transmission protection, least privilege, and audit log protection. If PII is logged without redaction, that may matter for privacy, retention, data minimization, and monitoring controls. If customer data is copied into staging without masking, that may affect access control, environment separation, and compliance obligations. If records survive a delete request, or data lives past its retention window, that ties directly to GDPR and CCPA obligations, and that needs to be fixed in deletion and retention logic itself. The finding that just says “Unsafe logging pattern” is pretty limited in its utility. But something like, “Customer PII flows into logs through this code path creates a data exposure risk, affects these controls, and can be fixed by redacting these fields before logging,” is actionable. That’s a much better way to bring engineering, AppSec, and compliance into the same conversation. ## The simple version Traditional DSPM is still important. It helps teams understand where sensitive data lives in the real environment. It can find forgotten buckets, exposed databases, shadow data, and over-permissioned stores. But code-based DSPM adds the missing application layer. It helps explain how sensitive data gets there, how it moves, where the exposure mechanism lives, and what developers can do about it. So the simple version looks like: **Traditional DSPM finds sensitive data where it lives.** **Code-based DSPM finds how sensitive data gets exposed.** **A Data Exposure Audit connects that flow back to the code, the control gap, and the fix.** That’s the shift-left version of DSPM. And for developers and AppSec teams, it’s probably the version that helps teams the most. Aikido offers the [first of its kind in code-based DSPM. ](https://www.aikido.dev/code/dspm) Protect and track your data, without even connecting your databases.