Starting "left of left": Is secure code always quality code?

A version of this article appeared in Dark Reading. It has been updated and syndicated here.

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.

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 get 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 everything else. However, those on the tools will waste precious time redoing sloppy code to add on 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.

Starting “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 kind of 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.

Ready to ignite the secure coding fire in yourself? Rise to the challenge.

‍