Add application security testing as soon as the application itself makes access decisions that matter to the business. If a user, token, or service account can reach sensitive actions through code paths, those paths need direct testing. IaC coverage should be treated as complementary, not a substitute for code-level assurance.
Why This Matters for Security Teams
IaC scanning is valuable, but it only proves that declared infrastructure meets a defined baseline. It does not tell a security team whether the deployed application enforces authentication, authorisation, session handling, or input validation correctly. Once business-sensitive actions are decided in code, risk moves from configuration drift into the application layer, where control failures are harder to see and easier to exploit.
This is why application security testing should begin as soon as code paths can affect access to data, money, administration, or other protected workflows. A clean Terraform or CloudFormation review can coexist with a vulnerable API endpoint, a broken role check, or a missing server-side validation control. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes the distinction clear by separating system and application control expectations from infrastructure hygiene.
Teams often get this wrong when they treat IaC scanning as a gate for the whole delivery pipeline instead of one control in a layered assurance model. In practice, many security teams encounter application-layer abuse only after a business workflow has already been exposed, rather than through intentional code-level testing.
How It Works in Practice
The practical trigger is not the presence of a cloud template, but the presence of application logic that can change trust, privilege, or data exposure. If the application decides who can approve payments, view customer records, mint tokens, call internal APIs, or assume a role, then static and dynamic application security testing belongs in scope. IaC scanners still matter, but they should be paired with controls that exercise the code itself.
Current guidance suggests combining several testing layers rather than relying on one tool category. For example, SAST can review source for insecure access control patterns, DAST can probe running endpoints for broken authorisation, and targeted abuse-case tests can confirm that protected actions fail closed. Where teams use cloud-native controls, the application should also be checked for security assumptions that depend on environment settings, because those assumptions are often fragile during refactoring or release automation.
- Test code paths that make decisions about roles, scopes, session state, or tenant boundaries.
- Verify that sensitive functions enforce server-side checks, not only client-side restrictions.
- Include APIs, background jobs, and service-to-service calls, not just user-facing screens.
- Re-test after changes to identity flows, permission models, or business logic.
Frameworks such as OWASP Application Security Verification Standard are useful for defining what “good” looks like at the code and behaviour level, while CISA’s Known Exploited Vulnerabilities Catalog helps teams prioritise weaknesses that are actively being abused in the wild. Security leaders should also align application testing with release criteria so that high-risk changes cannot bypass verification simply because infrastructure scans passed. These controls tend to break down when microservices, third-party APIs, and rapid feature flags shift trust decisions across many components because ownership and testing boundaries become unclear.
Common Variations and Edge Cases
Tighter testing coverage often increases release friction and engineering overhead, requiring organisations to balance assurance against delivery speed. That tradeoff is real, especially when teams are small or systems change quickly. The right answer is not to test everything equally, but to increase depth where the application actually carries security responsibility.
There is no universal standard for exactly which applications need code-level testing first. Best practice is evolving toward risk-based selection: start with internet-facing services, identity-sensitive workflows, privileged admin functions, payment paths, and any code that handles secrets or trust decisions. If the application is a thin wrapper around managed services and contains little logic beyond routing, IaC scans may carry more weight for initial triage. If it contains business rules, policy enforcement, or session-dependent authorisation, application security testing should be mandatory.
Edge cases also matter. Serverless functions, low-code apps, and agentic workflows can appear simple at the infrastructure layer while still making high-impact decisions in code. In those environments, code review, SAST, and behaviour testing should be added even when the deployment stack looks well controlled. For higher-maturity programs, the goal is not to replace IaC scanning, but to connect it with application assurance so that infrastructure, code, and identity controls are tested as one system.
Where the organisation operates regulated workloads, the expectation rises further because audit evidence usually needs to show that both platform configuration and application logic were checked before release. That is especially true when the application can influence access rights, transaction approval, or record visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Application testing protects access decisions that IaC scans cannot validate. |
| OWASP Agentic AI Top 10 | Code-level testing is needed when AI or automated logic can make access decisions. | |
| NIST AI RMF | MAP | Risk mapping helps determine where application logic introduces security exposure. |
| MITRE ATLAS | Adversarial abuse patterns matter when app logic is exposed to manipulation. | |
| NIST AI 600-1 | GenAI systems need testing when prompts or tools affect business-critical actions. |
Use adversarial abuse scenarios to test whether application paths fail safely under attack.
