Tim Ayling | VP of Cyber Security Solutions EMEA
More About This Author >
Tim Ayling | VP of Cyber Security Solutions EMEA
More About This Author >
What we all know is that developers ship features. What we may not realize is that they also ship exposures.
Application security has found itself squarely in the middle of the data protection battle. That demands better builds, right? As former CISA Director Jen Easterly famously put it, “We don’t have a cybersecurity problem. We have a software quality problem.”
This is absolutely true. But even with improved AppSec policies in the build phase, no app is an island. Leaked data has a blast radius that extends far beyond the platforms, and integrated data security protections are required to make apps the data lockbox they need to be.
Every API call, AI-generated code snippet, and hardcoded credential has the potential to become a data breach. In this light, AppSec needs to go beyond build-based improvements alone and participate in the broader domain of data security.
And that requires looking at application security in a different light.
The #1 DevOps Problem? Secrets Management
Secrets management was listed as the top application security concern among developers, according to the 2026 Thales Data Threat Report. This puts it ahead of DevOps toolchain alignment, AI security, and even release cadences.
Unfortunately, when it came to spending priorities, secrets management came in dead last.
Perhaps unsurprisingly, 67% are seeing credential theft and the misuse of secrets rise. And with cloud applications holding steady among the top three attack targets (accounting for 34%), it’s safe to say that applications are bearing the brunt of secrets-based attacks.
Secrets reveal data. And applications are giving them up. Because modern businesses are only as good as the data they stand on, this is no longer a developer-only problem—
Data security is a business priority, so AppSec must align with overarching data governance policies.
When It Comes to Protecting Data, Is AppSec Dropping the Ball?
In a word, yes. But only when it exists in a vacuum. Data sprawl is too large, and the stakes are too high for secret security to be left to build processes alone. This is what happens when they are:
- Secrets Leak: Fast sprints lead to forgotten credentials being left in logs, exposed in configuration files, or languishing unguarded in repositories.
- API Keys Multiply: The average org deals with roughly 89 SaaS apps, and every connection point is a chance to expose and lose credentials. Regular key rotation becomes a distant goal, and things get missed.
- Embedded Credentials Get Missed: Hardcoded credentials get baked into infrastructure-as-code, containers, and pipelines, spreading too far for manual processes to find.
- AI-Powered Development Can Perpetuate Exposures. AI adds an extra layer of complexity to securing build processes; as AI-generated code transmits at scale, exposures and flaws expand along with it. According to the report, 61% have had their AI applications targeted by attackers (with secrets as the main prize).
“Secure builds” are only a single line of defense. Today’s attackers are weaponizing AI to find not only sensitive data but also the weaknesses that expose it. If you don’t know where your sensitive assets reside – and 66% of respondents don’t – attackers will increasingly do the finding for you.
Siloed application security methods fail to track data at scale, centralize secret management, or secure sensitive data beyond access points alone. Which is why an integrated approach is needed.
Discovering “Integrated AppSec”
The mindset has to shift from securing the app to securing the data. But that shift isn't just philosophical. It requires treating data governance as a first-class citizen in every build process, not an afterthought applied once code is already in production.
That starts with visibility. You cannot govern what you cannot see, and most organizations are flying partially blind across their application estates. Sensitive data moves through APIs, gets cached in pipelines, and lands in cloud storage buckets that no one mapped at the start of the project. Continuous, automated discovery and classification of sensitive data across cloud and on-premises environments has to be the foundation on which everything else is built.
From there, secrets management needs to become a platform-level discipline rather than a developer-level habit. Rotation policies, access controls, and vaulting practices cannot vary project by project; that inconsistency is precisely where attackers find their footholds. Centralizing these controls removes the human variance that the Thales Data Threat Report identifies as the leading cause of breaches in the first place.
Finally, encryption and key management need to extend to the application layer itself, not just wrap the data at rest in cloud storage. When credentials are compromised (and the data says they increasingly will be), encryption at the data layer is the last line of defense that actually holds. Organizations that control their own encryption keys, independent of cloud providers, retain that control even when application-layer defenses fail.
Currently, aligning DevSecOps toolchains with data security practices ranks as the second-highest developer security challenge in the DTR, which means the integration gap is widely felt but not yet widely solved. The organizations that close it first are the ones that will be able to build fast without building exposure.
3 Solutions to Avoid Shipping Exposures
To keep data security as the north star in any application development process, Thales provides the following solutions, because data exposures should not be part of the rollout.
- Thales Data Security Posture Management (DSPM): Pinpoint the location of sensitive data across applications before they ship, giving teams a chance to apply encryption and data-centric security controls before insecure updates hit or flawed IaaS spreads across builds.
- Imperva Application Security: Protects data in transit, applications, and APIs from AppSec threats (bot-based attacks, DDoS, injection, credential abuse). Blocks over 113 billion application attacks monthly.
- Thales CipherTrust Data Security Platform (DSP): Discover, classify, and protect data while centralizing key and secret management from the same platform. Automatic encryption, key rotation, and data access policies protect data at the source, even when application-layer defenses are compromised.
Bridging Application and Data Security for Resilient Software
To create “quality” applications, data must be protected at every line of code. Data cannot be secured if it is not identified, and it cannot remain secure over time if it is not centrally managed at scale.
Application Security and Data Security can no longer be separate disciplines; because they aren’t to attackers. The sooner organizations integrate methods, the sooner they can roll out apps that consistently withstand today’s attacks.
Don't let your next release be your next breach. See how the Thales solutions work together to make application security a data security strength.