Notifications
Clear all
Topic starter
18/08/2026 2:18 pm
TL;DR: Effective application security depends less on warnings than on training that uses real vulnerabilities, shows concrete impact, and resets the relationship between security and developers, according to Probely. The practical lesson is that AppSec governance fails when teams treat discovery as blame rather than as a shared control to improve.
NHIMG editorial — based on content published by Probely: Balancing Act: The Six Keys to Successfully Navigating Security and App Development Team Tensions
Questions worth separating out
Q: How should security teams reduce AppSec friction in modern delivery pipelines?
A: Start by moving security checks into the tools developers already use, such as pull requests, CI/CD stages, and code review workflows.
Q: Why do AppSec tools lose credibility with engineering teams?
A: They lose credibility when they generate noisy, unclear, or incorrect findings and then ask developers to spend time on them.
Q: What do organisations get wrong about vulnerability discovery?
A: They often treat discovery as proof of risk.
Practitioner guidance
- Build evidence-based AppSec training Use internal vulnerabilities, real exploit paths, and short demonstrations that show how a defect turns into data exposure, impersonation, or service abuse.
- Remove blame from vulnerability discovery Frame findings as normal engineering outcomes, not personal failures, and reinforce that discovery is useful only when it changes design and remediation behaviour.
- Measure scanner credibility before scaling it Track false positives, unclear severity assignments, and the percentage of findings developers reject as non-actionable.
What's in the full article
Probely's full blog post covers the operational detail this analysis intentionally leaves at the governance level:
- Examples of how the author structured internal vulnerability examples for developer-facing training
- The specific ways the team explained exploit impact to reduce resistance to remediation
- How the author balanced security expectations against development constraints in day-to-day workflows
- The tooling characteristics that made security findings easier for developers to act on
👉 Read Probely's analysis of security and development team friction →
AppSec training and developer trust: what actually closes the gap?
Explore further
18/08/2026 3:10 pm
AppSec friction is usually a governance problem before it is a technical one. When development and security teams use different evidence, different severity thresholds, and different language, remediation slows even if the tooling is adequate. This is why training quality matters as much as scanner quality. In identity-heavy environments, the same pattern shows up when access reviews or secrets controls are presented as compliance chores rather than operational risk. The conclusion is straightforward: shared understanding is a control surface, not a soft skill.
A question worth separating out:
Q: How do security teams know whether AppSec findings are actually working?
A: Look at fix acceptance, false positive rates, time to remediate, and the volume of repeated findings. If engineers ignore alerts or remediation drags on, the programme is generating output without control. Effective AppSec changes behaviour, shortens exposure windows, and improves trust in the signal.
👉 Read our full editorial: AppSec training works when security and developers share evidence
