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.


02:00 PM
Matias Madou
Matias Madou
Connect Directly
E-Mail vvv

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
Newest First  |  Oldest First  |  Threaded View
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
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
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.