If you work in DevOps, you’re probably familiar with the concept of “shift-left”—at least when it comes to things like software testing and deployment. But have you thought about how you can also shift security to the left? If not, it’s time to start.
This article explains why shift-left security is an important part of the next big innovation in the way you keep applications and data secure.
Before delving into the details of shift-left security, let’s explore the shift-left concept itself and understand why it is so important.
“Shift left” is a simple term for a challenging task. The idea is that you move application quality and security considerations closer to the developer (that is, to the “left” of the delivery chain) so that potential issues are avoided or resolved sooner, even before code is committed. Technology certainly makes shift-left easier, but that is only half the battle. First. your developers need to care—Only then can you build a solution to make it efficient and effective for them.
The cost of bugs and security issues as they move through the delivery chain multiplies several times over at each step, all the way to production. It eventually turns into technical debt, becoming a ticking time bomb of cascading issues.
This means shifting left has a clear ROI, simply by addressing issues at the point of origin. In contrast, in traditional development, there is a dedicated team for security and a team for quality. Their general mode of operation is to respond to issues, not necessarily prevent them, because once code moves to integration or production, it’s often too late to take precautionary measures. The other problem is that IT teams are focused on system-level security, which is different than application security, where sneaky issues can surface off the radar. This has crippled companies, especially when it comes to security, where the actual cost of the issue is unbounded, unlike a bug where there is an upper limit.
But there is a huge benefit of these dedicated teams and the segregation of duties. Their domain expertise allows developers to be ambivalent of how security is implemented, and why. That does not mean, however, that the developers do not get involved. And when they do, it becomes not only a technical problem, but a communication problem. What could have been a 15-minute consideration when the code was written turns into a problem spanning days or weeks. Time not only needs to be spent on issue resolution, but also cleaning up the damage done to company reputation and frustrated users.
In the traditional model, when a security issue arises, it is disruptive, expensive, and wears on the entire team. This is why “shift-left” security makes sense. But telling developers they suddenly have more work to do is not going to fly.
Now, let’s take a look at how to shift security to the left and why it will not only make your application more secure, but also benefit your overall software delivery process.
Getting the buy-in from developers to think about security is challenge number one. The approach of just telling them it’s now their job is not likely going to work.
Telling a developer to do anything without explaining why will be met with strong opposition, or simply neglect to comply. Developers appeal to logic. They also appeal to accountability. The reason that most security issues are found in production, and IT is forced to be responsive rather than proactive is because IT Ops teams responsible for production were historically the only ones accountable for security—which is too late. The origin of code is the first line of defense. Zero-day exploits can show up in frameworks developers use. In containerized environments, exploits can show up in containers with poor configurations, or more likely, snowflake configuration changes that the developers implemented during the development process, which somehow made it into production.
This means that when stuff broke, developers’ heads rolled.
For that reason, IT Ops should not be 100% accountable. Developers need to understand that as exploits show up, sometimes the origin points to variables in their control. So they should be held accountable also. In DevOps, the idea is not to punish mistakes, but learn from them. When a serious security issue surfaces, it’s hard not to direct blame. But when developers are involved early on, and see the potential negative impacts of their activities, the pain of revisiting their configurations is often enough to get their attention. Developers don’t want to be interrupted, and most of the time, they do not want to be the reason behind an outage. It ruins their street cred.
Not all developers will comply, but if they aspire to “full stack” and grow with modern development practices, it’s always in their best interest to do so.
Shifting Left & Right
To shift security left, it’s not enough simply to put the security playbook in developers’ hands. They have to be enabled. Developers are better at leveraging tooling than anyone, and in this case the job of the team is to not make a significant amount of additional work for them. The goal is to give them a process where issues can be identified early, along with tools that help them do it automatically. This is how:
- Vet configurations: Whether VMs or containers, all configurations should be static, scripted, and immutable. Developers should not need to make any configuration changes, and all images (including those used in dev/test) should be vetted and have parity to what is in production. If you use a trusted image from a trusted image repo, then the concerns about configuration lead security issues should be diminished, and easy to respond to by replacing poor configurations. You can also create a lifecycle of developing the images so that they also go through a delivery chain, which includes the most stringent of security scanning and testing.
- Test early and continuously: In order to know how to improve security on the left, you have to be testing continuously at every stage of deployment, including production. So the tooling in your delivery chain should be implementing real-time detection of issues at each stage—even dev. Then, the success of the process should be judged by measuring the number of issues caught before production. If an issue does happen into production, success is measured not only by its detection, but also how the information plays into prevention back in development. Issues should never show up twice.
- Give insights into production: Often, developers see application performance data only up to CI environments, and sometimes not even then. Consider building visualization tools, or dashboards tailored to security considerations for the developer. Let developers quickly see the impact of their healthy security practices. DevOps, or IT Ops that define security strategies should be able to communicate the effectiveness of efforts to developers, and steward security, not dictate it.
- Re-think automation: The point of automated security testing is to block code from production. This sounds counterintuitive to DevOps. Automation comes at the expense of machine cycles, but not necessarily time, because they can run in parallel or real time, so it is not akin to the traditional security gates of the past where a human was involved. If you think about automation as a testing gauntlet that code has to go through for you to gain confidence, then you are being proactive. Making the gates is one thing, but if there are failures in integration or even end-to-end systems testing, the developer should be able to see all failures, and quickly inspect whether they are related.
- Be proactive: You can’t predict issues. But being proactive rather than reactive is important. The only way to do this is to leverage security tools that can learn and adapt to the environment, so that the delivery chain itself learns from previous issues, and issues that percolate in production.
As you can see, shift-left security is not necessarily on the developer to implement. The burden on the developer is making it a standard consideration during development, like unit and functional testing. What they implement should be minimal. They are:
- Making sure they follow the workflow
- Making sure their dev environment does not introduce unknown variables
- Making sure they stay away from ad hoc configuration changes
- Awareness, and monitor security analytics from dev to production environments
The benefits of shift-left security are phenomenal. They’re also easy to achieve, as long as you can get buy-in from developers and implement the right tooling. Shift-left security will pay for itself by preventing security issues, or helping developers to detect them early on.
Ready to learn more about how to reconfigure your workflow to enable shift-left security, then this post is for you. Otherwise, if you want to learn more about how Twistlock helps you shift-left, subscribe to our blog or contact us for a container security evaluation.
- Re-enable Your Workflow to Allow Shift Left Security
- Intent Based Security and Rethining Application Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog