Application security testing in 2026 is changing with agentic development

At a glance

What this is: This guide explains how SAST, DAST, SCA and IAST fit together, and argues that agentic development breaks scan timing assumptions.

Why it matters: It matters because IAM, NHI and application security teams now need to govern agent-generated code, secrets and privileges before conventional testing can compensate.

By the numbers:

• Applications are the most exploited entry point in 68% of global enterprise breaches.
• SCA scans dependencies across 70-90% of your codebase, reflecting how much application risk now sits in third-party libraries.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arnica's guide to application security testing tools and agentic development

Context

Application security testing exists to catch flaws before attackers do, but modern delivery pipelines now move faster than many control gates. In practice, static, runtime and composition testing each see only part of the risk, which is why security teams still find hardcoded credentials, injection flaws and vulnerable dependencies after code has already been shaped by automation.

The identity angle is stronger than the article makes it sound. Agentic development creates more non-human actors inside software delivery, and that means the security conversation extends beyond code quality into NHI governance, secret handling and access control for machine-originated changes. That is a familiar pattern in mature AppSec programmes, but agentic workflows make it harder to treat as an edge case.

Key questions

Q: How should security teams govern application security across the SDLC?

A: They should treat the SDLC as a chain of trust, not a sequence of isolated review steps. That means combining vulnerability scanning with provenance checks, secret governance, pipeline identity controls, and runtime monitoring. The goal is to know which identity can change code, which dependencies were introduced, and whether anything suspicious reached production.

Q: Why do generated code and non-human identities complicate application security governance?

A: Because machine-generated changes can introduce code, credentials and configuration before a human review step has any effect. That means the organisation must govern the non-human actor and its permissions, not just inspect the output. Without that, security teams respond after risk has already been created.

Q: What breaks when teams rely on scan schedules instead of continuous security enforcement?

A: Anything created between scans can ship with unmanaged risk. Agent-generated pull requests, dependency updates and secret leaks all move faster than periodic checks, so the organisation loses preventive control and falls back to remediation. Continuous enforcement closes that gap by moving policy into the workflow itself.

Q: How can organisations tell whether security testing is actually reducing risk?

A: Look for shorter time to fix, fewer repeat findings, and direct routing of issues into remediation workflows. Strong programmes also show that security tests are covering the systems with the highest blast radius, not just generating large volumes of findings. If release decisions change because of testing, the control is working.

Technical breakdown

How SAST, DAST, SCA and IAST divide the application risk surface

These four methods answer different security questions. SAST inspects source, bytecode or binaries before execution, so it catches issues like hardcoded secrets or unsafe functions early. DAST attacks a live application from the outside, which is useful for runtime flaws and misconfigurations. SCA maps third-party dependency risk, including vulnerable packages and transitive libraries. IAST sits inside test execution and correlates code flow with runtime behaviour, reducing false positives because the finding is tied to an actually executed path, not only a theoretical pattern.

Practical implication: treat the four methods as complementary controls, not interchangeable tools.

Why agentic development changes scan timing assumptions

Traditional AppSec assumes the pipeline is the place where security policy can still intercept risky code. Agentic development weakens that assumption because code, configuration and dependency choices may be generated before a human reviews the change. If the security rule set is only enforced at scan time, the organisation is already reacting to artefacts the agent produced. The governance issue is not merely faster development. It is the emergence of more non-human decision points that can create security debt before SAST or DAST can see them.

Practical implication: move policy enforcement upstream into the agent configuration and repo controls.

Why secrets and code security are converging

The article rightly links application security testing to secrets exposure because hardcoded credentials remain a common code-level failure mode. Secrets management is not separate from AppSec when keys, tokens and certificates are embedded in source, CI/CD files or generated artefacts. Once those secrets are present, scanning alone is too late for prevention and too noisy for lifecycle control. This is where NHI governance matters: credentials need issuance, rotation, revocation and visibility, not just detection after they appear in code.

Practical implication: align AppSec findings with secret lifecycle controls and NHI ownership.

Threat narrative

Attacker objective: The attacker wants to turn application-level weaknesses into broader access and operational impact across development and production environments.

