The 4 Keys to Building Cloud Security Programs That Can Actually Shift Left

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 quasi-public, 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.

Don’t forget to also learn how Wiz protects organizations — reach out today.

#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.

Take United Airlines for example, an organization that recently embarked on their own shift left transformation. Having already provided security with centralized visibility, United was able to identify some of the real-life security implications of previous containerization 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, United was 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, as United Airlines discovered, 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 these 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 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 cleanup process needs to include a critical look at any exceptions and expectations; if your infrastructure as code templates aren’t quite right – or some other metric starts to fall – the top-down support needs to prioritize feedback from environment owners.

#3. Enforce and Automate

The goal of providing the right context to the right person in real-time is unreachable without automation. For organizations reliant on infrastructure-as-code, these guardrails are facilitated by continuous analysis into dev accounts and activity. Every build is automatically measured against the frameworks that have already been outlined and implemented. If significant issues are found within the code, the deployment is blocked, and the developer is provided with immediate feedback. 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 security analyst and developer, the democratization of security knowledge is how you get into every single app and pipeline being built. This knowledge filters upward: internal knowledge groups often foster even greater shift-left success, as do regular progress updates on how teams are internally resolving issues.

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 Fox Fixed the Shift-Left Disconnect

Melody Hildebrandt, CISO at Fox, recognized that her team was staggering under the weight of its own security tooling. Inundated with alerts that – even when fixed – made no palpable difference to the organization’s true risk level, Hildebrandt noted that the lack of context was not just wasting employee hours: it was further worsening the divide between security and development teams.

By fully committing to the four key practices outlined above, Fox was able to embed security in the day-to-day processes of over 150 team members. See how Fox connected engineers with the tools to accelerate their workflows and democratize security understanding.