Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: A survey of 250+ AppSec stakeholders found 87% of organisations now use AI coding assistants, while 94% still rely on at least one testing tool and half spend 40% or more of their time triaging findings, according to StackHawk. The real problem is not tool scarcity but the gap between discovery, prioritisation, and business-risk measurement.
NHIMG editorial — based on content published by StackHawk: The 2026 State of AI-Era AppSec: Key Findings from Our Survey
By the numbers:
- 87% of organisations surveyed have adopted AI coding assistants such as GitHub Copilot, Cursor, or Claude Code to some extent.
- 50% of respondents report their teams spend 40% or more of their time triaging and prioritizing findings.
- Only 30% of respondents are very confident that they have visibility into 90% or more of their application attack surface.
Questions worth separating out
Q: How should security teams secure AI-assisted development without overwhelming AppSec workflows?
A: Start with continuous discovery, then connect findings to exposure, criticality, and data sensitivity before remediation begins.
Q: Why do visibility gaps create more risk than extra testing tools reduce?
A: Testing tools only evaluate what they can see, and incomplete inventories mean entire applications, APIs, or machine identities may never be assessed.
Q: What do AppSec teams get wrong about triage at scale?
A: They often treat triage as an operational nuisance rather than a governance signal.
Practitioner guidance
- Build continuous application and API discovery Replace quarterly inventory exercises with continuous discovery that feeds AppSec, cloud, and identity governance reporting.
- Tie remediation queues to business exposure Score findings using application criticality, data sensitivity, and internet exposure before work enters the backlog.
- Reduce triage inflation with contextual prioritisation Limit manual review to findings that cross a defined exposure threshold, and automate suppression for low-signal categories that repeatedly generate noise.
What's in the full report
StackHawk's full report covers the operational detail this post intentionally leaves for the source:
- The survey breakdown behind the 250+ AppSec stakeholder sample, including respondent seniority and organisational profile.
- The full priority ranking of 2026 AppSec investments, including where AI security, visibility, and measurement sit relative to other initiatives.
- The detailed chart set behind tool adoption, triage burden, and board reporting patterns.
- The associated AppSec Leader's Guide to Survival in the AI Era, which provides the implementation framework behind the findings.
👉 Read StackHawk's 2026 survey findings on AI-era AppSec →
AI-era AppSec: what visibility and risk metrics now matter?
Explore further
02/08/2026 12:35 pm
AI-era AppSec is becoming an identity governance problem as much as a testing problem. When AI-assisted development becomes standard, the security question shifts from finding vulnerabilities to governing the credentials, permissions, and access paths that let software move through the pipeline. That means application security, IAM, and PAM are increasingly coupled, especially where CI/CD and cloud build systems rely on persistent machine access. Practitioners should treat software delivery identity as part of the security control plane.
A question worth separating out:
Q: How do application security and NHI governance intersect in AI-era pipelines?
A: Modern delivery pipelines rely on service accounts, tokens, and automated credentials to move code and deploy services. Those identities need lifecycle control, privilege review, and ownership just like human accounts do. If they are unmanaged, AppSec inherits the same standing-access problems that plague broader NHI programmes.
👉 Read our full editorial: AI-era AppSec is shifting from testing to visibility and risk
