Security testing still fails where AI and cloud attack surfaces expand

At a glance

What this is: This is a StackHawk guide to software security testing that argues modern testing must cover code, runtime behaviour, dependencies, and cloud attack surfaces.

Why it matters: It matters to IAM and security teams because APIs, secrets, service accounts, and AI-assisted workflows all create identity-adjacent risk that traditional one-off testing misses.

By the numbers:

• Security testing can reduce costly late-stage vulnerability discoveries before they contribute to the $4.4 million global average cost of a data breach in 2025.
• 20 minutes and it discovers complete API landscapes
• StackHawk says developers find its remediation guidance useful over 80% of the time.

👉 Read StackHawk's guide to software security testing strategies

Context

Security testing is the process of checking software for vulnerabilities before attackers can exploit them, but the article's deeper point is that modern development now creates faster-moving exposure than point-in-time testing can reliably cover. The first-order issue is not just application code quality, but whether security controls keep pace with APIs, cloud resources, third-party dependencies, and AI-assisted development workflows.

For identity programmes, the overlap is practical rather than theoretical. Secrets in repositories, overexposed API paths, and weak pipeline controls all affect how human users, service accounts, and non-human identities gain access, so security testing now sits close to IAM, secrets governance, and workload identity management.

Key questions

Q: How should security teams decide between SAST and SCA?

A: Use SAST for code your organisation wrote and SCA for software it imported. If the application has both custom logic and third-party packages, you need both controls because they answer different questions. The correct decision model is coverage, not replacement, especially when runtime exposure and privilege change the impact of each finding.

Q: Why do APIs and secrets create security testing gaps in modern DevSecOps pipelines?

A: APIs and secrets move with release velocity, which means they often exist before teams have complete governance around them. Shadow APIs, hardcoded credentials, and ephemeral build artefacts can bypass review if testing is not tied to discovery and lifecycle controls. The result is that access risk appears faster than traditional control cycles can absorb it.

Q: What do teams get wrong about automated pentesting?

A: They assume automated coverage is enough on its own. Automation is good at scale, but it often misses business logic abuse, chained privilege paths, and the context needed to judge whether a finding is truly exploitable. Automated pentesting works best when paired with human validation and strong remediation governance.

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

SAST, DAST, and IAST test different trust boundaries

Static application security testing scans source code without running it, so it is good at finding predictable defects such as injection flaws and insecure crypto before release. Dynamic application security testing executes the application and probes live behaviour, which is why it catches runtime exposure, authentication weaknesses, and API issues that only emerge under malicious input. Interactive application security testing combines both by observing executed code paths during runtime, which usually reduces false positives but still only sees what the test actually exercises. The architectural difference matters because no single method covers design-time flaws, runtime failures, and implementation drift equally well.

Practical implication: teams should map each testing method to the trust boundary it actually covers instead of assuming one tool provides full coverage.

Software composition analysis is now supply-chain control, not just dependency scanning

Software composition analysis checks third-party libraries, frameworks, and open-source components for known vulnerabilities and licensing issues. In practice, this is a supply-chain control because modern applications inherit risk from packages, transitive dependencies, and build systems that developers do not fully author themselves. The article also points to AI-generated code provenance, which raises the bar further: teams must know not only what library is present, but where code came from and whether it can be trusted. That shifts SCA from hygiene to governance.

Practical implication: maintain an inventory of direct and transitive dependencies, then tie SCA findings to release gating and remediation ownership.

Threat modeling is the bridge between application testing and runtime risk

Threat modeling identifies likely attack paths before code is complete by mapping assets, data flows, and trust boundaries. In the article's framing, that matters because cloud-native systems and AI-assisted development expand the attack surface faster than manual review alone can follow. The useful insight is that testing becomes much more efficient when it is guided by a model of where attackers will look first, rather than by generic test coverage. For identity-heavy systems, that includes secrets exposure, role misuse, and API authentication failure points.

Practical implication: use threat models to decide which services, APIs, and build stages deserve the deepest security tests.

NHI Mgmt Group analysis

Continuous testing is becoming an identity control problem as much as a code quality problem. The article treats security testing as a software delivery discipline, but the practical issue is that API endpoints, secrets, service accounts, and CI/CD pipelines are now part of the access surface. When testing misses exposed credentials or shadow APIs, the failure is not only a vulnerability gap, it is a governance gap across human and non-human access. Practitioners should treat security testing as a control over who and what can reach production systems.

