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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/27/2020
Chinese Attackers' Favorite Flaws Prove Global Threats, Research Shows
Kelly Sheridan, Staff Editor, Dark Reading,  10/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11484
PUBLISHED: 2020-10-29
NVIDIA DGX servers, all DGX-1 with BMC firmware versions prior to 3.38.30, contains a vulnerability in the AMI BMC firmware in which an attacker with administrative privileges can obtain the hash of the BMC/IPMI user password, which may lead to information disclosure.
CVE-2020-11485
PUBLISHED: 2020-10-29
NVIDIA DGX servers, all DGX-1 with BMC firmware versions prior to 3.38.30, contains a Cross-Site Request Forgery (CSRF) vulnerability in the AMI BMC firmware in which the web application does not sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the u...
CVE-2020-11486
PUBLISHED: 2020-10-29
NVIDIA DGX servers, all DGX-1 with BMC firmware versions prior to 3.38.30, contain a vulnerability in the AMI BMC firmware in which software allows an attacker to upload or transfer files that can be automatically processed within the product's environment, which may lead to remote code execution.
CVE-2020-11487
PUBLISHED: 2020-10-29
NVIDIA DGX servers, DGX-1 with BMC firmware versions prior to 3.38.30. DGX-2 with BMC firmware versions prior to 1.06.06 and all DGX A100 Servers with all BMC firmware versions, contains a vulnerability in the AMI BMC firmware in which the use of a hard-coded RSA 1024 key with weak ciphers may lead ...
CVE-2020-11488
PUBLISHED: 2020-10-29
NVIDIA DGX servers, all DGX-1 with BMC firmware versions prior to 3.38.30 and all DGX-2 with BMC firmware versions prior to 1.06.06, contains a vulnerability in the AMI BMC firmware in which software does not validate the RSA 1024 public key used to verify the firmware signature, which may lead to i...