video

Security by Design Building Secure Software

Published on 26 November 2024

Written by Martin Hinshelwood

5 minute read

Link copied to clipboard!

Shift Left: Building Quality and Security From the Start

Hi, I’m Martin Hinshelwood, and today I want to explore the concept of “shifting left” in modern software engineering—a principle that’s all about building quality, security, and reliability into your software from the very start. It’s a transformative approach that not only enhances your product but also revolutionizes how your team works. Let me share some insights, personal experiences, and practical advice to help you embrace this mindset.

What Does “Shift Left” Mean?

At its core, shifting left means moving quality assurance (QA) earlier in the development cycle. Instead of testing quality or fixing security issues after the code is written—or worse, after it’s in production—you build it into your processes right from the beginning.

Why Shift Left?

Prevent, don’t patch: Catching issues early is exponentially cheaper than fixing them later.
Empower teams: The same people who write the code should test, validate, and even support it in production.
Avoid brand damage: By building robust systems, you reduce the likelihood of catastrophic failures that harm your reputation.

How Far Left Should You Go?

This is a common question—and a point of debate. For me, it’s simple: shift all the way to the left. Here’s what that looks like in practice:

1. Developers Own the Process

Write and run tests: The people writing the code should also write and run the tests, taking full accountability.
Support in production: Teams that build features should also be responsible for maintaining and supporting them in production.

2. Integrated Expertise

Modern teams need more than just coders:

Security specialists: To identify and mitigate risks early.
Testing and validation experts: To ensure the software does what it’s supposed to.
UX professionals: To design intuitive, user-friendly experiences.

The Tools and Techniques That Enable Shifting Left

Adopting a shift-left mindset requires leveraging modern engineering practices. Here are a few tools and techniques I’ve seen deliver incredible results:

1. Test-Driven Development (TDD)

TDD isn’t just about writing better code—it’s about creating better architectures. By writing tests first:

You focus only on the features you need.
Future enhancements become easier to add.

2. Pair Programming

While it may seem less productive at first (two developers working on the same code), it:

Reduces errors early on.
Saves countless hours of debugging later.

3. Continuous Feedback Loops

Short feedback loops help teams:

Identify and fix issues faster.
Reduce the chances of problems reaching production.

Overcoming the Initial Pain

I won’t sugarcoat it—shifting left takes effort. The first time you implement these practices, things will seem slower. You might feel like you’re delivering less. But here’s the reality:

Long-term efficiency: Each task done “right” the first time means fewer bugs, fewer reworks, and less wasted effort down the line.
Reduced exponential costs: Poor engineering practices don’t just create linear problems—they create exponential ones. Imagine building a skyscraper on shaky foundations. With software, at least, we can go back and strengthen those foundations. But wouldn’t it be better to build it right the first time?

A Real-World Example: Azure DevOps’ Transformation

The Azure DevOps team is a perfect case study in the power of shifting left. Here’s their story:

The challenge: Moving from a waterfall model to continuous delivery meant dealing with years of accumulated technical debt.
The investment: It took four years to pay back that debt. But the results? Stunning.
The results:
- They went from delivering 25 features per year to nearly 150 features—with the same team size.
- Faster delivery cycles enabled more experiments, better customer feedback, and ultimately, a better product.

The lesson? The initial cost of shifting left is irrelevant compared to the long-term value it delivers.

The Building Analogy: Why Quality Matters

Let me share a simple analogy: Imagine constructing a building. If the first floor is made of substandard materials, every subsequent floor is at risk. In software, poor-quality foundations might not cause an immediate collapse, but they create an unstable system that limits your ability to innovate.

Unlike physical buildings, though, software gives us the unique opportunity to refactor and strengthen foundations as we go. By using techniques like TDD and continuous delivery, you can ensure that every new “floor” of your product is stable and ready for future growth.

Shifting Left Enables Engineering Excellence

When you embrace shift-left practices, you’re not just improving your product—you’re transforming your organization. Here’s how:

Better products: Quality and security are baked in from the start, reducing the chances of costly errors.
Happier customers: Faster feedback loops and iterative improvements lead to better experiences.
Stronger teams: Empowered teams with diverse expertise are more engaged and productive.

How Naked Agility Can Help

