Much has been made of the concept of “shift-left security,” and rightly so. Shift left security practices can significantly reduce the risk of releasing software with security vulnerabilities into production. Shift left security also helps to optimize the continuous delivery chain by making security part and parcel of the development process.
Yet, to make the very most of shift left security, you need to do more than simply integrate security operations with development. You need to shift your entire culture left.
Shifting your culture left entails choosing the right personnel to ensure that you deliver secure and innovative software. It also requires designing and enforcing processes that maximize security at all stages of the delivery chain. Ultimately, shifting your culture left involves developing an entirely new paradigm and set of principles for software delivery and security, and using it to replace the philosophy that predominated in the age of waterfall delivery.
Intrigued? Keep reading for an explanation of what it takes to shift your culture left in order to improve software security.
The Shift-Left Concept
Before delving into the details of shift-left culture, let’s quickly recap what the shift-left philosophy entails.
The shift-left paradigm is relatively straightforward. The driving idea is that processes like software testing and security operations should take place early in the software delivery process, rather than waiting until software is in production (or close to it). In other words, the goal is to move processes to the left of the delivery chain.
Twistlock’s blog already explains the nuts and bolts of shift-left, so I won’t reiterate them here.
Building a Shift-Left Culture
Instead, I’d like to discuss the organizational and cultural changes that you need to implement in order to enable shift-left security. These are the types of changes I am referring to when I mention shifting your culture left.
As noted in the introduction, shifting your entire culture left requires more than just setting up the right processes and tools. You need to reshape the way your entire organization operates, with the goal of integrating all of your processes and personnel into the pre-production stages of the delivery pipeline.
A successful shift-left culture is one in which the default approach to software production centers on achieving as much as possible before code enters production—because once software is in production, making changes or resolving problems of any kind becomes much more difficult.
Following are tips for achieving the organizational and cultural transformation required to implement a shift-left culture.
Build the right team
To shift everything to the left, you need personnel who are prepared to engage with the early parts of the delivery pipeline.
This doesn’t mean that everyone on your team needs to be a developer. That would obviously not make sense.
You should, however, strive to find and retain people who have the expertise required to collaborate with development and—most importantly—are passionate about such collaboration. Your QA personnel don’t need to be elite hackers, but they should have the basic coding skills required to discuss testing processes with developers and ensure that QA work starts early in the delivery chain. The same is true of your security team. The security team needs to be able to speak the same language as developers.
Your developers, too, must be ready to collaborate with non-developers. While they need not be experts in every type of IT job, they need a basic understanding of roles like QA and security operations. This may seem hard to achieve because the stereotypical developer looks down upon colleagues in other positions that are typically viewed as less prestigious than development. (For proof of this stereotype, take a look at the autocomplete suggestions that appear when you start typing “developers hate” in Google!)
Of course, stereotypes do not reflect reality. Not all developers disdain people who are not developers. When building your development team, look for developers who talk about and appreciate the value of collaborating with other roles.
Maximize visibility
It’s hard to shift processes to the left when team members lack the ability to track the status of those processes.
For example, if a member of your security team discovers a vulnerability in pre-production code, brings it to developers’ attention, and discusses with the developers how the issue will be fixed, the security engineer should have the ability to track efforts addressing the problem. Otherwise, her request goes into a black hole from her perspective, and she lacks the ability to follow up in order to ensure that the vulnerability was adequately addressed.
You can improve visibility with liberal access policies within your organization for code repositories, CI servers and other systems. Access needs to be balanced against security concerns, of course, and with highly sensitive code or data, it may be better to limit access. But in general, a healthy shift-left culture is one in which team members are allowed maximum visibility into the organization’s systems and processes, even when that access is not strictly necessary for performing a specific job.
Empowering all of your team members with visibility across the organization leads to better security practices than keeping information inaccessible. The latter approach is essentially equivalent to security by obscurity, whereas the former allows more people to put their eyeballs on the code and processes on which your organization relies. In general, more eyeballs is a good thing, because it maximizes the chances of finding and fixing problems before they reach production. (After all, as the Linux folks like to say, given enough eyeballs, all bugs are shallow.)
Collect metrics
Metrics are important for helping to assess the impact of your shift-left cultural transformation. As you embark on your shift-left journey, collect and analyze metrics to determine (and communicate to your team) how the changes you make are leading to better results.
The metrics you collect toward this end don’t have to be overly complex. Simple data like the number of security bugs that are found before production versus those that appear in production reveal a lot. By tracking how data such as this changes over time, you can quantify that impact on your shift-left culture.
Strive for continuous improvement
Last but not least, remember that shifting culture to the left is not a one-and-done affair. In other words, it’s a process that should never really end. Once you have shifted some aspects of your organization and culture to the left, you should strive to do even more.
In a perfect software delivery world, everything would shift left, and the number of security vulnerabilities and other problems that are introduced in production software would decline to zero. In the real world, however, achieving absolutely no production bugs is not realistic. But that doesn’t mean you should ever cease to reach for that goal.
Think like Sisyphus (whom I, like Albert Camus, prefer to imagine as a happy guy), and keep striving for an existence in which zero-day vulnerabilities never happen, even if you know you’ll never fully get there.
