The Importance of Defining Secure Code

The developers who create the software, applications, and programs that drive digital business have become the lifeblood of many organizations. 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 attacks remain prevalent, even though spending on cybersecurity in most organizations is way up, and even though movements like DevSecOps are shifting security towards those developers who are the lifeblood of business today. 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 of 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 questioned further, a lack of time and a lack of a cohesive approach from management were stated as the top barriers to creating secure code.

Reliance on existing code is one of the factors that increase the risk of the software being shipped with exploitable vulnerabilities. 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 overriding messages from the survey was that the developer community as a whole is filled with professional people who care about 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.

In fact, most developers stated that their organizations did not even have a clear definition of what constitutes 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:

Read more: https://bit.ly/3sgxNJh

You can also read this: How Risk and Compliance Technology Makes FIs More Secure

Leave a Reply

Your email address will not be published. Required fields are marked *