Implementing these practices can be daunting, especially if your organization has years of technical debt to tackle. That’s where Naked Agility comes in. We help teams and organizations choose the practices that work best for their context, enabling them to:

Build quality in from the start.
Experiment and innovate more effectively.
Deliver better products, faster.

SEO Keywords

Shift left software development
Modern software engineering practices
Building quality into software
Test-driven development (TDD)
Pair programming benefits
Continuous delivery practices
Agile engineering techniques

Shifting left is about more than just fixing bugs early—it’s about creating a culture of excellence that empowers your team and delights your customers. Start your journey today and unlock your team’s full potential.

Watch on Youtube

Many companies make the mistake of treating security as an afterthought, doing security validation and security checks at the end of the process. This is not a small company problem; it’s not a big company problem; it’s an all-company problem. Some of the largest tech companies have resolved this with something you’ll probably hear about in the Dora report, which is shift left. Shifting left means shifting everything as left as you can, as close to the developers and engineers as possible, to resolve these issues.

What has been happening is that we will do many years of work on a product—could be months, could be years, could be weeks. We do a whole bunch of work on a product and then we ship it to pen testing or someone who’s going to do some security validation for your product, even if it’s yourselves doing it. But you just do it at the end, and you find a whole bunch of problems. Some of those problems are going to be systemic to how you’ve built your product in the first place. In order to fix that, we’re going to have to rearchitect.

If we’re late in the game, we’re ready to ship, and everybody’s asking us when it’s going live, we need to get out. We need to blue Peter the heck out of that, and we get out our super glue, our sticky tape, and we go figure out how to paper over the cracks in our product to prevent the hackers from getting in. The problem is that hackers are super good at peeling away the edges of those things to get underneath and gain access to your system and take it over.

I’ve been involved with some exercises that the Azure DevOps team did, where they hired a team of professional hackers. This is a red-blue exercise: hire a team of professional hackers, bring them in, and their job—the red team’s job—is to hack the system. The blue team’s job is to detect them and do something about them, either prevent them from getting in or push them out, or all of those things. The red team always wins. That’s the thing you have to realise: eventually, the red team is always going to win. They’re going to find a flaw; they’re going to find ways to peel up that tape. The only way for you to prevent those things is to not have vulnerable code in the first place, not have vulnerable architectures in the first place.

The only way to do that is to refactor the heck out of your system to make those things go away and then stop those things from happening in the first place. For example, the Azure DevOps team does these red-blue exercises, and the red team’s job is to go around all of the teams in the organisation and show them how the red team was able to use their code to get access to the system and how they could have coded it differently or architected it differently or changed the way they do something in order to prevent hackers from getting in. That’s security by design; that’s security from the start; that’s security baked into the problem.

This is true for a lot of different facets of software engineering: it’s every team member’s problem. What the business wants is every team member’s problem. How much it’s going to cost is every team member’s problem. The customer’s worries are every team member’s problem, and security is every team member’s problem. So building security in rather than testing it in, building quality in rather than testing it in, is about shifting left, getting as many of those skills that you need for your context into the hands of the developers that are doing the work.

There are a bunch of tools out there that can help with that. There’s SonarQube and SonarCloud, which enable your developers to analyse their code and find and hopefully deal with vulnerabilities. There are known vulnerabilities that happen in the code. You can also use GitHub, which has an advanced security protection system that you can use in GitHub or as part of Azure DevOps to again analyse the code, find problems, and poke at it.

It’s why, if you’re a developer and you try to upload some code that has a PAT token or something that looks like a security token or a password into the system, you will be prevented from checking in that code, from committing that code, from the repo, from doing a push to production by GitHub and Azure DevOps, because the advanced threat protection is detecting that and preventing it from getting into the system in the first place. Shifting as far left as we possibly can to validate that those things are not going to cause vulnerabilities.

A really common vulnerability is developers on dev machines putting passwords in text files. On dev machines, there are all sorts of vectors that hackers can use. My advice is to help you within the context of shifting left and enabling your teams to have the knowledge and skills they need to be able to prevent and remove as many of these issues as possible before they become a problem.

video Software engineering Software development Agile Product development Agile product development Project management Agile project management project manager product owner scrum master product manager

Link copied to clipboard!

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.

CR2

NIT A/S