AppSec trends in 2025 are converging on runtime risk

At a glance

What this is: This is a 2025 AppSec trends roundup that says teams are shifting toward earlier detection, better prioritisation, and more context-aware analysis.

Why it matters: For IAM and NHI practitioners, the article matters because code, secrets, and runtime access are converging into one governance problem that conventional controls still handle inconsistently.

👉 Read Backslash Security's analysis of the top 5 AppSec trends in 2025

Context

Application security is no longer just about finding bugs in code. It now has to account for how secrets, service credentials, open-source components, and AI-assisted development move through modern delivery pipelines, which makes NHI governance part of the AppSec problem space.

This article frames that shift through five trends, but the deeper issue is control quality: teams are trying to reduce noise, understand real exploitability, and keep pace with GenAI-driven code creation. That combination is typical of mature AppSec programmes, but the NHI angle is now unavoidable because credentials are embedded in the same workflows.

Key questions

Q: How should security teams handle secrets found in application code?

A: Treat every secret in code as a governance issue, not just a coding mistake. Security teams should identify whether the secret is still valid, what systems it can reach, and whether it has been used elsewhere. Then rotate or revoke it, remove it from source control, and add build-time scanning so the same exposure does not recur.

Q: What is the difference between static scanning and runtime analysis in AppSec?

A: Static scanning reviews code and configuration before deployment, while runtime analysis observes actual behaviour in execution. Static controls are better for catching exposed secrets and insecure patterns early. Runtime controls are better for seeing what is truly reachable. Mature programmes use both because each one exposes a different part of the risk picture.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: How can teams prioritise AppSec findings more effectively?

A: Prioritise findings by exploitability, reachability, and privilege. A low-severity issue that exposes a valid credential or reaches a sensitive API is often more urgent than a high-volume category of theoretical findings. This approach reduces noise and focuses remediation on the issues that can actually change access or impact.

Technical breakdown

Static scanning versus runtime agents in AppSec

Static scanning examines code and configuration before deployment, while runtime agents observe behaviour during execution. The distinction matters because static methods can flag insecure patterns early, but runtime tooling sees actual data flow, request context, and reachable execution paths. In practice, neither view is complete on its own. Static analysis can miss contextual exploitability, while runtime-only approaches can be expensive to deploy and may still leave secret sprawl or build-time exposure untouched. For NHI governance, the lesson is that credential and secret controls must cover both pre-release and live environments.

Practical implication: Use static controls to catch exposed secrets and insecure patterns early, then verify that runtime visibility exists for anything that can reach production.

GenAI code generation and secret exposure risk

Generative AI changes AppSec because it increases code volume without guaranteeing security maturity. AI-generated code often blends new logic with copied patterns, third-party libraries, and embedded configuration, which raises the chance that secrets, tokens, or insecure defaults are propagated faster than teams can review them. The risk is not that GenAI writes every flaw, but that it accelerates the spread of weak assumptions across the delivery pipeline. For NHI practitioners, this means secrets governance cannot sit outside software engineering. It has to be embedded in code review, build validation, and release controls.

Practical implication: Treat AI-assisted code as a higher-throughput source of NHI exposure and enforce secret detection in every build and review stage.

Reachability analysis and the identity blast radius

Reachability analysis asks whether a discovered issue can actually be exploited in the application’s real architecture and data flow. That is different from simple vulnerability counting, because many findings are theoretical until a code path, dependency, or credential makes them reachable. This is especially relevant to NHI security because a leaked secret is only dangerous if it is valid, privileged, and usable in a reachable path. The most useful AppSec programmes are therefore mapping exploitability to access scope, not just enumerating defects. That is where identity blast radius becomes the useful operating concept.

Practical implication: Prioritise vulnerabilities and secrets by exploit path, reachable scope, and privilege level rather than by raw alert volume.

Threat narrative

Attacker objective: The attacker wants to turn a code-level weakness into usable access that reaches production systems, secrets, or data paths.

1. Entry occurs when attackers obtain exposed secrets, insecure tokens, or vulnerable third-party dependencies from the application delivery pipeline.
2. Escalation follows if those credentials are valid across environments or carry excessive privilege, allowing broader access than the original code flaw implied.
3. Impact arrives when reachable code paths, CI/CD systems, or production APIs are used to exfiltrate data or alter application behaviour.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AppSec is becoming an NHI governance problem, not just a code-quality problem. Secrets, service accounts, and API tokens are increasingly embedded in the same pipelines that produce application code. That means the operational question is no longer only whether code is secure, but whether the identities that code depends on are visible, scoped, rotated, and revoked correctly. Practitioners should treat delivery pipelines as identity-control surfaces.

