Notifications
Clear all
Topic starter
01/08/2026 10:49 pm
TL;DR: Code-based DSPM shifts attention from where sensitive data is stored to the code paths that create, move, log, and expose it, according to Aikido. That matters because traditional scanning can find exposed data, but it often leaves developers guessing which application change caused the risk and how to fix it.
NHIMG editorial — based on content published by Aikido: What developers need to know about DSPM and data exposure in code
By the numbers:
- Only 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams reduce data exposure in application code?
A: Start with the code paths that create exposure, not just the systems that store data.
Q: Why do storage scans miss some of the biggest data exposure risks?
A: Because many exposures happen before data reaches storage.
Q: What do teams get wrong about secrets management in pipelines and scripts?
A: They often treat the vault as the finish line.
Practitioner guidance
- Map sensitive data flows in code first Trace where PII, payment data, tokens, and AI context enter the application, where they are transformed, and which functions write them to logs, queues, or third-party services.
- Redact at the point of emission Remove or mask sensitive fields before logging, serialisation, prompt construction, or outbound API calls.
- Separate storage findings from application fixes Use storage scans to confirm where sensitive data landed, then route the remediation back to the service, controller, or workflow that created the exposure.
What's in the full article
Aikido's full guide covers the operational detail this post intentionally leaves for the source:
- Concrete examples of data exposure findings across logs, queues, SaaS tools, and AI workflows
- The Data Exposure Audit workflow used to connect code paths to sensitive-data movement
- Developer-focused remediation patterns such as redaction, response trimming, masking, and deletion fixes
- Implementation details for reviewing tokens, secrets, and customer data without connecting directly to datastores
👉 Read Aikido's guide to code-based DSPM and data exposure in code →
Code-based DSPM: what it means for AppSec and data governance?
Explore further
01/08/2026 10:58 pm
Code-based DSPM is really exposure-path governance, not just data discovery. The article correctly separates finding sensitive data from understanding how it was introduced into the environment. That distinction matters because modern applications move data through APIs, logs, queues, and AI prompts before storage teams ever see it. For AppSec and data security programmes, the governing question becomes which code path created the exposure and whether that path is still shipping risk into production.
A question worth separating out:
Q: How do you know if code-based DSPM is actually improving governance?
A: Look for fewer recurring exposure patterns, faster remediation of the exact code path, and a measurable reduction in sensitive data copied into logs, queues, and AI prompts. If findings still require manual hunting to locate the offending service, the programme is not yet operationally mature.
👉 Read our full editorial: Code-based DSPM closes the gap between data storage and exposure
