“Shift left security” refers to a software development model which fully considers security from the outset. Until quite recently, security tended to come at the very end of the process in the form of a go-live audit. This impedes visibility into your overall security posture, allowing threats to slip through unnoticed.
The concept of shifting left is a vital part of DevSecOps, the DevOps expansion that views security as a first-class component. It attempts to address the disconnect between developers, operations teams, and security experts, encouraging all stakeholders to think daily about the bigger security picture.
Designing for Security
Considering security at the start makes it more likely you’ll end up with a watertight system. Leaving it to a dedicated team at the end increases the probability you’ll overlook issues buried deep within the code paths.
Shifting security left properly recognizes its importance and makes more individuals responsible for its implementation. Developers should be aware of the overarching security implications of their code, without relying on a dedicated team’s audits. That’s not to say a separate team is completely redundant: a pre-launch review is still a good idea but it should be less time-consuming if security’s already baked in from the beginning.
The altered approach helps to foster a productive DevOps culture. Collaboration between teams is enhanced by discussing development and security in parallel, instead of moving through a rigid linear flow.
Developers need to have awareness of the app and organization-level security context which their code will operate within. Some security measures, such as robust password encryption and key verification, are already de facto defaults; others like active vulnerability scanning and pervasive event auditing vary significantly between organizations. They could be omitted by newer developers unfamiliar with the project’s security standards.
Security workers need to understand the development team’s perspective too. Implementing the most stringent security measures can add code complexity, increasing the project timeline. This touches on project management teams and business stakeholders, both of which also benefit from better visibility into the app’s security posture.
Beyond your software components, you must also look at your networking stack and any physical devices in your infrastructure. IoT products in particular can present unique weaknesses that give attackers a foothold in your system. People who oversee these systems need to be informed of your security baselines too.
How to Shift Left?
Shifting left isn’t something that happens overnight. An effective shift is dependent on a mindset change across the organization. You could spend an afternoon discussing security in an all-hands stand-up but unless changes are enacted, tested, and iterated upon, you’re no better off than you were in the morning.
First of all, it’s important to define the fundamental security requirements for your system. A clearly documented set of technical foundations, procedural routines, and compliance baselines gets everyone onto the same page, whether they’re coming from “dev,” “sec,” or “ops.” You can use popular community standards such as the OWASP guidelines as a starting point.
Next, look at your existing process. Where does security fit in? If it’s your first attempt at shifting security left, you might find security sits a long way to the right. Analyze your process to identify where security could slot in. Which discussions should security appear in?
You want this to be as early on as possible but the exact position will vary by organization. In an ideal world, security will be considered once the project’s functionality has been fully scoped but before a firm technical architecture has been selected. This gives you the flexibility to make security-conscious choices without worrying you’ll need to start again when the spec’s decided.
Before development starts, provide everyone with an overview of the system’s security model. Make it development’s responsibility to see technical standards are implemented while operation teams ensure production environments adhere to your agreed baselines.
During and after development, code should be audited, questioned, and scanned to ensure it’s actually performing as intended. You need a way of verifying code and infrastructure components possess the qualities you’ve specified.
Fortunately, security tooling has been moving at the same pace as the methodologies it helps facilitate. Automated vulnerability scanning lets developers verify code is safe without increasing the time they spend writing it. Similarly, scanning third-party dependencies used in projects helps defend against the rising tide of supply chain attacks.
You can use the new breed of API fuzz testing tools to conduct security scans of your live endpoints. These can help uncover issues that only show in specific scenarios, improving your security testing coverage.
Another aspect of tooling concerns the day-to-day developer experience. Using in-editor linters and plugins provides immediate line-by-line feedback, flagging issues the moment they enter the code. An effective review and merge strategy guarantees there are multiple eyes on each change.
Automate as many of your controls as possible. This mitigates time losses and will help to keep team members onboard. Adding complexity to the process could lead to frustration, eventually prompting developers to look for ways to sidestep the security checks.
The Benefits of Shifting Left
Organizations that successfully shift left benefit from an improved security posture that’s more maintainable over time. It results in a security-conscious culture where everyone understands the system’s controls and why they’re present.
Shifting security left can also improve code quality and lead to more advanced architectural designs. Baking security in from the start can uncover alternative strategies that solve broader problems than security alone. It also promotes modern development practices by encouraging the use of automated tooling.
The model can alleviate release day pressures too. There’s no mad scramble to audit solutions before they go live, as they’ll have been continually assessed throughout the development process. Finding problems earlier tends to make them easier and less costly to fix. If a security issue is found in development, it can be resolved safely without any impact on customer data.
Summary
“Shifting left” refers to elevating security’s position in the software development lifecycle to one of priority and continual reference. It challenges the perception that security’s often an afterthought, assessed hastily right before a new system launches.
Tackling security on day one gives you greater peace of mind, more collaboration between team members, and earlier discovery of issues. You won’t be chasing security problems late in the day, as they’ll show up during planning, development, or code review. This helps releases flow smoothly and safely.
Moving security left meshes well with other modern concepts such as cloud-native methodologies and DevOps procedures. They all help you create more resilient software in a shorter timeframe without compromising on the developer experience. With cyberattacks on the rise, taking the time to better integrate security into your development process will help you defend your data and your customers against emerging threats.