API discovery is the named control gap this article points toward. StackHawk's emphasis on finding complete API landscapes, including shadow APIs, reflects a broader problem: organisations often secure the endpoints they know about while leaving unmanaged interfaces reachable. That creates an access boundary that is invisible to IAM, PAM, and security testing alike until a scanner or attacker finds it. The practitioner conclusion is straightforward: if you cannot enumerate the API surface, you cannot meaningfully secure it.

Secret exposure is no longer just a repository hygiene issue. The article's references to modern development workflows, AI-assisted code, and CI/CD speed all reinforce the same point: exposed secrets move faster than manual review can. In NHI terms, that means service credentials, tokens, and certificates need lifecycle controls that align with how software is built and deployed, not just how humans access systems. Teams should connect security testing outputs to secrets governance and rotation workflows.

Risk-based testing will outperform blanket tool adoption. The article correctly notes that testing can become noisy and slow when teams try to cover everything equally. The stronger governance model is to prioritise assets with the highest blast radius, then align SAST, DAST, IAST, and SCA to the specific failure modes that matter most. For identity and access programmes, that means focusing on the systems that issue, store, or use credentials rather than treating all code paths as equal.

AI-assisted development increases the need for provenance-aware controls. The article hints at AI-generated code and agents inside development workflows, which means the security question is no longer only whether code compiles or passes scans. It is also whether the source, transformation, and approval path are trustworthy enough for release. Practitioners should view AI coding systems as governance subjects that require traceability, just like any other non-human contributor.

What this signals

Shadow API discovery is becoming a governance requirement, not a scanner feature. As development shifts toward AI-assisted coding and faster release cycles, teams need continuous visibility into undocumented interfaces, exposed secrets, and service-to-service access paths. That is where Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 become useful references for control design.

Secret lifecycle gaps will keep surfacing in testing unless ownership is explicit. The practical signal for programmes is not just whether a scanner finds a token, but whether the organisation can trace that token back to an owner, an application, and an offboarding path. That is why identity teams should align testing outputs with the NHI Lifecycle Management Guide rather than treating security testing as a separate discipline.

Provenance-aware development will matter more as AI-generated code enters the pipeline. When code comes from models, copilots, or agentic workflows, the question becomes whether release governance can verify source, change intent, and dependency trust. The control model is moving toward traceability across the build chain, not just vulnerability detection at the end.

For practitioners

• Map testing methods to control objectives Assign SAST to pre-merge code defects, DAST to runtime API and authentication behaviour, IAST to exercised code paths, and SCA to dependency and licensing risk. Then tie each method to an owner, a release gate, and a remediation SLA.
• Inventory every exposed API and shadow interface Build a living inventory from source repositories, gateways, and discovery scans so that undocumented APIs do not sit outside security testing coverage. Reconcile that inventory with IAM and secrets controls before release.
• Connect secret findings to rotation and offboarding workflows When security tests uncover exposed tokens, keys, or certificates, route them into credential revocation, rotation, and service-account ownership checks rather than treating them as standalone defects. This closes the loop between testing and NHI governance.
• Use threat models to prioritise the highest-blast-radius paths Focus deep testing on code paths that issue access, process credentials, or expose sensitive data, especially where cloud resources and third-party dependencies converge. That is where attackers usually gain the most leverage.

Key takeaways

• Security testing is shifting from a code-centric task to a control over APIs, secrets, dependencies, and release pipelines.
• The strongest signal in this article is that testing fails when discovery and lifecycle governance are missing, especially for non-human identities and exposed interfaces.
• Practitioners should align each testing method to a specific failure mode and tie findings directly to ownership, remediation, and access control.

Key terms

• 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.
• 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.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.

What's in the full article

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

• Developer-focused comparisons of SAST, DAST, IAST, and SCA implementation trade-offs
• Tool-specific guidance for API security testing in CI/CD pipelines
• Detailed examples of how the source vendor positions runtime testing and remediation workflows
• Practical selection advice for teams choosing a security testing approach

👉 StackHawk's full post covers the testing methods, workflow trade-offs, and tool selection detail

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect access control, lifecycle management, and operational governance across identity programmes.