5 reasons why developers can’t just morph into security champions

With an explosion of software-driven tech making way for the rapid growth of cyber security incidents in the last decade, we’re all scrambling to keep up with threat actors working around the clock to uncover exploits in valuable systems.

That scramble doesn’t just impact the security team; security should be a shared responsibility.

In software, developers are being asked to do their part, by learning and applying secure code practices to their work. Security and engineering teams may aid in this by incorporating secure coding and security guidelines into the technology stacks and workflows that developers use, thereby ensuring that the fabric for creating new software and applications is, to a basic level, secure.

The code created using these guardrails and on top of these fabrics also needs to be secure as well.

For that to happen, developers need to make security part of their own DNA. They need to be open to critically analysing their existing code patterns and altering those patterns to meet current security best practice.

Developers need support in this regard: from their employers, managers, operations and security teams. Change won’t happen by osmosis. It requires cooperation and a shared commitment and mindset, backed up by comprehensive training and an embrace of newer security-oriented methodologies and standards.

Unpacking the developer disconnect

Security leaders can go a long way to improving initial awareness and identifying areas of the most pressing knowledge gaps, by ensuring that the development cohort is shown the complete picture of what secure coding entails.

VIEW ALL

Recent research produced in collaboration with Evans Data shows just 14 per cent of developers consider security a priority when coding. The research also brought to light that a staggering 86 per cent of developers find it challenging to practise secure coding, with 92 per cent of developer managers also conceding that their teams needed more training in security frameworks.

Worryingly, 48 per cent of respondents admitted that they knowingly leave vulnerabilities in their code, and a further 19 per cent left the option for using insecure code open, “depending on the project”.

So why is this occurring?

First, legacy mindsets allow this to occur. Developers view secure coding as one part of the overall landscape of their job roles, and one that takes a backseat to competing priorities such as being able to push new features into production at pace.

This perception is able to persist in part because the environment that exists in many organisations does not treat developers as a focal point in the fight against common vulnerabilities. A lack of emphasis on writing secure code in their KPIs (coupled with a lacklustre security culture) reinforces this as an acceptable standard.

Second, we know that developers who feel unsupported or dissatisfied with their jobs in any way are much less likely to buy into secure coding or to put it into practice; a separate study in 2020 found that “happy tech developers (69 per cent) are more likely to perform security analysis of their code compared with grumpy developers (19 per cent).

Additionally, happy tech developers are “1.7X more likely to pay attention to security than their grumpy counterparts”, and “1.9X more likely to consider application security a top concern.”

Third, it is our experience that developers may think they’re engaging in secure coding practices, where they’re often just scratching the surface of what secure code entails. Some rely on using existing (or pre-approved) code, rather than writing new code that is free from vulnerabilities.

Others mistake a heightened awareness around their use of third-party components as a practical demonstration of having a secure coding mindset. These measures alone do not meet a functional level of secure coding ability.

Fourth, reduction of vulnerabilities requires hands-on training in good, safe, coding patterns, in the languages and frameworks that are actively in use. It appears that, generally, developers are not getting frequent, adequate training, nor are they getting enough exposure to good security practices and hygiene.

The training they receive does not build their confidence or practical skills, nor does it help them understand the impact of their decision to ship vulnerable code.

They need comprehensive training, and any responsibility for security needs to be implemented with respect to their tech stack and workflow.

Fifth, this isn’t just on developers. It will take a sizeable culture shift to uplift developer-driven security, and it starts with educational pathways that move both engineers and the security team to greater clarity. Security professionals in the business can utilise developers in an uplifted strategy; they just need to get familiar with their needs and consider them as part of their defensive play.

It’s an uphill – yet essential – battle to create an environment where the goals of the security team and their developer counterparts are aligned. We’ve got a long way to go, but the obstacles that stand in the way of the synergy needed to open the door to shared responsibility for software security are becoming abundantly clear.

Developers are not in a position to assimilate into a working security process without consideration of their needs and challenges, and without appropriate support and training to facilitate that shift.

Pieter Danhieux is the CEO and co-founder of Secure Code Warrior.