1. Entry occurs when attackers exploit application flaws or exposed secrets embedded in code, CI/CD workflows or dependencies.
2. Escalation follows when those secrets or weaknesses grant broader access to repositories, cloud resources or production systems.
3. Impact is achieved through data theft, code tampering, service disruption or downstream compromise of other connected systems.

NHI Mgmt Group analysis

Agentic development creates a governance gap, not just a tooling gap: when software agents can generate code and configuration before human review, SAST and DAST become downstream controls rather than preventive guardrails. That changes the security model from scan-and-fix to govern-and-constrain, especially where the output can include secrets, permissions or infrastructure changes. Practitioners should treat agentic code generation as a non-human identity problem as much as an AppSec problem.

Application security testing is increasingly an identity control surface: hardcoded credentials, excessive repository permissions and machine-generated commits all sit at the intersection of AppSec and NHI governance. The strongest programmes do not separate code risk from credential risk, because the same workflow often creates both. Organisations that cannot see who or what is allowed to write, execute and promote changes will keep discovering issues too late.

False positives are a signal problem, but false negatives are the strategic risk: the industry tends to focus on noisy scans because they are visible, yet the bigger failure is missing the code or dependency path that matters. That is why runtime confirmation, dependency reachability and workflow-level policy matter more than tool counts. The decision should be whether security feedback changes developer behaviour before release, not whether another scanner exists.

Security policy must travel with the workflow: the article points to a broader shift where controls need to follow code creation, not just code deployment. That aligns with modern identity governance thinking, where access and privilege are managed continuously rather than inspected after the fact. For AppSec teams, the practitioner conclusion is simple: move enforcement as close as possible to the place where code and secrets are created.

Supply chain visibility is now part of application testing: SCA is not an optional add-on when 70-90% of code often comes from open source dependencies. The named concept here is application risk sprawl, the way dependency volume, generated code and runtime complexity make point-in-time review ineffective. The practical answer is tighter provenance, reachability analysis and ownership for every package that enters the pipeline.

What this signals

Application security programmes are being pulled into identity governance whether they planned for it or not. Once agents can create code, secrets and repository changes, security teams need to know who controls those non-human actions and how quickly they can be revoked. That makes the boundary between AppSec and NHI governance far less clean than most operating models assume.

Control effectiveness will increasingly depend on where policy is enforced, not how many scanners are deployed. If rules live only in the pipeline, they will always trail generated output. Teams should expect more pressure to shift controls into agent configuration, repository policy and secret lifecycle management rather than relying on post-generation detection.

Application risk sprawl is now a programme-level issue. Dependency volume, generated code and embedded secrets spread responsibility across development, security and identity teams. Organisations that align SAST, DAST, SCA and NHI ownership will have a better chance of keeping pace than those treating each as a separate backlog.

For practitioners

• Map security controls to each testing layer Assign SAST to pre-merge code review, DAST to staging validation, SCA to dependency intake and IAST to test execution so each control has a clearly owned decision point.
• Push policy into agent configuration files If agents are generating code or pull requests, enforce managed security rules in their configuration so unsafe patterns are blocked before the pipeline sees them.
• Track secrets as lifecycle assets Treat tokens, API keys and certificates as governed identities with ownership, rotation and revocation, rather than as static artefacts to be discovered after commit.
• Reduce dependency blind spots Use reachability analysis and transitive scanning to separate exploitable library risk from noise, then make package ownership explicit for every high-risk dependency.

Key takeaways

• Application security testing no longer works as a late-stage filter when agentic development can generate risk before human review.
• The most useful control model combines code scanning, runtime validation, dependency governance and secret lifecycle management.
• Identity governance and AppSec are converging because non-human actors now shape the same code and credential surfaces attackers target.

Key terms

• Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.

What's in the full article

Arnica's full blog covers the operational detail this post intentionally leaves for the source:

• How its agentic rules are written into repository configuration before code reaches SAST or DAST
• The specific workflow behaviour it claims to change when security policy travels with the agent
• Examples of how the managed rule pack propagates across repositories and connected development environments
• The vendor's implementation framing for reducing downstream AppSec noise

👉 Arnica's full post covers the AppSec control breakdown, workflow examples and agentic rules detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps security and identity practitioners connect machine access, lifecycle control and governance decisions across modern delivery pipelines.