TL;DR: Application security still breaks down when organisations treat code scanning, testing, and governance as sufficient while leaving secrets, access, and runtime identity controls weak, according to Cycode’s analysis. The practical lesson is that secure delivery now depends on treating applications, pipelines, and service accounts as an identity governance problem, not just a tooling problem.
At a glance
What this is: Cycode argues that application security best practices fail when organisations leave identity, secrets, and access controls weak across the software lifecycle.
Why it matters: For IAM, PAM, and NHI practitioners, the key lesson is that application security is also an identity governance problem because services, secrets, and access paths can be abused like user accounts.
By the numbers:
- Security monitoring can reduce combined detection and response time to 241 days, compared with 321 days without automation.
Context
Application security is the control layer that keeps code, pipelines, dependencies, and runtime access from becoming a single compromise path. In this article, Cycode’s core point is that traditional AppSec practices are incomplete if identity, secrets, and privilege are not governed alongside code quality and testing.
The identity angle is genuine here because application assets are increasingly accessed by service accounts, API keys, tokens, and other non-human identities. If those identities are not inventoried, scoped, rotated, and monitored, then secure development becomes a governance problem as much as a technical one.
The blog’s starting position is typical for modern enterprise environments: most organisations have some combination of scanning, testing, and policy, but not the same level of control over runtime identity and credential exposure.
Key questions
Q: What breaks when application security does not include identity controls?
A: Security breaks at the point where code safety ends and runtime access begins. If secrets are embedded, service identities are over-privileged, or access is not continuously monitored, attackers can use legitimate credentials to move through systems even when the code itself was scanned. The result is a control gap between development assurance and operational exposure.
Q: Why do overprivileged service accounts increase the impact of secret leakage?
A: Because the leaked secret authenticates the service account as itself, and the entitlement set determines how far that identity can move. If the account has broad storage, deployment, or API rights, an attacker inherits that scope immediately. Least privilege is what keeps a credential incident from becoming a wider compromise.
Q: What are the signs that application identity controls are failing?
A: Common signs include secrets appearing in source repositories or build artefacts, service accounts with broad or persistent permissions, and access events that do not match expected workload behaviour. Another indicator is when teams can scan code but cannot explain who can actually act at runtime. Those signals show governance has stopped at the pipeline.
Q: Should teams prioritise secrets management or broader DevSecOps coverage first?
A: Teams should usually start with secrets management and dependency risk because those are high-frequency, high-impact failure points with the clearest path to compromise. Broader coverage only helps if the team can act on it. The best sequence is to close credential exposure first, then expand toward code and runtime prioritisation.
Technical breakdown
Why identity controls sit inside application security
Application security does not stop at code correctness. Modern systems depend on identities that authenticate services, pipelines, and integrations, and those identities often carry broader access than human users ever should. When developers hardcode API keys, reuse secrets across environments, or grant service accounts persistent privilege, the application becomes a trust broker for the rest of the estate. That is why AppSec and IAM now overlap: the attack surface includes credentials, authorization rules, and the runtime pathways those identities open. Practical implication: treat application access as part of the identity control plane, not as a separate after-the-fact hardening task.
Practical implication: treat application access as part of the identity control plane, not as a separate after-the-fact hardening task.
How secrets exposure turns development pipelines into access paths
Secrets management is not just about storage, but about preventing credentials from becoming durable assets in code, logs, images, and CI/CD systems. A secret that lands in a repository or container layer can outlive the change that created it, especially when it is copied into multiple tools or environments. In practical terms, the security issue is not only theft but persistence: once a token or key is embedded, it can be used repeatedly until discovered and revoked. That creates a mismatch between development velocity and credential lifecycle governance. Practical implication: enforce continuous secret detection and rotation at commit, build, and deployment time.
Practical implication: enforce continuous secret detection and rotation at commit, build, and deployment time.
Why least privilege matters for runtime services and APIs
Least privilege is often discussed as an enterprise access principle, but in application environments it is a runtime containment mechanism. Service accounts, APIs, and workloads frequently inherit permissions broad enough to move laterally, query sensitive data, or trigger administrative actions if compromised. The article correctly ties strong identity and access controls to breach cost because the same credential that enables automation can also enable abuse. For practitioners, the control objective is not simply limiting who can log in. It is constraining what each non-human identity can do, where it can do it, and how long that authority lasts. Practical implication: map service permissions to business functions and remove standing access that exceeds task scope.
Practical implication: map service permissions to business functions and remove standing access that exceeds task scope.
Threat narrative
Attacker objective: The attacker wants to turn exposed application credentials into durable trusted access that can reach sensitive resources and support lateral movement.
- Entry occurs when developers or pipelines expose hardcoded secrets, API keys, or other credentials in code repositories, container images, or configuration files.
- Credential abuse follows when attackers use those valid secrets to access application assets and move through connected systems as trusted identities.
- Impact emerges as attackers reach sensitive resources, data stores, or administrative functions while remaining difficult to distinguish from legitimate service activity.
Breaches seen in the wild
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
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
Application security has become an identity governance problem disguised as a code-quality problem. Scanning and testing matter, but they do not govern who or what can act inside production once the application is running. The article’s real contribution is to show that secrets, service accounts, and API permissions are now first-order security assets. Practitioners should treat application security controls as part of IAM and PAM design, not as a parallel discipline.
Secret leakage is the named failure mode that keeps defeating mature AppSec programmes. Hardcoded credentials, repository exposure, and CI/CD propagation create a longer-lived attack window than most development teams expect. The governance gap is not merely theft of a secret, but the absence of a lifecycle model that assumes secrets will escape and must therefore be continuously found, scoped, and revoked. The practical conclusion is that exposure detection without rapid revocation remains incomplete control.
Over-privileged service identities create the blast radius that code scanning cannot see. Once a workload credential is broadly authorised, an attacker does not need to exploit the code path you tested if the identity itself grants access elsewhere. This is where identity and access management, privileged access governance, and application security converge. Teams should be measuring runtime privilege scope as aggressively as they measure vulnerability counts.
Application security programmes now need control-plane thinking, not only tool coverage. The article points to a stack of practices, but the deeper lesson is that all of them fail when policy stops at the repository and does not extend into runtime identity. That means governance over secrets, access, and auditability must be designed as one system. The practitioner takeaway is straightforward: if identity is unmanaged, AppSec is only reducing noise around the real risk.
Cycode’s analysis reflects a broader market shift toward identity-aware software security. Security leaders increasingly need a single view of code, pipeline, and runtime trust relationships because attackers move across those boundaries with ease. That does not replace AppSec tooling; it changes the governance question from 'is the code safe' to 'what identities can the code exercise'. The field is moving toward lifecycle controls that join software assurance with identity assurance.
What this signals
Identity-aware AppSec is becoming the control model that matters. The article shows why security teams can no longer treat credentials as a side issue to code quality. When service identities and pipeline secrets are part of production access, the programme needs one view of issuance, scope, monitoring, and revocation.
Continuous credential governance is now the differentiator between visible risk and invisible compromise. Teams that only review code will miss the identities that code exercises at runtime. The operational question is no longer whether a control found a vulnerability, but whether it can also stop a workload credential from becoming a standing access path.
Blast-radius control is the named concept that should shape AppSec design. The point is not to eliminate every flaw before release, but to make sure one leaked secret or one over-privileged service account cannot reach too far. Practitioners should align IAM, PAM, and AppSec around that containment objective.
For practitioners
- Enforce continuous secret scanning across code and pipelines Scan repositories, build logs, container images, and deployment artefacts for exposed API keys, tokens, and certificates, then revoke and rotate immediately when found.
- Scope service accounts to task-level permissions Review every non-human identity used by applications and CI/CD systems, remove standing access that is broader than the workload needs, and separate privileges by environment.
- Treat credential rotation as a release control Require rotation for secrets that are introduced, modified, or detected outside policy, and connect rotation to deployment approval rather than a loose maintenance cycle.
- Instrument runtime access anomaly detection Monitor unusual login patterns, API call volumes, and cross-resource access from service identities so that misuse is visible when a credential is abused in production.
- Make identity controls part of AppSec governance Include secrets hygiene, least privilege, and access review evidence in application security policy, audit prep, and developer enablement materials.
Key takeaways
- Application security programmes fail when they ignore the identity layer that powers modern pipelines, services, and APIs.
- The most dangerous gaps are not always code defects but exposed secrets, broad service permissions, and weak runtime monitoring.
- Practitioners need to align application security with identity governance so that credential scope, rotation, and revocation are treated as core controls.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on hardcoded and exposed secrets as an application security failure mode. |
| NHI-05 — Overprivileged NHI | Service accounts and API credentials with excessive scope are a core risk in the article. | |
| NHI-07 — Long-Lived Secrets | The article highlights the persistence risk created when secrets remain valid after exposure. | |
| Recommendation — Scan code, pipelines, and images for leaked secrets and revoke any exposed credential immediately. Review non-human identities for excess privilege and reduce each one to task-scoped access. Replace durable application secrets with short-lived credentials and enforce rotation on exposure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle controls directly govern rotation and revocation of application secrets. |
| Recommendation — Apply IA-5 to manage credential issuance, rotation, and revocation for application identities. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential theft leading to movement through connected systems. |
| Recommendation — Map exposed application secrets to credential-access and lateral-movement detections in your monitoring stack. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article argues that application access must be limited and governed as part of the security baseline. |
| Recommendation — Use PR.AA-05 to validate that every application identity has only the permissions it genuinely needs. | ||
Key terms
- Application Security Program: An application security program is the set of processes, tools, and policies used to protect software across its full lifecycle. It covers design, development, deployment, and production operations, with the aim of reducing exploitable risk while fitting the pace of modern delivery.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
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 security and identity teams connect application controls to the broader access model their programmes depend on.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org