Secure code can be both beautiful and high-quality

Friday, 22 April 2022 10:54

Secure code can be both beautiful and high-quality

By Matias Madou, co-founder and chief technology officer, Secure Code Warrior

GUEST OPINION: To really make security part of the developer mindset, it needs to be incorporated into their broader aspirations and backed up with holistic, relevant and continuous training.

All developers want to create software that works, but many also aspire to broader ideals of creating code that is beautiful, memorable, and of high quality, in addition to being purely functional.

A codebase’s beauty is usually defined by its aesthetics and simplicity, though these judgments are often subjective and ‘in the eye of the beholder’. The question of ‘What makes beautiful code?’ has been asked in virtually every software development forum, and we’re no closer to a definitive or comprehensive answer.

Quality is similarly subjective. The production of high-quality code should be the baseline for all software development, but the definition of ‘quality’ still appears to be up for debate. Some, for example, consider quality to be a measure of whether the code works well and stands the test of time. An active question is the extent to which secure code is considered an essential indicator of quality.

As it stands, overall security is rarely a major feature of the discussion, nor are developers assessed on their ability to write secure code in most KPI scenarios. There’s little correlation between code security and quality; both secure and insecure code can fail the quality test, depending on how it was created and how well it compiles and runs.

And that’s where a change is needed.

Functional and beautiful code shouldn’t be considered ‘high quality’ if it’s demonstrably insecure. The complicating factor is that secure code isn’t inherently high quality (or beautiful) either; after all, code that fixes one security problem may introduce another, or potentially break the software entirely.

There needs to be stronger alignment between the security of code and aspirational concepts in code development like ‘attractive’ and ‘high quality’.

By tying security more closely to the aspirations of developers, it stands a higher chance of becoming embedded into coding practices and a core part of the developer skillset.

Patchy understanding
Security may not be part of what developers aspire to, in part because for a long time, it hasn’t been their problem. Only in recent times with the rise of ‘shift-left’ methodologies like DevSecOps has security become something with which developers have to concern themselves.

DevSecOps was a great leap forward, in no small part because of the emphasis on shared responsibility for security, and the power of a security-aware developer to thwart common vulnerabilities as they write code.

A lot of effort is now put into skilling up developers to play a role in security, with mixed results.

How well developers understand security and can apply it to review of a codebase - either their own or someone else’s - varies.

In a 2013 university study, 30 developers were asked to review the code of a ‘small web application’ for vulnerabilities. The findings were stark: “None of the developers found more than five of the seven vulnerabilities and about 20% did not find any vulnerabilities.”

A study last year found “significant differences between the categories of security defects that are identified and that are missed during code reviews”.

In other words, developers are unlikely to find all common vulnerabilities that exist in a codebase, and tend to be better at detecting some vulnerability types over others.

Part of the reason for patchy security knowledge among developers is that not all secure code training is created equal.

There’s a real need for organisations to review secure code training for development teams to ensure they emerge with a well-rounded understanding of vulnerability types, how to detect their presence, and ultimately, write good coding patterns that don’t introduce common security bugs in the first place.

Getting developers onside
Developers need to be enabled to care more about creating secure software.

The modern developer has to keep a lot of plates spinning, and it’s no surprise they find security training a bore, especially when it’s not implemented with their workday in mind and takes them away from their deadlines and priorities with little benefit.

It’s also completely unfair to change their KPIs to include an emphasis on secure coding, when they don’t have the skills built up from regular, right-fit learning opportunities and supplementary tooling.

However, the importance of secure software development cannot be overstated, and getting developers on-side with it is crucial.

Developers won’t have a positive impact on vulnerability reduction without a foundational understanding of how the vulnerabilities work, why they are dangerous, what patterns cause them, and what design or coding patterns fix them in a context that makes sense in their world.

A dynamic, holistic approach allows layers of knowledge to give a full picture of what it means to code securely, defend a codebase, and stand up as a security-aware developer. Part of that layered learning should be dedicated to offense and understanding the mindset of an attacker; this is critical to hone lateral thinking skills, which are invaluable in threat modelling and defensive strategy.

Incentivising developers to engage with continuous security skill-building is also a no-brainer; they should be rewarded for recognising the importance of code-level security. Security champion programs, bug bounties and hackathons can be great opportunities to build a positive security culture, retain valuable developer talent, and ensure ongoing innovation in your quest for a higher standard of code quality and security.

Read 630 times

SONICWALL 2022 CYBER THREAT REPORT

GET REPORT!

PROMOTE YOUR WEBINAR ON ITWIRE

MORE INFO HERE!