How do developers define "secure coding"?

A version of this article appeared in TechRepublic. It has been updated and syndicated here.

‍

It has been 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. Smart companies want to evolve their strategy to avoid those pitfalls, find a productive way forward, and use DevSecOps to its full people-powered potential.

What I wasn’t anticipating, is that the perception of what constitutes the act of secure coding is up for debate. According to brand new research in collaboration with Evans Data, this sentiment was revealed in black and white. The State of Developer-Driven Security 2022 survey delves into the key insights and experiences of 1200 active developers, illuminating their attitudes and challenges in the security realm.

One of the headline findings was that just 14% of developers consider security a priority when coding. While this shows there is enormous room for improvement, it confirms what we knew already: feature-building is king in the developer’s world, and they remain ill-equipped to make security part of their DNA. However, when coupled with data on developer definitions of what secure coding means to them, it is cause for concern.

These perceptions are driven by developer experience in their working day, and it speaks to the environment of many organizations, which is that developers are simply not a focal point in the fight against common vulnerabilities. Their enablement is critical, but in the meantime, we must quickly get on the same page with the scope of “secure coding”, and what we should expect from a security-skilled developer. 

We need to demystify security in the developer’s world.

Cybersecurity is a multi-faceted, unwieldy beast at the best of times, and while secure coding represents just one part of the overall landscape, it is a complex cog in the system that requires specialist attention.

The survey revealed that the concept of working with secure code was quite siloed for the average developer, with their scope often limited to a single category as opposed to a holistic view of the fundamentals and beyond. Developers indicated a reliance on using existing (or pre-approved) code, rather than the practice of writing new code that is free from vulnerabilities. While security awareness regarding third-party components (especially patching, and the Log4Shell debacle is a great example: 30% of instances remain unpatched since December) is very important, as is testing existing code, these alone do not meet a functional level of secure coding ability. 

Code-level vulnerabilities are introduced by developers who have learned poor coding patterns, and a lack of emphasis on writing secure code in their KPIs (coupled with a lackluster security culture) only reinforces this as an acceptable standard. 

Security leaders can go a long way in improving initial awareness and identifying areas of the most pressing knowledge gaps, by first ensuring that the development cohort is shown the complete picture of what secure coding entails. Testing and scanning pre-approved code is one function, but the reduction of vulnerabilities requires hands-on training in good, safe, coding patterns, in the languages and frameworks that are actively in use.

Context is vital in developer upskilling, and they need to be brought on the journey when it comes to the security goals of the business.

Many organizations need to upgrade their security programs.

With an explosion of software-driven tech making way for the rapid growth of cybersecurity 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. 

The DevSecOps methodology is built on the idea that everyone shares responsibility for security - developers included - and it’s a chief consideration from the very beginning of the SDLC. The problem is, especially in large companies, they may be very far away from implementing DevSecOps as a standard. In 2017, a study by the Project Management Institute showed that 51% of organizations were still using Waterfall for their software development. That study is now five years old, but knowing how gradual changes can be in large enterprises, it’s unlikely that there has been a sharp transition to the latest security-oriented methodologies. These legacy processes can create an uphill battle for security professionals trying to cover all bases with a comprehensive strategy to protect against cyber threats, and retrofitting developers and their needs into this landscape is a challenge. 

However, we can’t use this as an excuse. The security pros in the business can utilize developers in an uplifted strategy; they just need to get familiar with their needs and consider them as part of their defensive play. They need comprehensive training, and any responsibility for security needs to be implemented with respect to their tech stack and workflow. 

Secure coding = the “too hard” basket?

The Evans Data research brought to light that a staggering 86% of developers find it challenging to practice secure coding, with 92% of developer managers also conceding that their teams needed more training in security frameworks. Worryingly, 48% of respondents admitted that they knowingly leave vulnerabilities in their code. 

This paints a very concerning picture. It appears that, generally, developers are not getting frequent, adequate training, nor are they getting enough exposure to good security practices and hygiene. Reading between the lines, it reinforces the crux of the issue: it simply is not a priority for developers to consider security in their work. That, and 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. 

The Colonial Pipeline ransomware attack was one of the most disruptive supply chain security incidents in the past year, sparking fear that half of the gas supply on the United States east coast would be cut off for an indeterminate period. Thankfully, they were back up and running quickly, but not without significant apprehension in the community. It was one of those crucible moments where the general public faced the prospect of a cyber incident seriously affecting an element of the physical world that isn’t necessarily thought of as software-driven, or a risk for a cyberattack. And all of that chaos was made possible by two old, unpatched vulnerabilities, one of which was the insidious, yet widely known, SQL injection. If developers knew what was truly at stake when they chose to ship vulnerable code, they would quickly see there is no scenario where that is an acceptable business risk.

Functional “P-P-T” is not up to the developer.

The famous “golden triangle” of People, Process, and Tools is not achievable without carefully considered strategy, and developers are not in a position to assimilate into a working security process without consideration of their needs and challenges.

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.