The Case for ‘Shifting Right’
“Shift left” tends to dominate the conversation when it comes to software development and application security. In fact, we’ve been doing it for decades. That term has been a part of the language since as early as 2001 when Larry Smith introduced the idea of testing early in the development process.
While we’ve benefitted from “shift left” for quite some time now, we’re now more recently seeing developer tools broaden their focus to include the right side of the deployment life cycle. The development and testing up front are still performed, but we’re also seeing IDE plugins and CI/CD pipeline tools help identify issues that won’t actually manifest until the software is deployed in staging or production.
The Importance of Shifting Left
Let’s be clear: Shifting left creates significant inroads when it comes to creating functional, reliable, clean code. Testing code earlier in the process is an invaluable practice that saves a massive amount of time and money in the long run by finding bugs that will create migraines for developers later on. As developers increasingly leverage generative AI tools, this becomes especially critical.
The benefits of shifting left are myriad: high-quality software, improved efficiency, reduced cost and reduced risks are only a few of them. It’s easy to get caught in the mindset that this is the biggest principle of development that coders and security alike should pay attention to. This practice ensures the kind of continuous clean code all developers should — and do — want. But there’s something to be said for shifting right. It’s not just about the code we write, it’s about what happens to that code next.
Testing the Code of Infrastructure
When we talk about shifting right, it’s not meant to be in place of shift left when it comes to ensuring secure software. Shifting right comes more into focus when you think about deployment. The greatest benefit of shifting right is the ability to see what software will actually look like once deployed while developers are still shaping and creating it.
Think of it this way: Giving yourself a site on which to test the things that you code only ensures that they look and function the way they’re supposed to upon execution. This is especially important as developers both recycle previous code and allow generative AI to work on new code. But all of this starts with infrastructure.
Defining the infrastructure of software as code means we have the tools to test it. This is crucial to deploy autonomously and consistently. From Kubernetes templates to Docker configuration, this mindset allows us to test, review and secure infrastructure — all under the umbrella of ensuring clean code.
There are a myriad of issues that aren’t necessarily caught in the earlier stages of development, meaning that shifting left doesn’t cover everything. CI/CD code-checking can be performed earlier, but that doesn’t always create a full fix for problems. Issues often never even manifest until the software is actually deployed. So, why wouldn’t we check for that too?
There are two places where this becomes especially important: secrets detection and platform configuration.
We know secrets are pieces of confidential data that must be kept secure — from API keys to passwords to access tokens and more. Secrets detection during the testing phase prevents sensitive information from exposure and leaks, providing security against breaches and unauthorized access to systems and data. This process also allows complicity with security best practices and regulatory requirements. Overall, it’s a great risk-reducer for developers by disallowing the kind of financial and reputational consequences that come from breaches.
Common sense tells us never to store secrets within code, even temporarily, because it can be easy to forget it’s been done and neglect to remove anything that needs protection. Still, it happens; humans aren’t perfect, and even AI can’t account for every single error or mistake.
With a shift-right mentality that puts coding infrastructure into practice, developers can negate this possibility by seeing exactly where their code will end up. Checking code can identify these situations and allow developers to see them more clearly, therefore preventing the kinds of easy missteps that jeopardize the code they’ve worked so hard to create.
Platform Configuration and Security Code Smells
Think about a house: A homeowner can install the best security systems, fortify doors and put in unbreakable glass for windows. But, without a solid foundation, the entire structure stays vulnerable to collapse — and renders those security measures totally useless.
So whether you’re deploying to Amazon Web Services(AWS), Microsoft Azure or Google platforms, the security of your platform is paramount to the security of your application. It’s easy for developers to want to simplify security to speed up the development process, but that’s a mistake; shortcuts at the beginning can mean holes are overlooked by the time it’s pushed to QA or deployment.
Once again, shifting right can have you covered. By understanding what your application will look like once it’s live and ready to roll, a developer can find any mistakes, errors or loopholes that will jeopardize their technology and, consequently, their company in the long term. Whether it’s human error, recent changes or a vulnerability that’s newly been discovered, doing this puts you in the position to protect the security of your application.
Balancing Shift Left and Shift Right
The phrase “shifting right” sounds innately counterintuitive to the shift-left mentality all software developers understand at the offset. But in reality, and in practice, putting these processes together ensures the best possible security and quality of your software. It’s critical to test early and find mistakes under real-world conditions. That way you’re ensuring the same high levels of quality and you’re protected from later issues by understanding how software looks at the end of the development cycle. Prioritizing both of these principles puts everyone in the best possible position to succeed — not just now, but for the long term.