The developers that create software and applications to drive digital businesses have been the heartbeat of many companies. Most modern businesses would not be able to (profitably) function, without competitive applications and programs, or without 24-hour access to their websites and other infrastructure.
And yet, these very same touchpoints are also often the gateway that hackers and other nefarious users employ in order to steal information, launch attacks and springboard to other criminal activities such as fraud and ransomware.
Successful hacking continues to be a problem, despite the fact that cybersecurity spending in many organizations has gone up and movements like DevSecOps shifting security away from developers who are today’s lifeblood of businesses. Developers understand the importance of security, and overwhelmingly want to deploy secure and quality code, but software vulnerabilities continue to be exploited.
Why?
For the 2nd year, Secure Code Warrior conducted The state of developer-driven security survey, 2022 in partnership with Evans Data Corp in December 2021, surveying 1,200 developers globally to understand the skills, perceptions, and behaviors when it comes to secure coding practices, and their impact and perceived relevancy in the software development lifecycle (SDLC).
The survey identified an absence of a clear definition or an understanding as to what constitutes secure code. It turns out that there is a big discrepancy between what developers think is secure code, and what secure code actually is.
It was not surprising that writing quality code was a top priority for the development community. But when asked specifically about secure code, only 29% said that active practice of writing code that was free of vulnerabilities was prioritized. Instead, developers associated less safe and far less reliable practices with the creation of secure code. For example, scrutinizing existing code (37%), and relying on externally sourced libraries for safe code (37%) were the top practices that developers associated with secure coding. Reusing code that had already been deemed to be secure (32%) was another popular choice. The active practice of writing code that is free from vulnerabilities came in 6th with 29% stating this was a top practice in the creation of secure code.
When asked further about the barriers that prevented secure code creation, they stated that a lack in time and lack of coordination from management are their top two obstacles.
Relying on code from the past is one factor that can increase the likelihood of exploitable vulnerabilities being discovered in software. Addressing this disconnect of what constitutes secure code is necessary for developers to create quality code that is also secure.
What Can Organizations Do To Fix The Situation?
One of the most important messages that emerged from the survey is the fact that developers as a community are filled with professionals who take pride in what they do. Writing top quality code was overwhelmingly important to them as a group. The problem is that in many cases, the organizations they work for have not identified what best practices are required to produce secure code, and have not put enough resources into training or enabled their developers to meet those goals.
Most developers said that they didn’t have any clear guidelines for what makes secure code. One of the most worrying examples of this was that 28% of the survey respondents said that their organization considered code to be secure if no breach was reported once an application or program was deployed into a production environment or made available to the public.
It probably goes without saying, but in today’s complex threat landscape, simply hoping for good results without actually working toward them will likely produce predictable results: even more security breaches.
It’s easy to get started on fixing the problem and to then work toward secure code. Organizations must first define secure code. This is the most crucial step. And everything that is outside of that definition needs to be deemed as not secure.
Secure coding should be defined as the practice of skilled developers writing code that is free from vulnerabilities, from the start of the SDLC. Only once this practice is defined can the developer community work towards that goal.
Making the goal of secure code a reality
Once the definition of secure code is established, organizations need to be ready to support those efforts and their developers who will be carrying out the goal of implementing total secure code practices. That support is critical. It is essential that your company has secure code. Without this support, it will not be able to define the codes. Management must approve secure coding practices and give them the appropriate authority, budget and consideration in order for them to be successful.
This may require new benchmarking goals for developers, who have traditionally been measured on the speed of their coding. In fact, 37% of developers in the survey reported leaving known vulnerabilities within their code because tight deadlines would not allow for the time needed to fix them, or to code properly from the start.
At first, this may mean increasing deadlines to give developers more time to properly code, although that expenditure in time at the beginning of the coding process will likely be made up later because of less of a need for program revisions, patches and post-deployment work. And eliminating the possibility of a breach one deployed can end up saving hundreds of hours and possibly millions in lost revenue, fines and cleanup costs.
Developers will need to receive relevant training. This is especially important in relation to the vulnerabilities they might encounter and how to fix them. This is especially true in light of 36% of survey respondents who said they wanted to remove vulnerabilities from their code, but didn’t have the skills or the knowledge to do so.
Want to read more insights gained from Secure Code Warriors’ survey of 1200 developers around the globe? You can access them here: State of Developer Driven Security 2022
