Application security in 2026 depends on connected lifecycle control

At a glance

What this is: This is an Orca Security analysis of modern application security, showing that effective AppSec now has to connect code, pipelines, infrastructure, secrets, and runtime behavior across the full software lifecycle.

Why it matters: It matters to IAM practitioners because exposed secrets, over-permissive access, and lifecycle gaps all create identity risk inside software delivery, not just around it.

👉 Read Orca Security's analysis of application security across the full lifecycle

Context

Application security is no longer a single code-scanning exercise. Modern software changes continuously across development, build, deployment, and runtime, which means the security model has to follow the application instead of assuming a one-time review can capture the whole risk surface.

For IAM, NHI, and platform teams, the key issue is that secrets, service access, and configuration state now move with the software lifecycle. That makes application security a governance problem as much as a technical one, especially where build systems and runtime environments rely on credentials and connected tooling.

Orca Security frames this as a lifecycle problem rather than a point-in-time vulnerability problem, which is the right starting point for teams that need to connect code hygiene, CI/CD controls, and runtime context into one operating model.

Key questions

Q: How should security teams handle exposed secrets in modern application environments?

A: Treat exposed secrets as active identity incidents, not just code defects. Find them in source, logs, pipelines, and historical commits, then revoke, replace, and trace usage across systems that may already trust the credential. The important part is closing the access path, because a valid token can bypass traditional vulnerability management entirely.

Q: Why do modern applications make AppSec and IAM harder to separate?

A: Because the application now carries its own access logic through credentials, service permissions, deployment configuration, and runtime connections. Security teams are no longer only protecting code. They are governing which identities can move through the software lifecycle and what those identities can reach once the application is live.

Q: How do teams prioritise AppSec findings without drowning in alerts?

A: Start with reachability and exploitability in runtime, not with scan volume. A finding that is reachable in production and can be used under real conditions deserves faster action than a dormant issue buried in unused code. This approach turns AppSec from list management into risk triage.

Q: What should organisations do when CI/CD pipelines carry application risk forward?

A: Treat the pipeline as part of the attack surface and the governance boundary. Control who can change builds, who can inject secrets, and which deployment paths can promote insecure artefacts. If the pipeline is trusted implicitly, it becomes the fastest path from a small coding issue to broad production exposure.

Technical breakdown

Software composition analysis and inherited dependency risk

Software Composition Analysis, or SCA, maps open source and third-party dependencies so teams can identify known vulnerable components before they are embedded into applications. The limitation is context. A dependency may contain a known issue, but that does not tell you whether the vulnerable path is actually executed in your application or whether it is reachable in the runtime environment. That is why SCA is necessary but incomplete: it inventories inherited risk, but it does not answer exploitability on its own.

Practical implication: use SCA as a dependency discovery layer, then pair it with runtime reachability to separate theoretical exposure from actual attack surface.

Exposed secrets in code, logs, and pipelines

Exposed secrets are credentials, tokens, keys, or certificates that appear in source code, configuration files, commit history, logs, or pipeline artefacts. Unlike traditional vulnerabilities, this is direct access material. If an attacker finds a valid secret, they do not need to exploit a code flaw to reach systems, APIs, or cloud services. The article correctly treats historical secrets as part of the modern application footprint, because once a secret is committed or logged, it often outlives the code change that exposed it.

Practical implication: search for secrets across code, CI/CD output, and historical commits, then treat revocation and replacement as part of the remediation path, not an optional follow-up.

Runtime reachability and exploitability

Runtime reachability asks whether there is a real path from application entry points to a vulnerable component. Exploitability goes one step further and asks whether an attacker can actually use that path under real-world conditions. This distinction is central to modern AppSec because it prevents teams from treating every scanner result as equally urgent. A vulnerable library buried behind an unreachable code path is not the same as a flaw exposed in an active service path. Runtime context is what reveals that difference.

Practical implication: prioritise findings that are both reachable and exploitable in production, and use runtime context to de-prioritise issues that do not present an active path.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Modern AppSec is now an identity governance problem, not just a code quality problem. The article shows that applications are assembled from code, dependencies, secrets, pipelines, and runtime services, each of which carries access implications. Once credentials, service permissions, and deployment logic become part of the software system, IAM and NHI governance have to extend into the delivery chain. Practitioners should treat application security as a lifecycle governance discipline, not a scan-and-fix workflow.

