How do you make developers fix SAST findings?
Stop hunting SAST findings. That's the wrong target.
If you run an AppSec program, you eventually introduced some kind of SAST scanner into your CI/CD pipeline. You put in all that effort comparing 10, 20, or even 30 different vendors to finally find the best scanner out there. You ran that PoC and convinced your management to finally invest in your favorite tool.
Now all the developers need to do is fix all those critical and high-severity findings the scanner made visible within their codebase.
They should thank you! You made their work so much easier.
Instead, they let you down. They are not fixing anything. Not even the critical ones. How can they be so lazy? Or careless? Or both?!
You are the one who needs to explain to your management why your company invested so much money in a tool that has literally no impact on software security.
Calm down, there is a solution. Developers are friends, not enemies. And the problem isn't their attitude. It's the deal you're offering them.
Why developers don’t fix SAST findings
As a developer, I was the exception. I loved fighting technical debt, fixing SAST findings and updating libraries more than building the next stupid feature our customer asked for. Why would anyone prioritize changing a button color while the application has more holes than Swiss cheese?!
I annoyed my project leaders every day, because I wouldn't work on that feature request without arguing about security or technical debt or both. If you have developers on your team who are like that, you are lucky. Remember their names. You will need them.
For everyone else, SAST findings are just another annoying task on their desk. You have so many bug fixes that take forever to figure out why the application behaves in a certain way under certain circumstances. And the customer might already be angry, because their customers keep complaining about these bugs.
As a developer, you probably did not sign up dreaming of maintenance. You imagined building cool features. Creating something that will add value. Something you can be proud of.
Instead, you lose day after day, hour after hour, fighting all those side-quests. Bugs, vulnerabilities, dependency updates, technical debt and who invented those stupid unit tests?
Chainguard asked 1,200 software engineers and tech leaders how their week actually breaks down. The numbers are hard to ignore. Engineers spend only 16% of their time writing code and building new features. The other 84% goes to maintenance, patches, vulnerability remediation, and other toil. And 93% of them say that 16% slice is the most rewarding part of their job.
16% of time spent on work you love. 84% for everything that keeps you from it. Developers are neither careless nor lazy.
They are just protecting those few hours when they can actually do what they love.
Why you don’t want developers to fix SAST findings
Let us step away from security for a moment.
My dog Suschka has something she loves more than everything else: hunting. Mice, squirrels, cats, reindeer – she even tried to keep up with a chamois once. For her, running behind a deer or digging for mice is the best thing in the world.
Of course, I cannot let her freely hunt other animals for fun. She would harm them and could even cause accidents when she crosses a street at full speed behind that deer.
So she needs to be on a leash in the forest. But keeping her on leash all the time?
That’s managing the problem, not solving it.
Same thing in AppSec.
Fixing SAST findings is managing the problem, not solving it.
Why would you want your developers to fix SAST findings?
Nobody wins when time is spent that way. You want them to build features your company can sell to make money. That is their job and that is what they love doing.
What do we want instead?
Let us come back to our little hunting story.
My dog trainer told me to establish a special command that promises a really big win for Suschka, e.g., sausages. The idea is simple: she can’t hunt a cat and turn toward me at the same time.
I would need to find something that is more rewarding to her than hunting or at least a safe win. When I then reward the turn, the hunting dies out on its own.
This approach is called Differential Reinforcement of Alternative Behavior (DRA). It's a core technique in applied behavior analysis: instead of punishing the problem, you reinforce an incompatible alternative.
We started small. After a few weeks of training I was eventually able to stop her from hunting a cat. She spotted the cat and prepared to hunt as usual. Bambi! My timing was good. She turned towards me and asked for her sausage. YES! It’s working!
Sure, that was just one cat and she had not been in the hunting tunnel already. But it was a first step.
She had begun to slowly shifther default behavior from ‘Oh, cat! Bye!’ to ’Hey, see that cat? Gimme my sausage!’
It is all about timing. When I reward Suschka after she had already hunted that cat, she is not replacing the old behavior with the new one. I just taught her that she can have fun hunting and get her sausage on top.
For developers, it is even worse. They don’t love fixing SAST findings. Any reward you provide for fixing SAST findings will only compensate for the hours you kept them from doing what they love (building cool features) and what makes your company earn money.
Fixing SAST findings is a win for security and a lose for everyone else.
How do you create a win for everyone?
You have a big advantage when dealing with SAST findings. They are a self-caused problem and follow patterns. I cannot prevent cats from crossing our path, but that is exactly what you need to aim for. You can step in earlier in the chain and remove the trigger, instead of fighting the consequence.
When you accomplish that, your developers can spend time on building features, your company can sell software and your stats are green.
Win. Win. Win.
We cannot go back in time and stop the existing SAST findings before they entered your code base. That is security debt we need to deal with, no matter how annoying it is. But those findings are valuable signals you can use to prevent future SAST findings.
What do we hunt instead?
You start by looking at what your SAST tool already tells you. Not the findings themselves. The patterns behind them.
Spot the insecure pattern.
Every SAST finding has a shape. SQL injection doesn’t appear randomly. XSS leaves fingerprints. A handful of patterns cause the majority of your critical findings. Find them. Start with the one that generates the most noise. That’s your first target.
Define the secure version.
What does the code look like when the developer does it right? That becomes your standard. Not the finding. The correct pattern. That’s your command, which promises them this delicious sausage.
Automate the feedback.
When a developer writes code that matches the secure pattern, the system should recognize and reward it.
When they don’t, the system should block the insecure pattern and suggest the secure one. That’s your long leash that prevents the hunting approach just in case.
When they then switch to the secure pattern? Reward it.
That’s DRA applied. Developers cannot use the insecure pattern and the secure one at the same time. Every time they use the secure pattern and get a green light, that’s one step towards the new secure default behavior.
Your system needs to reward the secure pattern in real-time, so the insecure one stops appearing.
Start with one pattern. The one that hurts most.
When you witness your developers choosing the secure pattern over the insecure one, it’s time to celebrate your win and expand your system to dry out more insecure patterns.
A nice side-effect is that the metric of secure vs. insecure pattern usage is perfect proof that your AppSec system actually improves software security.
I want to strengthen one last important point. This approach is not about manipulating or tricking your developers into showing the behavior you want to see.
It’s about cooperation.
In the end, you all share the same goal: maximize the time your developers can spend building cool features while still producing secure software. When you reward the secure pattern instead of punishing the insecure one, you’re not playing mind games. You’re making the secure path the easy path. You’re removing friction.
That’s not manipulation. That’s good system design.
Subscribe for weekly insights on building resilient AppSec systems that improve software security even when the road gets rough.