July 30, 2021
The concept of shifting security left is not new, but historically this has meant little more than inserting security processes in the middle of development and slowing everything down. As you probably know by now, trends like “shift-left security” and “DevSecOps” refer to integrating security throughout the build cycle, rather than the end, where it traditionally resided—or should we say ‘languished?” We refer to this as the ‘zero moment of security truth’.
Starting from the ‘zero moment of security truth’ can help organizations keep workloads secure in the age of cloud-based applications and infrastructures that are constantly changing and constantly subjected to increasingly sophisticated cyber-attacks. In this article, I will review why and how a modern approach to shifting left can have a high impact on risk reduction and create a healthy balance of freedom and responsibility with security built in rather than bolted-on. From my experience of working with cybersecurity, I have identified a set of rules for securing applications. These rules explain what any company—whether it is a digital giant or a traditional company—must do to prosper in this digital age. For legacy companies that are becoming digital, I would like to make an impact to fill in the pieces that leaders often miss with respect to security.
First, security is vastly outgunned in headcount. Large development teams that are armed with CI/CD and IaC are unstoppable. Inserting security into development has also traditionally meant hiring and deploying software security experts into development teams with the ratio sitting around 1.5 security experts per 100 software engineers. This model simply does not scale when companies are confronting modern decentralized development.
Second, most of all vulnerabilities are from applications with application developers directly provisioning applications to the cloud by using cloud platforms like AWS, Google, and Azure using continuous integration and continuous deployment (CI/CD) for rapid software releases and updates. This can be viewed as an opportunity because starting from the zero moment of security truth (i.e., shift left) can start addressing nearly 80% of all your vulnerabilities in a single step. An additional benefit that is often overlooked is that shifting left helps organizations identify systemic problems.
Third, is speed since the power and scale of modern software development cycles adds a new risk dimension to security. Software provisioned with declarative Infrastructure as Code (IaC) can go from developer laptops to clouds to customers in seconds. This has shifted DevOps left and allowed developers to provision their own infrastructure using software development practices such as writing, testing, and executing code. If they want to make changes or tear down the infrastructure, they code it, test it, and then deploy the changes using declarative Infrastructure as Code (IaC).
Fourth, the more metrics we gather, the more compelling ‘shifting left’ in application development appears. For example, organizations could be looking at:
Cloud security is by default handled by developers because cloud services are by nature a world of self-service and automation. Unfortunately, many engineers bypass cloud security and compliance policies. For example, cloud misconfigurations cost companies nearly $5 trillion from 2018-2019 alone. A shift-left approach shifts security responsibilities to the ones creating software, the developers, and it shifts it to the beginning of the process when the developers are provisioning infrastructure. Shift left refers to moving security sooner in the development process. Shifting left involves making changes in when, where and how to apply security best practices. Security must build trust with developers and DevOps. Additionally, a tighter integration of security throughout the process leads to better security outcomes, versus tacking it on at the end.
Developers can make any fixes before committing code to production (e.g., leverage Terraform and CloudFormation for security before execution, just as they would test their application code for quality and reliability)— where it could affect customers and result in data loss. Let’s not forget that more-secure applications lead to fewer alerts. Once security teams are free from trying to deal with barrages of false alerts, they can focus on the ones that matter. This is true even for organizations that use automation, which is helpful but typically used sparingly. Either way, it’s far more efficient to prevent alerts than to try to deal with them as they arise.
This shift weaves security into the existing CI/CD processes leveraging APIs to integrate security solutions into the tools they already use while giving security teams visibility into what has been tested and fixed. The idea is to make sure developers know they are responsible for testing, which ensures that the whole process starts with a testing mindset, while automating the testing as much as possible. Code review quality checks are also key, as is teaching testers to code, as the line between developers and testers will and should begin blurring. Also, make sure everybody uses the same tools. Do all this and you would minimize the damage misconfigurations and vulnerabilities can cause while saving time and money in the process. That’s a win-win-win.