Topic starter
18/08/2026 2:50 pm
TL;DR: Application security testing still depends on SAST, DAST and SCA, but Arnica argues agentic development changes the timing problem because agents can create risky code faster than scan schedules, while applications remain the entry point in 68% of global enterprise breaches, according to the article. The control question is shifting from finding flaws later to governing what gets generated before it reaches the pipeline.
Editorial analysis by NHI Mgmt Group, based on content published by Arnica: “Application Security Testing Tools: Complete Guide for CISOs (June 2026)”.
By the numbers:
- Applications are the most exploited entry point in 68% of global enterprise breaches, according to Arnica.
Key questions
Q: What breaks in application security testing when agentic development outpaces scan schedules?
A: The control that breaks first is timing.
Q: Why does faster code generation increase application risk even if scan coverage stays the same?
A: Because coverage and timing are not the same thing.
Q: What breaks when application security testing is moved too late in the delivery cycle?
A: Late testing turns vulnerabilities into backlog, which increases alert fatigue and encourages teams to work around controls.
Practitioner guidance
- Enforce policy before code generation Push approved security rules into agent configuration so risky patterns are constrained before code is written or committed.
- Tune SAST and DAST for pipeline timing Run static checks at commit time and runtime checks against staging on every deployment, but do not rely on them as the first control point.
- Prioritise reachable dependency risk Use SCA to focus on transitive packages and exploitable paths, not just raw CVE volume, so teams fix what can actually be reached.
Bottom line: Agentic development changes the AppSec timing model by letting unsafe code appear before traditional scans run.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:32 pm
Agentic development creates a code-generation trust gap: security teams have spent years hardening review and scan stages, but the new risk is that non-human actors can introduce unsafe code before those stages fire. That changes application security from a post-generation detection problem into a governance problem about what may be generated at all. Practitioners should treat agent output as a controlled security input, not just a developer productivity feature.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should organisations govern agent-generated code in application security programmes?
A: They should treat agent output as a governed security input, with policy enforced at generation time and not only in CI/CD. That means controlling what the agent can produce, validating policy coverage across repositories, and keeping SAST, DAST and SCA as downstream verification rather than the first line of defence.
👉 Read our full editorial: Application security testing in 2026 is changing with agentic development