Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: Security issues in software delivery often persist because development and security teams operate with different priorities, language, and tooling, making late-stage fixes expensive and demoralising, according to Probely. The practical challenge is not awareness but shared governance, because secure delivery fails when controls are bolted on after release pressure has already shaped the workflow.
NHIMG editorial — based on content published by Probely: security alignment between development and security teams
By the numbers:
- 72% of vulnerabilities in web applications are detectable and preventable.
Questions worth separating out
Q: How should security teams implement SecDevOps without slowing delivery?
A: Start with advisory controls, not blocking gates.
Q: Why do security controls often fail in fast-moving CI/CD environments?
A: They usually fail because they arrive too late or ask for manual work at the point where teams are optimising for speed.
Q: What do teams get wrong about security training for developers?
A: They often treat training as a separate event instead of a workflow intervention.
Practitioner guidance
- Build a shared security glossary for delivery teams Create a short, controlled vocabulary for the terms that most often cause review failures, especially around access, secrets, privilege, and pipeline exceptions.
- Move security checks into the developer workflow Embed scanning and policy checks in the CI/CD path where engineers already work, so findings appear before code is merged or promoted.
- Define shared KPIs for speed and control Use a small set of metrics that track release velocity alongside vulnerability age, remediation latency, and exception volume.
What's in the full article
Probely's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor frames developer-security collaboration inside CI/CD and release workflows
- The specific examples it uses to explain why generic security training fails with developers
- The way it positions AI-native remediation guidance as a workflow aid rather than a standalone control
- The practical context behind its references to DAST, SAST, and in-pipeline feedback
👉 Read Probely's analysis of developer-security alignment in modern DevSecOps →
Development-security alignment: what teams need to fix first?
Explore further
19/08/2026 4:17 pm
Misalignment is a control problem, not a culture problem. The article frames tension between development and security as a communication issue, but the deeper issue is governance drift across the software delivery lifecycle. When teams do not share a control vocabulary, security requirements are interpreted inconsistently and enforcement becomes ad hoc. That is why a cross-functional glossary can help, but only if it is embedded into operational decisions and ownership models.
A question worth separating out:
Q: How can organisations measure whether development and security are actually aligned?
A: Look for shared outcomes, not just attendance or policy completion. Useful signals include shorter time to remediate, fewer late-cycle security rework items, and fewer exceptions that recur across releases. If security review still creates repeated handoff delays, the teams are coordinating, but not aligning.
👉 Read our full editorial: Development-security alignment is the real DevSecOps bottleneck
