Developers don't ignore security. They ignore lists they can't act on.
Security that arrives in the pull request, names one thing to do, and explains why it matters — instead of a dashboard nobody has a reason to open.
The "developers don't care" story is wrong
It's also a convenient excuse for tools that were never designed for them. Look at what a developer actually receives:
- A list of 400 items with no order, no owner and no context
- A ticket about a service they have never touched
- A "critical" that turns out to be unreachable, twice in a row — after which every critical is noise
- A dashboard on another platform, behind another login, that they would have to remember to visit
- A gate that blocks a release on a Friday with no explanation
Any engineer optimizes the same way under those conditions: ignore the channel with the worst signal-to-noise ratio. That isn't apathy. Given those inputs, it's correct behaviour.
Meanwhile the AppSec engineer — often one person for eighty developers — becomes both a bottleneck and a bearer of bad news, which is an efficient way to burn out a role that is already hard to hire for.
Change what developers receive
- In the pull request, not in a portal. Risk feedback arrives as a comment, in the review they're already reading.
- One thing, not four hundred. Ranked by actual risk contribution, so the top of the list is genuinely the top.
- With a reason. "Reachable from your public checkout endpoint" is actionable. "CVSS 9.8" is trivia.
- With the fix and its effect. The upgrade to apply, and what it does to the score.
- Without becoming a gate on day one. Inform first, enforce later, and only where it has earned the right.
- Owned by the right team. Findings map to services and owners, so nobody triages someone else's code.
For Security Champions and AppSec engineers the shift is bigger: instead of chasing individual findings, you set the risk model and let it distribute the work. You move from doing triage to designing how triage happens.
Why it matters
AppSec doesn't scale by adding scanners. It scales when the people writing the code make slightly better decisions, continuously — and that only happens if the information reaches them at the moment of the decision, in a form they can act on.
Every tool that gets ignored also costs something that never appears on the invoice: it teaches your team that security alerts are safe to skip. That habit is expensive, and it is hard to undo.
The honest test of a security tool isn't coverage. It's whether developers open it a second time without being asked.
A practical example
The same information, delivered two ways:
What a developer used to get:
Subject: Weekly security report — 412 open findings (37 critical)
Opened: no.
What a developer gets now, in the PR they already have open:
🔎 M.A.R.I.A. — Risk 41 → 58 (+17)
jsonwebtoken 8.5.1 adds a critical auth bypass (CVE-2022-23529),
and this service handles login.
Bump to 9.0.0 → this PR becomes −6 instead of +17.
Time to read: 8 seconds. Time to act: one line in package.json.Illustrative example
That's the whole thesis. Not more findings — findings at a moment when acting is cheap, with enough context to be worth eight seconds.
See what your team would actually see.
If this is the argument you've been making internally, this page was written to be forwarded.