Identity blast radius: is the most useful concept for modern AppSec prioritisation. Reachability analysis matters because not every finding creates the same exposure, and not every secret is equally dangerous. A valid credential with broad scope is a bigger operational risk than a long list of low-probability findings. Teams should prioritise by reachable privilege, not by alert count.

GenAI raises the speed of NHI sprawl faster than most governance teams can absorb. If code generation increases throughput without equivalent secret hygiene, then hidden credentials, insecure defaults, and over-permissioned service access will scale with it. That does not make GenAI inherently unsafe, but it does make manual review-only approaches inadequate. Practitioners should design controls for velocity, not just for correctness.

Noise reduction is now a governance requirement, not a convenience feature. Legacy AppSec programmes often fail because they produce more findings than teams can act on, which leads to alert fatigue and missed remediation windows. In NHI terms, that is how exposed secrets persist, valid credentials remain live, and ownership remains unclear. Organisations should demand tooling and process that separate theoretical issues from reachable risk.

Modern AppSec programmes should be measured by remediation quality, not tool volume. The article’s trend line points toward contextual analysis, better triage, and tighter integration across SAST, SCA, secrets detection, and runtime visibility. That direction is consistent with stronger NHI governance because it forces teams to control access paths rather than merely catalogue them. Practitioners should use this shift to tighten accountability across engineering and identity teams.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap makes the next step clear, so teams should review Top 10 NHI Issues alongside application security controls.

What this signals

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the governance gap is structural rather than tactical. Security teams should treat application pipelines as identity systems and wire controls into every stage where credentials can be created, copied, or deployed.

Identity blast radius: will become the practical metric that unifies AppSec and NHI governance. The more teams can tie findings to reachable access, the easier it becomes to justify remediation, reduce noise, and align engineering with identity risk management.

As GenAI increases code output, the pressure shifts from vulnerability detection alone to continuous credential hygiene, access scoping, and ownership clarity. Teams that still separate AppSec from identity management will keep missing the same class of exposure in different places.

For practitioners

• Map secrets to reachable access paths Inventory where secrets appear in code, CI/CD, configuration, and runtime environments, then trace which ones can actually reach production systems or sensitive APIs.
• Enforce secret detection before release Run secret scanning in pull requests, build pipelines, and deployment gates so exposed tokens and credentials are stopped before they leave the delivery process.
• Prioritise findings by privilege and reachability Rank remediation work by whether the issue is exploitable, whether the credential is still valid, and how much access it confers if abused.
• Separate AI-generated code from trusted code paths Apply stricter review and validation controls to AI-assisted output, especially where it can introduce copied secrets, unsafe defaults, or unmanaged dependencies.
• Reduce alert noise with contextual triage Require tools and workflows that suppress non-reachable findings and preserve attention for issues that can affect identity scope, application integrity, or production data.

Key takeaways

• Application security trends in 2025 point to a deeper identity problem because secrets, credentials, and access paths now sit inside the delivery pipeline.
• Reachability analysis and contextual triage matter because raw finding counts do not tell teams which issues can actually change access or cause impact.
• Security programmes that link AppSec with NHI governance will be better positioned to control privilege, reduce noise, and shorten remediation cycles.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Identity blast radius: Identity blast radius is the amount of access that a compromised credential, token, or service account can expose if abused. In NHI governance, it reflects privilege scope, environment reach, and how quickly an identity can move from single-purpose access to broad operational impact.
• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials, tokens, and keys across code, configuration, CI/CD, and runtime systems. It makes ownership harder, rotation slower, and exposure more likely, especially when teams do not have a single governed path for storage and revocation.
• Runtime agent: A runtime agent is a control that observes application behaviour while software is executing. It can surface live data flow and exploit context that static tools may not see, but it must be paired with pre-deployment controls to cover secrets, code, and delivery pipeline exposure.

Deepen your knowledge

Application security, secrets hygiene, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to control identity risk inside modern delivery pipelines, it is worth exploring.

This post draws on content published by Backslash Security: The Top 5 AppSec Trends of 2025. Read the original.