Notifications
Clear all
Topic starter
18/08/2026 2:28 pm
TL;DR: Developer and security teams still fail most often because siloed workflows, unclear ownership, and mismatched priorities turn vulnerability handling into a handoff problem rather than a shared control loop, according to Probely. The real issue is not cooperation in theory but whether security signals flow into developer tooling fast enough to change remediation behaviour.
NHIMG editorial — based on content published by Probely: Breaking Down Silos: Collaboration Between Developers and Security Teams
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams integrate application security findings into developer workflows?
A: Security teams should push findings into the tools developers already use, such as pull requests, CI/CD checks, and issue trackers.
Q: Why do siloed development and security processes increase vulnerability risk?
A: Siloed processes increase risk because detection, prioritisation, and remediation happen in different systems with different owners.
Q: What do organisations get wrong about enforcing security in developer workflows?
A: They often enforce too early.
Practitioner guidance
- Integrate findings into developer workflows Route security issues directly into CI/CD, source control, and ticketing systems so developers can act without manual handoffs.
- Create one remediation ledger Maintain a single view of ownership, severity, status, and verification so security and development teams are working from the same record.
- Prioritise fix-ready findings Require scanner output to include the failing file, vulnerable component, exploit condition, and the minimal safe fix.
What's in the full article
Probely's full article covers the operational detail this post intentionally leaves for the source:
- How developer-friendly scanning output is embedded into existing engineering workflows without creating extra handoff steps
- Examples of shared visibility between SAST and DAST teams that reduce duplicate effort and conflicting remediation decisions
- The practical mechanics of aligning ownership, validation, and reporting across development and security teams
👉 Read Probely's analysis of developer-security collaboration and workflow silos →
Developer-security collaboration , where the governance gap really is?
Explore further
18/08/2026 3:16 pm
Siloed security is now an application governance failure: when developers and security teams do not share the same risk view, the organisation loses speed and control at the same time. The issue is not whether either team cares about security, but whether their workflows produce a single, executable remediation path. In practice, that makes application security, secrets handling, and IAM-adjacent controls harder to govern consistently. Practitioners should treat workflow integration as a control requirement, not a collaboration slogan.
A question worth separating out:
Q: How do you know if shared security visibility is working?
A: It is working when findings move from discovery to verified closure with minimal manual chasing, and when both teams can see the same status at the same time. You should also see fewer duplicate findings, faster prioritisation, and less disagreement about who owns the next step.
👉 Read our full editorial: Developer-security collaboration is now a control problem, not a culture one
