As cloud applications are built, tested and updated, they wind their way through an ever-complex series of different tools and teams. Across hundreds or even thousands of technologies that make up the patchwork quilt of development and cloud environments, security processes are all too often applied in only the final phases of software development.
Placing security at the very end of the production pipeline puts both devs and security on the back foot. Developers want to build and ship secure apps; security teams want to support this process by strengthening application security. However, today's security processes are legacy approaches that once worked brilliantly for the tight constraints of on-prem production, but struggle in ever-shifting cloud environments. As a result, security is an afterthought, and any attempt to squeeze siloed security into agile SDLC can swell the cost of patching by 600%. A new cloud security operating model is long overdue.
Shift-left is an approach to software development that integrates security early in the software development lifecycle. It aims to reconnect developers with security, create a culture of shared responsibility, and transform security into a value add. But for many organizations, shift-left security remains elusive and teams aren't sure how to get started.
Today's Shifting Puzzle
In the past, the role of security was isolated to a specific team in the final stage of development. When development cycles lasted for months at a time, this close-ended format worked well enough; however, in the last decade, teams that span the width of the SDLC have already begun re-evaluating how they can better communicate. Suddenly, the development cycle has transformed into a series of hyper-agile sprints that last weeks or days at a time. Security remains lagging behind - the final piece of the DevOps puzzle.
Many organizations are struggling to fit this last piece into place. One reason for this is the fact that both teams have vastly different goals and skill sets. On the surface, developers strive to create code to meet ever-changing end-user demands. Security, on the other hand, primarily focuses on guaranteeing the code's safety, in order to prevent exploitation later down the line.
Another difficulty facing DevSecOps is the way in which many DevOps programs have built cross-departmental transparency. Stripping back to a system of low context may have drastically sped up the CI/CD pipeline, but this low-context approach is disappointing for any attempt to shift security to the left. After all, a lack of contextual security is a direct contributor to overworked analysts and bloated patch lists. In security, context matters.
Instead of isolating security as an individual process, shift-left security builds a culture of collective responsibility - without blocking up the development process. The answer to this puzzle is cultures and toolkits that provide the right context, at the right time, to the right person. The need for a singular platform and shared language has never been greater - consider, for example, that it only takes 7 hours for an attacker to discover an open S3 bucket referenced in a Github repo. For legacy security, time is running out.
The Best Practices of Shift-Left
To build a cloud security program that can actually shift left, the bulk of this organizational culture change must come from a top-down, strategy-first approach that takes people, processes and technology into account.
But before beginning any transformation, the four components of total shift-left need a reliable and solid foundation.
Trust between Security and Development Teams: This model works when developers trust that security isn't going to slow them down. In fact, shift-left helps prove to developers that security can not only help their work - but elevate it to greater degrees of safety than ever before. A suitable analogy are high-speed race cars: developers racing through production need to trust the guardrails that line the track.
Security-Minded Dev Teams: No one is building applications in order to give cyberattackers a foothold in their environment. Shift-left works best when security is already in the back of your security team's mind. When dev teams are open to the idea of implementing security, shift left occurs with far more fluency and ease.
Full Environmental Visibility: With shared goals defined, it's possible to begin digging a little deeper into the details of your environment. Wielding full visibility into your environment allows development and security teams to understand not just what is deployed - but to further define the role each team member plays within a wider SDLC.
Pipeline Responsibility: Bringing shift-left to everyone requires you to identify and group all the teams that individually contribute to the dozens of pipelines in your organization. Defining this responsibility helps sow fertile soil for true shift-left.
With that foundation in place, Sriya Potham - Field CTO at Wiz - takes us through the 4 best practices that organizations need to implement for true shift-left.
#1. Align and Communicate
Top-down buy-in is critical for success due to the magnitude of organizational change that needs to take place. The engine of your shift-left efforts is the leadership of each team; communication is the driver that gets the wheels turning.
Sriya Potham was formerly a cloud security architect at a travel organization that recently embarked on their own shift left transformation. Having already provided security with centralized visibility, this organization was able to identify some of the real-life security implications of previous infrastructure choices. This allowed them to begin aligning dev teams alongside security. The way in which the CISO helped push this cultural change is by picturing it as a team sport. While security was given a greater degree of transparency, the dev teams were similarly offered a seat at the table. Prioritizing their need to be able to move fast, United acknowledged that developers needed to be able to act outside of a security tool.
With both teams on board, they were able to start drawing out the roadmap of their shift-left transformation. Defining a baseline risk level was critically important, alongside drawing a hard line for what can never be shipped into production.
#2. Measure
While templates are important, it's vital that goals are kept tightly in line with what's technically possible. Many organizations struggle with this - and this road bump is usually due to the security issues that remain on the right. Bringing a development cycle in line with your security goals requires constant measurement of how well your infrastructure-as-code templates are performing against where you want to be. Speed of product development, time to fix exploits, and colleague and customer satisfaction are all vital metrics to keep an eye on.
Foiling many of these metrics may be your current security debt; one of shift-left's highest hurdles. By implementing tools that identify and prioritize toxic combinations of attacks, security cleanup in production can be significantly expedited. Throughout the time your teams spend working on this security debt, it's vital to keep the long-term view in mind. The guardrails that help define your risk tolerance here will form the foundation for bringing them further left.
Placing everyone on the same page - and keeping them there - is a critical component to this best practice. The measurement process needs to include a critical look at any exceptions of your infrastructure as code templates don't meet your risk baselines - or some other metric starts to fall - you need to not only fix the templates but also communicate broadly to those that use the template..
#3. Enforce and Automate
Once you've iterated on your infrastructure-as-code templates and are comfortable with the results, you can begin the process of enforcement. Now, every build is automatically checked against your security policies. If significant issues are found, the deployment is blocked, and the developer is provided with immediate feedback on why it failed the check. Enforcing in this manner removes the friction of constant back-and-forthing, granting dev teams the autonomy to deploy securely. By enforcing the guardrails throughout the pipeline, and supporting developers with automated help and feedback, security is given back the time to prioritize strategic work - such as overseeing your organization's latest acquisitions.
#4. Share and Improve
At the level of the security analyst and developer, the democratization of security knowledge is how you bring security guardrails into every single app and pipeline being built. This knowledge should filter upward and across teams: create internal working groups to continuously improve processes, templates, and policies. They should foster even greater shift-left success and conduct regular progress updates on how teams are internally resolving issues earlier in the pipeline.
This momentum builds into even greater democratization of your security program, as devs and engineers now have a channel through which to share and improve the process. As a result, security can finally saturate the earliest phases of the SDLC.
How Priceline Proactively Prevents Risks in Their Pipeline
Priceline's cloud-first infrastructure approach enabled them to innovate quickly but led to their security team spending considerable time fixing one-off security issues in production. They decided to undertake a shift left strategy to address systemic issues and ensure they were secure by default.
By leveraging the four key practices outlined above, Priceline was able to clean up their production environment, determine the guardrails that would enable their developers to deploy securely, and build enforcement into their CI/CD pipeline. By learning from the right, then shifting to the left, Priceline successfully implemented invisible guardrails that give developers autonomy. See how Priceline saved their security and development teams time and reduced the cost to secure their cloud by shifting security left..