Exposed secrets are the clearest example of identity risk moving inside the application lifecycle. API keys, tokens, and certificates are not abstract security objects, they are live identity artefacts that can grant direct access without a software exploit. That means the security problem is not limited to secret discovery. It also includes where secrets are created, where they are copied, and how long they remain valid after exposure. The implication is that secrets management and AppSec are now operationally inseparable.

Runtime context changes how teams should think about blast radius. The article’s reachability model is a reminder that finding a weakness is not the same as finding an exploitable path. That distinction matters because identity-controlled access inside applications can be over-scoped long before it becomes visible in production. Practitioners need a governance model that ties privilege, execution path, and runtime exposure together, rather than relying on siloed controls.

Modern application security depends on continuity across the SDLC, not checkpoints inside it. The article’s main lesson is that siloed tooling creates fragmented signals, which slows remediation and inflates noise. That fragmentation is especially costly when applications depend on NHI-like service access across build and deploy stages. Practitioners should expect AppSec to converge with NHI governance, cloud posture, and pipeline control as one operating model.

Cloud-to-dev visibility is becoming the named operating concept for this category. The strongest position here is that teams need a single view from development through runtime if they want to understand what is actually exploitable. That concept matters because it collapses the false separation between application security, infrastructure security, and identity governance. Practitioners should design for connected context, not disconnected findings.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
• For a broader control lens, NHI Lifecycle Management Guide helps teams connect provisioning, rotation, and offboarding to the same access-risk problem.

What this signals

Cloud-to-dev visibility: the practical shift is toward one control plane that can follow application risk from code creation to runtime execution. When teams cannot connect identity, pipeline, and production context, they end up remediating symptoms instead of the access paths that create exposure.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, the problem is no longer isolated leakage but industrial-scale credential churn. That scale means practitioners need continuous discovery, revocation, and ownership mapping across the software lifecycle.

For teams aligning to external control frameworks, the governance model should be tied to NIST Cybersecurity Framework 2.0 outcomes rather than to scanner coverage alone. The right measure is whether the organisation can identify, protect, detect, respond, and recover across both application and identity layers.

For practitioners

• Map application access paths end to end Trace where credentials, service accounts, and deployment permissions are created, copied, stored, and consumed across code, CI/CD, and runtime. The goal is to understand which identities can actually reach production systems and where privilege is broader than the application needs.
• Separate reachable risk from theoretical findings Use runtime context to distinguish vulnerabilities that sit behind real execution paths from those that appear in scans but are not reachable in production. This reduces alert fatigue and shifts remediation effort toward issues that can be exploited.
• Search for secrets beyond source code Include commit history, logs, pipeline output, and configuration artefacts in secret discovery. Historical exposure matters because a valid token in a forgotten location can remain a live access path long after the original code change is fixed.
• Connect AppSec and identity governance workflows Bring application security findings into the same governance process that manages access, privilege, and remediation ownership. That is the only way to keep code, pipeline, and runtime controls aligned when applications change continuously.

Key takeaways

• Modern AppSec fails when teams treat code, pipeline, and runtime as separate problems instead of one connected risk surface.
• Exposed secrets turn application security into direct access governance because a valid credential can bypass a traditional vulnerability chain.
• The most defensible prioritisation model is reachable and exploitable risk, not raw scan volume or checklist coverage.

Key terms

• Application Security: Application security is the practice of protecting software across development, deployment, and runtime. It covers code, dependencies, secrets, infrastructure, and execution behaviour, because any one of those layers can expose data or access if it is not governed as part of the same lifecycle.
• Exposed Secret: An exposed secret is a credential, token, API key, or certificate that appears in a place where it can be discovered and reused. In practice, it becomes a direct access path, so discovery alone is not enough. The credential usually has to be revoked, replaced, and traced through dependent systems.
• Runtime Reachability: Runtime reachability is the question of whether a vulnerable component can actually be reached in a running application. It helps teams separate theoretical defects from real attack paths, which makes prioritisation more accurate and reduces noise from findings that do not translate into exploitable exposure.
• CI/CD Pipeline: A CI/CD pipeline is the automated path that builds, tests, packages, and deploys software. It matters to identity security because it often contains credentials, trusted service accounts, and promotion logic that can carry a small issue into production very quickly if the pipeline itself is not controlled.

Deepen your knowledge

Application security, secrets exposure, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model that has to span code, pipelines, and runtime, it is worth exploring.

This post draws on content published by Orca Security: Application Security (AppSec) across the full lifecycle. Read the original.