Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

9/29/2020
02:00 PM
Matias Madou
Matias Madou
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Shifting Left of Left: Why Secure Code Isn't Always Quality Code

Enabling engineers to share responsibility for security and empowering them to erase common vulnerabilities are good starting points.

When talking to developers about security, one of my mantras is that the only quality code is secure code. This remains true; we might have escaped disaster when vulnerable software was out in the wild in the '90s, but it's not worth the risk today. Many have worked hard to instill a security-aware mindset in developers over the years, and in doing so, have hopefully made security synonymous with quality when it comes to a self-assessment of their code.

Upon reflection (and some debate among my peers), however, it's perhaps oversimplifying the concept. It is entirely possible to create code that is indeed secure, yet shows signs of novice development technique, or other problem areas that render it less than ideal.

Related Content:

Open Source Security's Top Threat and What To Do About It

The Threat from the Internet—and What Your Organization Can Do About It

New on The Edge: A Hacker's Playlist

Our industry talks at length about the notion of shifting left. In my mind, it's all about starting left by enabling engineering cohorts to share the responsibility for security (being an aspect of quality), and giving them the power to erase common vulnerabilities at their (literal) fingertips. In light of this current conundrum, though, it seems the envelope must be pushed a little further. 

Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting left of left the formula to ensure pure secure coding standards?

What Does 'Poor Quality' Secure Code Look Like?
Let's run the magnifying glass over this code snippet:

If we analyze this code from a security perspective, this snippet is indeed secure, and not an entry point for an attacker to exploit a SQL Injection vulnerability.  

Is it an example of high-quality code? Not really, unfortunately. A simple change to the argument from an int(eger) to a string value allows free-form user input to manipulate the query, in contrast to a number which cannot. That change — or a haphazard copy and paste of the string sql from somewhere else — immediately creates an environment where SQL injection vulnerabilities are possible, and all the risks associated with them. 

The security measures had a very limited scope here, whereas a more thorough or experienced developer may have taken a different approach and considered implications of inefficient argument structure. Shipping code like this is not only poor practice, it sets a bad example for others in the development cohort.

The Software Triple Threat: Form, Function, Fortress-Like?
A triple threat in the entertainment industry is an individual who can act, dance, and sing with an equally high level of skill. They are the people feared and envied at every audition, and are the unicorns of an already competitive space. Every industry has its own version of a top-tier, exceptional example of its products and services, with software being no exception.

If we think of three key elements in applications that are difficult to balance with equal (high) quality, they might be functionality/elegance, plus iron-clad security, plus cost-effectiveness when considering the required speed of delivery. Now, that last attribute is undoubtedly a defining factor in how well the other two options are applied, and it can be a catalyst for overall quality slipping over time. 

However, does all software need to perform like Hugh Jackman, or can we get away with Nicolas Cage? Put it this way: if you can get Wolverine on your team, then you give it your best shot.

Martin Fowler asked the question, Is High Quality Worth The Cost? in software development, concluding that not only was it worth it, but it was actually cheaper over time. Most users aren't going to be looking under the hood to assess whether the code is a mess, nor whether security was made just as important as everything else. However, any engineers on the tools will waste precious time redoing sloppy code to add newer features, or trawling through major parts of the project to understand what's going on, or, the worst-case scenario, fixing a vulnerability that has bounced back from the AppSec team and delayed production. Spending time now to make code both secure and good quality saves a lot of future heartaches, not to mention the cost of unraveling poorly executed work.

Skilled, security aware developers write code that retains their creative, problem-solving vision in feature delivery, with consideration given to erasing the common security pitfalls that engineers can control in their stage of the process. Secure code isn't terribly effective in isolation, and that is why the notion of starting left of left will help support a culture of security as second nature for developers, built into their capacity to deliver amazing features with reduced risk.

Left of Left Is Critical for Secure User Experience
Security has been a consideration in the software user experience for a long time, yet clearly resulted in mixed success. Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, with amateur-hour errors like storing passwords in plaintext resulting in some serious losses in productivity, revenue, and customer trust for affected companies. 

That, and users themselves can be their own worst enemy when it comes to protecting their own data. Far too many people are still using "password" as their password, or using the same combination across multiple sensitive accounts. 

I don't know any developers who fist-pump the air when they're told they have to work on a login screen, and it's no wonder: it's a delicate balance to design a security flow that is robust, functional, and that users will be able to navigate in a way that makes sense to them, with the least disruption. 

Put in too many complex steps and restrictions, and users may switch off never to return (a disaster for a new app), make it too confusing, and you might end up giving the support team a collective migraine as they field queries from users trying to access their accounts. Make it too easy, and you're failing at the security part. 

A successful secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn't detract from everything else that is compelling about the software. You can certainly meet the objective of coding a secure login function, putting in all manner of complex password requirements, CAPTCHA, mini-bosses, and four waves of zombies, but if it's a total mess that is repellant to users, it's missing the mark. 

Lay the Foundation for Software Excellence
As a developer myself, I know that the vast majority of us take pride in our work, and want to do the right thing. Pesky curveballs like time constraints, sudden changes in the current objective, or urgent hotfixes can disrupt the flow and lead to mistakes but the harsh truth is that many software engineers are not set up for success. 

Starting left of left is a developer-first concept, and requires organizations to get serious about uplifting their engineering cohort. Security-aware developers are worth their weight in gold, and support in the form of training, provision of the right tools, and the opportunity to be mentored by more experienced developers will foster an environment where code is crafted with a security-first mindset, with the precision and attention to detail required to take software to the next level.

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. When he is away from his desk, he serves as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-25316
PUBLISHED: 2021-04-14
A Insecure Temporary File vulnerability in s390-tools of SUSE Linux Enterprise Server 12-SP5, SUSE Linux Enterprise Server 15-SP2 allows local attackers to prevent VM live migrations This issue affects: SUSE Linux Enterprise Server 12-SP5 s390-tools versions prior to 2.1.0-18.29.1. SUSE Linux Enterp...
CVE-2021-28797
PUBLISHED: 2021-04-14
A stack-based buffer overflow vulnerability has been reported to affect QNAP NAS devices running Surveillance Station. If exploited, this vulnerability allows attackers to execute arbitrary code. QNAP have already fixed this vulnerability in the following versions: Surveillance Station 5.1.5.4.3 (an...
CVE-2020-36323
PUBLISHED: 2021-04-14
In the standard library in Rust before 1.50.3, there is an optimization for joining strings that can cause uninitialized bytes to be exposed (or the program to crash) if the borrowed string changes after its length is checked.
CVE-2021-31162
PUBLISHED: 2021-04-14
In the standard library in Rust before 1.53.0, a double free can occur in the Vec::from_iter function if freeing the element panics.
CVE-2017-20004
PUBLISHED: 2021-04-14
In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions.