A narrow AppSec program can miss supply chain issues, infrastructure weaknesses, and broader operational exposures that sit outside a single codebase. Modern software depends on dependencies, cloud services, and cross-functional workflows, so application-level testing alone does not cover the full attack surface. Security leaders should treat AppSec as one control layer, not a complete security strategy.
Why This Matters for Security Teams
A narrow application security program is useful, but it only answers part of the risk question. Modern delivery chains include open source dependencies, CI/CD systems, cloud roles, API integrations, and non-human identities that can outlive the code they support. NIST’s NIST Cybersecurity Framework 2.0 pushes teams toward broader governance because the real exposure spans asset inventory, identity, supply chain, and operations, not just source code review.
That wider view is especially important for NHIs. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now both show that identity sprawl and credential weakness frequently sit outside conventional AppSec workflows. In practice, many security teams discover the critical gap only after a dependency, token, or pipeline account has already been abused, rather than through intentional application testing.
How It Works in Practice
AppSec programs usually focus on what can be scanned from the codebase: vulnerabilities, secrets in repositories, insecure libraries, and common web flaws. That approach is necessary, but it misses failure modes created by delivery systems and runtime trust. A build runner with excessive cloud permissions, a service account reused across environments, or a third-party OAuth integration with broad access can create material risk even when the application itself is clean.
A more complete program maps the full delivery path and asks where trust is granted, how long it lasts, and who or what can use it. That means pairing code-centric testing with identity review, dependency governance, and runtime controls:
- Inventory third-party packages, container images, and build artifacts with ownership and update paths.
- Review CI/CD and cloud identities as first-class assets, not just support plumbing.
- Enforce short-lived credentials and rotation for secrets used by pipelines and workloads.
- Validate egress, permissions, and deployment approvals where code moves into production.
- Correlate AppSec findings with logging and detection so abuse of trusted automation is visible.
This is where broader guidance matters. The OWASP view of the OWASP Agentic Applications Top 10 is useful for autonomous workloads, while the same underlying lesson applies to traditional delivery: software risk is often created by the identities and integrations around the code, not just the code itself. These controls tend to break down in highly ephemeral cloud environments because ownership is blurred and temporary access is rarely tracked back to a business service.
Common Variations and Edge Cases
Tighter application testing often increases process overhead, requiring organisations to balance scan coverage against release speed and operational complexity. That tradeoff is real, but current guidance suggests the answer is not to narrow AppSec further. Instead, teams should scope controls by delivery model and business criticality, then apply stronger governance where automation, third-party access, or privileged pipelines are involved.
There is no universal standard for this yet. Some organisations centralise dependency and secrets review in platform engineering, while others keep it in AppSec and security operations. Either model can work if it closes the gaps between code, identity, and runtime. The key exception is highly regulated or safety-sensitive software, where a code-only program is especially misleading because control failures may arise in infrastructure policy, vendor access, or release orchestration rather than in the application layer itself.
For teams expanding beyond AppSec, NHIMG’s 2024 ESG Report: Managing Non-Human Identities is a useful reminder that compromised NHIs are not a theoretical edge case. The report found that 72% of organisations have experienced or suspect they have experienced an NHI breach, which is why risk programs must extend beyond code scanning to the identities that ship, deploy, and operate software.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Broader governance is needed when AppSec misses supply chain and runtime risk. |
| OWASP Non-Human Identity Top 10 | NHI-01 | CI/CD and service identities are NHIs that AppSec programs often overlook. |
| CSA MAESTRO | TRUST-02 | Trusted automation and dependencies can fail outside code-scanning coverage. |
| NIST AI RMF | GOVERN | Risk oversight must extend beyond code to the full AI or software delivery system. |
| OWASP Agentic AI Top 10 | A1 | Autonomous tooling and agentic workflows expand risk beyond traditional AppSec scope. |
Define software delivery risk across code, identity, cloud, and vendors, not just application flaws.
Related resources from NHI Mgmt Group
- Why do code review tools miss important application security risks in modern software delivery?
- Why do traditional security tools often fail to reduce application risk in modern software teams?
- How should security teams govern software supply chain risk in application delivery?
- Why do APIs create more security risk as organisations move faster in modern software delivery?
