Software Developers : Scapegoats For Security Vulnerabilities

Nowadays there is a wide variety of security layers used by organizations at different stages of the software development life cycle. Static code analysis, dynamic analysis, penetration tests, bug bounty programs, or manual findings all offer different frequencies and different coverage levels to catch vulnerabilities.

Software developers need to deal with all vulnerabilities coming from these different sources while ensuring that they release new features or new applications within the deadlines.

Under the pressure of releasing applications at the speed of DevOps, security is not a luxury every software developer can afford.

Nevertheless, with the rising trend of secure coding, they are also the ones that are asked to change the way they work and code with security in mind.

However, while we ask them to give up some deeply rooted habits, how many of us would really embrace a change when there is no upside to it?

When it comes to sales teams, we rarely question the reasoning behind bonus programs. No one claims it is their job to try to close more deals and they should not be paid extra for hitting their targets.

On the contrary, almost everyone thinks that when sales teams go the extra mile, the company also benefits from it by generating extra revenue, and therefore it makes sense to share the extra profit with them.

But doesn’t the same apply when software developers write more secure code? Instead of generating more revenue, by coding securely, they prevent loss of reputation or loss of sensitive data which can not be restored even if you spend millions of dollars.

It’s a myth that software developers do not really care about security or take it lightly. At the end of the day, no one wants to build something easily penetrable and destructible by outside attackers.

The real problem is when it is time to evaluate their performance, most of the time secure coding is not one of their KPI’s.

If security is not among the things talked about in 1:1’s with team leads or one of the indicators of their performance, it is only natural for them to focus on other tasks with higher priorities to stay afloat.

When you want to improve your security posture and reduce your exposure to code-related vulnerabilities, how can we create a win-win scenario and talk developers into change?

Let’s picture the ideal world we want to create. First, we want our software developers to be mindful of security and create as few vulnerabilities as possible. Second, we want them to remediate vulnerabilities in the agreed-upon time frames.

As we have tipped off before, we see the problem more as a cultural one that requires a change in the way the performance of software developers is assessed. Without a security-driven culture embedded in the KPI’s of software developers, unfortunately security is destined to be an afterthought.

We know cultural problems are not solved in one day and we need baby steps towards our ideal world.

As a start, we recommend picking a certain vulnerability type (e.g. Injection) that you believe could be most devastating for one pilot project.

Once you know the persona non-grata vulnerability type, it is time to set a target fix time for these vulnerabilities. 3 days, 10 days, or 20 days. That is totally up to the flexibility of your development pipeline, frequency of your releases, and your risk perception.

What matters most at this point is just to come together with software developers and not leave the table until you come to an agreement and everyone commits to the targets that are mutually decided.

If there are outstanding vulnerabilities from the selected type, at the end of the agreed time frame, set a meeting with software developers and have your first retrospective analysis on what went wrong and what went well. Then, try to turn these meetings an integral part of their sprint planning so that vulnerabilities make their way into work items in each sprint.

When you are certain that vulnerabilities are fixed within deadlines in this pilot project, gradually roll out your approach for a larger set of projects and new vulnerability types.

Along with making security coding a KPI, when you give developers visibility into the security posture of what they are building and let them track their remediation metrics through a platform like Kondukto, you will quickly experience a dramatic change in their approach towards vulnerabilities.

Instead of being ignored or treated as second class citizens, secure coding and remediation of vulnerabilities will become a means to stand out in the crowd for your developers. They will be hot topics in their internal conversations and even part of the feedback they receive from team leads.

As well as comparing the actual remediation speed with target rates, one other KPI we strongly recommend is the recurrence ratio of vulnerabilities to get closer to our ideal world where software developers do not create the same vulnerabilities over and over again.

When you observe the same types of vulnerabilities are created by certain teams or developers you can create customized training programs to help them improve their security knowledge.

Secure coding is an unstoppable trend and security is expected to be one of the traits that tell an excellent developer from a good developer in the near future. When you help them improve their security skills, they will obtain a lifelong asset that will give them a competitive advantage.

So, don’t shy away from introducing secure coding as a KPI for your software developers. The better they perform, the safer is the company, and the higher they are valued. Just be transparent in why you have to do this and clearly explain how they will also benefit from it.

Tell them the definition of a good developer is not the same as it was 10 years ago and will not be the same 10 years later. Secure coding will be one of the indispensable characteristics looked for when hiring software developers in the coming years.

To be fair to your existing developers and to make newcomers easily fit into your culture, make secure coding one of the characteristics you look for when you are hiring new developers.

To prevent paranoia and fear of punishment, try to create an environment of trust where you encourage secure coding by helping poor performers improve their skills through custom training programs.

Start the change with yourself to ask it from developers. Only then, the change will be embraced rather than resisted. Be the change you want to see.