TL;DR: Security testing is moving from point-in-time validation to continuous pipeline control as AI-assisted development, APIs, cloud expansion, and third-party dependencies widen attack surfaces, according to StackHawk. The real challenge is not finding more tools but aligning testing with modern identity, runtime, and supply-chain risk.
At a glance
What this is: StackHawk argues that traditional security testing loses effectiveness when modern delivery pipelines, cloud environments, and AI-assisted development expand the attack surface faster than point-in-time checks can keep up.
Why it matters: IAM, NHI, and security teams should read this as a control-design problem: testing now has to account for API access, ephemeral environments, secret exposure, and machine-driven development paths.
Context
Security testing is the process of looking for weaknesses before attackers do, but that model starts to strain when software is delivered continuously and exposed through APIs, cloud services, and AI-assisted workflows. The governance gap is not whether testing exists, but whether it is aligned with how access, code, and runtime risk now move through modern systems.
For identity and access practitioners, the intersection is real: security testing increasingly touches secrets, service accounts, tokens, delegated access, and the permissions that development tooling uses to reach source code and deployment environments. Once AI agents and distributed cloud workloads enter the picture, the old assumption that controls can be verified only at release time becomes too slow for the risk profile.
The article’s starting position is typical for teams modernising their AppSec programmes: they know the old perimeter-style model is insufficient, but they are still working through how to test continuously without overwhelming delivery workflows.
Key questions
Q: How should security teams implement developer-first security testing in CI/CD workflows?
A: Security teams should place testing inside the tools developers already use, then make findings easy to act on before merge and release. The goal is fast feedback, low friction, and clear remediation guidance. Effective programmes connect scans to source control, CI pipelines, and pull requests so vulnerabilities are detected early, assigned to the right code, and fixed while the change is still fresh.
Q: Why do API-heavy and cloud-native systems need different security testing coverage?
A: Because the main risk shifts from a single application boundary to many service-to-service trust paths, transient resources, and permission decisions. Testing has to cover authorisation, authentication context, and environment drift, otherwise teams validate the wrong layer and miss the conditions attackers actually exploit.
Q: What do security and engineering teams get wrong about AI-assisted development?
A: They often confuse faster output with better control. AI assistants can generate code quickly, but they do not automatically preserve architecture, reuse patterns, or the source of truth. If teams only measure throughput, they may miss the fact that they are borrowing speed from the future and creating systems that are harder to govern.
Q: What happens when cloud and application security testing are treated as separate programs?
A: Coverage gaps appear at the seams. Cloud drift, API permissions, dependency risk, and runtime behaviour can all escape if each team tests only its own layer. The result is a false sense of assurance because the system is only secure in pieces, not as a whole.
Technical breakdown
Why point-in-time testing misses modern attack paths
Point-in-time testing assumes a stable target, yet cloud applications, CI/CD pipelines, and AI-assisted code generation produce a moving one. Static testing inspects code before execution, DAST probes runtime behaviour, IAST bridges both, and SCA looks at inherited library risk, but each only sees part of the system at a specific moment. That is why a release gate can look clean while the deployed environment still exposes APIs, misconfigurations, or dependency risk. The real architectural problem is coverage across time, not just coverage across code.
Practical implication: security testing must be tied to deployment and runtime change, not treated as a one-time pre-release event.
How API security and cloud expansion change the testing model
APIs, microservices, and ephemeral cloud resources change what has to be tested because the attack surface now includes service-to-service paths, shadow endpoints, and transient infrastructure states. Traditional web testing that focuses only on the front end misses the authorization logic, object access patterns, and environment drift that matter in distributed systems. In practice, cloud testing also has to deal with shared responsibility boundaries, where the application team owns only part of the risk. Security testing therefore needs discovery, authentication context, and runtime validation across API-heavy environments.
Practical implication: teams should verify API inventory, authorization behaviour, and cloud configuration together rather than as separate programmes.
Where AI-assisted development creates new testing blind spots
AI-assisted development speeds up code creation, but it also increases the chance that insecure patterns, copied dependencies, and hidden secrets enter the pipeline faster than reviewers can inspect them. If an AI agent contributes to code or analysis, the testing problem is not only code quality but trust in the provenance of what was generated and committed. That makes security testing part of software governance, because machine-produced changes can introduce vulnerabilities that conventional reviews treat too late or too lightly. The issue is not that AI changes the need for testing, but that it compresses the window in which testing can still prevent exposure.
Practical implication: security testing needs to inspect machine-generated changes, dependency inheritance, and secret exposure earlier in the workflow.
Threat narrative
Attacker objective: The objective is to exploit gaps between development-time assurance and runtime reality so that exposed systems, data, or credentials can be reached before defenders detect the weakness.
- Entry begins when insecure code, exposed APIs, or vulnerable dependencies are introduced into rapidly changing development and cloud environments.
- Credential and access abuse follows when secrets, tokens, service accounts, or overly broad permissions are present in the pipeline or runtime path.
- Impact occurs when those weaknesses reach production, allowing unauthorized access, data exposure, or operational disruption that point-in-time testing failed to catch.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Continuous security testing is now a governance problem, not just a tooling problem. Once software delivery is driven by CI/CD, APIs, and AI-assisted coding, the question becomes whether testing is embedded where change happens. The old model of validating security at the end of the cycle leaves too much risk outside the control boundary. Practitioners should treat testing as part of change governance, not as a final quality check.
API-heavy systems create a testing gap that traditional web security controls do not close. The article’s strongest signal is not about one testing method being superior, but about the attack surface shifting toward service-to-service access, shadow endpoints, and runtime authorisation paths. That intersects directly with identity governance because machine credentials, tokens, and delegated access now carry much of the enforcement burden. Practitioners should assume that untested API permissions are production risk, not technical debt.
AI-assisted development compresses the time available to catch insecure provenance. When code, dependencies, and even review assistance are machine-accelerated, the control failure is often not absence of testing but delay in where testing is applied. That creates a trust gap between what was generated and what was actually examined. Practitioners should move assurance earlier and closer to the source of change.
Attack surface expansion changes what counts as adequate assurance. A control set that was acceptable for monolithic applications can fail when cloud resources are ephemeral and third-party dependencies are constantly refreshed. The article underscores that modern security testing has to measure living systems, not frozen snapshots. Practitioners should re-baseline their testing programme around runtime behaviour, dependency integrity, and cloud drift.
What this signals
Continuous assurance is replacing release-time validation. Security testing has to follow the same tempo as cloud delivery and AI-assisted development, or it will lag behind the systems it is supposed to protect. That means practitioners should rework testing triggers, reporting, and ownership so findings arrive while they can still influence the change.
API authorization is becoming the practical centre of application risk. As more business logic moves behind services and machine-to-machine calls, testing needs to prove that access is correct, not merely that code is present. For IAM and application security teams, that pushes entitlement review closer to pipeline control and runtime verification.
For practitioners
- Embed testing into CI/CD gates Make security checks part of the delivery workflow so they run on every meaningful code or configuration change, not only before release.
- Expand coverage to API authorization paths Test object access, function access, and authenticated API behaviour in addition to front-end vulnerabilities and generic scan output.
- Validate dependency and secret exposure continuously Scan third-party libraries, build artifacts, and repositories for inherited vulnerabilities, exposed tokens, and credentials that AI-assisted changes can introduce.
- Add runtime checks for cloud drift Verify that ephemeral cloud resources, microservices, and deployment changes still meet security requirements after they reach production.
Key takeaways
- Security testing fails when it is treated as a pre-release checkpoint instead of a living control across the delivery lifecycle.
- The article’s central risk is the widening gap between runtime reality and the older assumptions behind point-in-time scanning.
- Practitioners should prioritise continuous coverage for APIs, cloud drift, dependencies, and machine-assisted code paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article repeatedly centers API security, runtime exposure, and misconfiguration in modern delivery pipelines. |
| Recommendation — Harden API deployments against misconfiguration and validate authorization behaviour during every release. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Testing now has to verify permissions across APIs, cloud services, and runtime paths. |
| Recommendation — Review and test entitlements continuously so API and cloud access remains aligned to intended authorizations. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is fundamentally about testing software security throughout development and deployment. |
| Recommendation — Embed application security testing into development and deployment workflows rather than relying on end-stage checks. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0008 — Initial Access; Credential Access; Lateral Movement | The attack patterns discussed map to credential exposure, unauthorized access, and spread through connected systems. |
| Recommendation — Map testing gaps to initial access, credential abuse, and lateral movement paths across cloud and API environments. | ||
Key terms
- Security Testing: Security testing is the practice of evaluating applications, infrastructure, and supporting services to find weaknesses before attackers do. In eCommerce, it covers code, configurations, integrations, and third-party components. The objective is to reduce exposure of customer data, payment information, and business operations while supporting compliance and resilient software delivery.
- 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.
- 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.
- Threat Modeling: A structured way to identify where an application can be entered, abused, or misused before or during development. It maps trust boundaries, access points, and likely abuse cases so teams can design controls that match the way attackers and misuse actually happen.
Deepen your knowledge
NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and IAM foundations. It helps security and identity practitioners connect operational controls to real-world identity risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org