Sponsored: Developers have defined “secure coding” and their answers point to a critical issue

Image: Michael Traitov/Adobe Stock

We have a long way to go, but the obstacles that impede the synergy needed to open the door to shared responsibility for software security are becoming very clear. Smart companies want to evolve their strategy to avoid these pitfalls, find a productive path, and use DevSecOps to its full potential.

What I didn’t anticipate is that the perception of what constitutes the act of secure encryption is up for debate. According to brand new research in collaboration with Evans Data, this feeling has been revealed in black and white. the 2022 Developer-Driven State of Security Survey dives into the key ideas and experiences of 1,200 active developers, illuminating their attitudes and challenges in the field of security.

A key finding was that only 14% of developers consider security a priority when coding. While this shows there is huge room for improvement, it confirms what we already knew: feature creation is king in the world of developers, and they remain ill-equipped to make security part of their DNA. However, when paired with data about developers’ definitions of what secure coding means to them, it is concerning.

These perceptions are driven by the experience of developers in their workday, and this reflects the environment of many organizations where developers are simply not a focal point in addressing common vulnerabilities. Enabling them is essential, but in the meantime, we need to 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 world.

Cybersecurity is a multifaceted and unwieldy beast at the best of times, and while secure coding is only part of the overall landscape, it is a complex cog in the system that requires specialized 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 fundamentals and beyond. The developers have indicated that they rely on using existing (or pre-approved) code, rather than the practice of writing new code free of vulnerabilities. While the security awareness regarding third-party components (specifically patches and the Log4Shell debacle is a great example of this: 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 capability.

Code-level vulnerabilities are introduced by developers who have learned bad coding patterns, and the 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 where knowledge gaps are most pressing, by first ensuring that the development cohort has a complete picture of what the secure coding involves. Testing and analyzing pre-approved code is one function, but mitigating vulnerabilities requires hands-on training in good, secure coding patterns, in the languages ​​and frameworks that are actively used.

Context is critical in improving developer skills, and they should be built into the journey when it comes to enterprise security goals.

Many organizations need to upgrade their security programs.

As the explosion of software technologies has given way to the rapid growth of cybersecurity incidents over the past decade, we all strive to keep up with threat actors who are working around the clock to uncover exploits in systems. precious.

The DevSecOps methodology is based on the idea that everyone shares the responsibility for security – including developers – and this has been a major consideration since the very beginning of the SDLC. The problem is that, especially in large enterprises, they can be a long way from implementing DevSecOps as a standard. In 2017, a study by the Project Management Institute showed that 51% of organizations still use Waterfall for their software development. This study is now five years old, but knowing how incremental changes can be in large organizations, it is unlikely that there has been a sudden transition to the latest security-focused methodologies. These legacy processes can create an uphill battle for security professionals trying to cover all bases with a comprehensive cyber threat protection strategy, and upgrading developers and their needs in this landscape is a challenge.

However, we cannot use this as an excuse. Enterprise security professionals can use developers as part of an enhanced strategy; they just need to familiarize themselves with their needs and consider them part of their defensive game. They need comprehensive training and all security responsibilities must be implemented in regards to their technology stack and workflow.

Secure coding = shopping cart “too hard”?

Evans Data’s study shed light on the fact that 86% of developers struggle to practice secure coding, with 92% of development managers also admitting that their teams need more training on security frameworks. Worryingly, 48% of respondents admitted to knowingly leaving vulnerabilities in their code.

This paints a very worrying picture. It seems that, in general, developers do not receive frequent and adequate training, and that they are not sufficiently exposed to good security and hygiene practices. Reading between the lines, this reinforces the nub of the problem: it’s just not a priority for developers to consider security in their work. This, 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 of the past year, sparking fears that half of the gas supply on the US East Coast not be interrupted for an indefinite period. Fortunately, they were back up and running quickly, but not without significant apprehension in the community. It was one of those pivotal times when the general public was faced with the prospect of a cyber incident severely affecting an element of the physical world that is not necessarily considered software-driven, or a risk of a cyber attack. And all this chaos was made possible by two old, unpatched vulnerabilities, one of which was the insidious, but widely known, SQL injection. If developers knew what was really at stake when they chose to ship vulnerable code, they would quickly see that there is no scenario where this is an acceptable business risk.

The functional “PPT” does not depend on the developer.

The famous “golden triangle” of people, processes, and tools is not achievable without a carefully thought-out strategy, and developers are unable to assimilate into a functional security process without considering their needs and their challenges.

It will take a significant culture shift to improve developer-centric security, and it starts with educational journeys that bring both engineers and the security team to greater clarity.

This content was provided by the Secure Code Warrior team. Click here to learn more.

Comments are closed.