TL;DR: AppSec friction with development is the top pain point for 39% of respondents in OXSecurity’s FS-ISAC 2024 Americas Fall Summit poll, ahead of alert fatigue at 19% and DevOps integration gaps at 18%, showing that disconnected workflows now delay releases and leave remediation too late. Security becomes a delivery control problem when findings arrive without code, pipeline, and runtime context.
At a glance
What this is: This article argues that AppSec and development misalignment has become a delivery risk because late, disconnected security feedback slows releases and leaves vulnerabilities exposed in production.
Why it matters: It matters to IAM, NHI, and broader security teams because fragmented workflows, ownership, and remediation context create governance gaps that attackers can exploit after deployment.
By the numbers:
- AppSec friction with development was the top pain point for 39% of respondents in OXSecurity’s FS-ISAC 2024 Americas Fall Summit poll.
- Lack of integration with DevOps tools received 18% of votes in OXSecurity’s poll.
- Alert fatigue and prioritization accounted for 19% of votes in OXSecurity’s poll.
Context
AppSec misalignment is not just a workflow nuisance. When security findings arrive after code is shipped, they create rework, delay releases, and force teams to decide between velocity and control.
The governance gap is that development and security often operate with different tools, metrics, and language, so findings lack the context needed for fast remediation. That problem is especially relevant to identity and access governance wherever application changes affect secrets, service accounts, or runtime permissions.
Key questions
Q: What breaks when AppSec findings are not routed into developer workflows?
A: Findings lose context, ownership becomes unclear, and the work shifts into tickets and handoffs that developers tend to deprioritise. The result is longer remediation cycles, growing backlog, and weaker control over how long a vulnerable change remains exposed before release.
Q: Why do disconnected development tools increase risk in modern software delivery?
A: Disconnected tools create blind spots. When code analysis, security findings, and operational data live in separate systems, teams lose the context needed to judge severity and business impact. That makes it harder to enforce consistent standards, correlate vulnerabilities across the SDLC, and keep AI-assisted development aligned with the organisation’s security and quality controls.
Q: What do security teams get wrong about appsec alert volume?
A: They often treat more findings as more security, when the real problem is whether the findings are true, reachable, and worth fixing. High alert volume can mask critical exposure and exhaust engineering capacity. A mature programme should optimise for verified impact, not for the number of issues it can generate in a report.
Q: How should organisations align developers and security teams in AppSec?
A: They should treat AppSec as a shared operating model, not a handoff after code is finished. That means training developers with evidence from real findings, using tools that explain issues clearly, and setting remediation expectations that fit delivery realities. Trust improves when security helps teams ship safely, not just block release.
Technical breakdown
Why late AppSec findings become a delivery bottleneck
When application security checks run late in the SDLC, they detect issues after engineering teams have already committed time to release work. That creates a queue of rework because the issue must be triaged, traced, reproduced, and revalidated before deployment can continue. In practice, the cost is not only delay. Late discovery also weakens prioritisation because teams see a generic finding rather than a code-level, pipeline-aware risk with clear ownership. The result is a control that exists in theory but fails operationally because it is detached from the delivery path.
Practical implication: Push security feedback into the same pipeline and review points where code is already being changed.
Why disconnected toolchains undermine remediation quality
A scan result without source context is hard to act on. Developers need to know which function, dependency, or deployment path is affected, and AppSec needs to preserve that traceability across CI/CD, runtime, and third-party scanning tools. Without that correlation, the finding may be accurate but still unusable, which is why teams experience both friction and slow remediation. This is also where the identity angle appears: insecure handling of secrets, tokens, and service credentials often sits inside code and pipeline artifacts, so poor integration hides the real trust boundary.
Practical implication: Correlate findings back to code, build, and runtime context before routing them to engineering.
Why alert fatigue weakens security prioritisation
Alert fatigue happens when teams receive too many low-confidence or duplicate findings, which makes high-value issues harder to distinguish. Security teams then spend effort proving that the signal is real, while developers learn to treat findings as background noise. In governance terms, this is a measurement problem as much as a tooling problem because volume is being used as a proxy for coverage. The better model is risk-based triage that considers reachability, exploitability, and business impact, not just severity labels. That changes AppSec from a scanner into a decision support function.
Practical implication: Score and route findings by exploitable risk, not by raw alert count.
Threat narrative
Attacker objective: Exploit production-facing weaknesses that slipped past late AppSec controls and remain unpatched after release.
- Entry occurs when a vulnerability is discovered only after deployment, giving the organisation no chance to block the release before exposure.
- Credential or code-path abuse follows when the weakness reaches production and becomes reachable through live application behaviour, including exposed secrets or unsafe permissions.
- Impact is delayed remediation in production, which keeps the weakness open long enough for exploitation and creates avoidable business disruption.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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
AppSec misalignment is now a governance failure, not a tooling inconvenience. When development and security measure success with different clocks, late findings turn into release blockers and organisational waste. The real issue is that the control plane is split across delivery and assurance, so no one owns the full path from code change to production risk. Practitioners should treat this as a governance design problem, not a communication problem.
Contextless findings create remediation debt. A vulnerability ticket without code, build, and runtime context forces developers to reverse-engineer the issue before they can fix it, which is why tickets age out or get deprioritised. That is especially relevant where application changes affect secrets, service accounts, or other non-human identities embedded in deployment workflows. The practitioner lesson is to move from alert generation to traceable risk explanation.
Risk-based prioritisation is the named concept here: AppSec signal translation. The article’s core point is not that teams need more findings, but that findings must be translated into the developer’s operational language with reachability, exploitability, and business impact attached. That aligns with broader secure delivery thinking in NIST CSF and CIS Controls, where outcome quality matters more than raw detection volume. Practitioners should optimise for decision quality, not alert count.
Shared ownership is the only durable operating model. When security stays outside engineering workflows, the organisation pays twice, first in delayed releases and then in deferred remediation. Embedding accountability, security champions, and shared metrics makes security part of the delivery system rather than a downstream veto. The practical conclusion is that secure software delivery depends on joint accountability, not handoffs.
What this signals
AppSec signal translation is the operating gap teams should watch. Findings only become useful when they are translated into the language of the delivery team, with code path, ownership, and exploitability attached. Without that translation layer, security becomes a queue of tickets rather than a control that changes engineering behaviour.
Security leaders should expect more pressure to prove whether AppSec findings are actually actionable, not merely numerous. That shifts attention toward developer experience, remediation velocity, and whether the control is influencing release decisions early enough to matter.
For practitioners
- Embed AppSec checks in delivery pipelines Run security scanning inside CI/CD and pull-request workflows so developers see issues where code is still being changed.
- Add source and runtime context to findings Correlate each finding to the affected function, dependency, build step, and deployment context before assigning remediation work.
- Prioritise exploitability over raw severity Rank issues using reachability, exploitability, and business impact so teams focus on the findings most likely to matter in production.
- Create shared remediation ownership Use security champions, cross-functional standups, and shared KPIs such as mean time to remediation and remediation velocity.
- Train developers on secure coding decisions Provide role-specific workshops and code review feedback that help engineering teams recognise how insecure patterns affect release risk.
Key takeaways
- AppSec and development misalignment becomes a delivery risk when security findings arrive too late to shape release decisions.
- The core weakness is not a lack of effort but a lack of shared context, which turns remediation into rework and noise.
- Teams reduce this risk by embedding security into delivery workflows, translating findings into engineering language, and measuring outcomes that reflect real remediation speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, OWASP SAMM and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AppSec failures often expose unsafe app permissions and runtime access paths. |
| Recommendation — Review application entitlements and release workflows to ensure only intended access survives deployment. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about shifting security left into the software delivery process. |
| Recommendation — Embed application security checks into development and release workflows under CIS-16. | ||
| OWASP SAMM | Security Testing — Security Testing | The piece centres on integrating security testing with the SDLC and engineering cadence. |
| Recommendation — Use Security Testing maturity criteria to measure whether findings are arriving early enough to matter. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article stresses code-level context and secure design decisions inside engineering workflows. |
| Recommendation — Apply V15 to make security feedback part of architecture and coding decisions, not a post-release gate. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Late AppSec remediation can leave exposed secrets or credentials reachable in production. |
| Recommendation — Map exposed secrets and unsafe runtime permissions to TA0006 and prioritise them for remediation. | ||
Key terms
- Application Security Testing Service: A managed or platform-based delivery model for finding and prioritising software vulnerabilities across code, dependencies, secrets, containers, and infrastructure. It combines scanning with workflow integration and often adds remediation support, reporting, and governance features for enterprise development teams.
- Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
- Remediation velocity: The speed at which an organisation can move a finding from validation to verified closure. It is a practical measure of security execution, not just detection maturity, and it often depends on asset ownership, change control, and the surrounding access model.
- Security Champion: A security champion is a team member inside a delivery group who helps translate security requirements into day-to-day engineering practice. The role reduces bottlenecks by giving teams a trusted local guide, while central security keeps policy, standards, and escalation paths consistent.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and engineering practitioners connect identity controls to the broader delivery and risk model their programmes depend on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org