Security as Code, Shift Left Security, and Security Automation are three of the most popular methodologies and frameworks for building a more secure organization. All three approaches focus on operationalizing security—that is, making security an integral part of an organization’s daily operations, deployment, and software development. Still, each approach has a distinct focus that’s worth exploring:

• Shift Left Security builds on the established practice shift-left testing, which focuses on addressing quality concerns early in the development cycle. Security tests and reviews become first-class tasks in the project plan from its earliest phases, and they’re the responsibility of the entire team.
• Security as Code is similar to the Shift Left Security, but makes explicit the need to convert security tests, policies, and procedures into code that’s run as part of daily builds and deployments.
• Finally, Security Automation extends the focus beyond the development phase, automating security actions during normal business operations. When an organization adopts the Security Automation approach, it deploys infrastructure that automatically scans for, detects, and even remediates suspicious activity.

Below, we look at each approach in detail.

Shift Left Security

Shift Left Security is about addressing security concerns earlier in your development cycle. Shift Left Testing was first introduced in 2001 by Larry Smith to encourage more comprehensive testing done by both developers and QA earlier in the process. Smith encouraged that, if you shift left, “you can expand your testing program while reducing manpower and equipment needs—sometimes by as much as an order of magnitude.” The idea of reducing costs by finding errors earlier in the process can be traced back even earlier to 1981 with the release of Software Engineering Economics by Barry Boehm. Today, when we talk about Shift Left and security we are still focused on finding and fixing bugs earlier in the pipeline. Smith advocates for automation that can be run by “entry-level engineers (or even nonengineers)” whereas today we have the luxury of CI/CD pipelines and pull request-based testing. 

Shifting left on security has many key benefits and has been identified by DORA’s State of DevOps research program as one of the key technical capabilities that drive higher software delivery and organizational performance. Shifting left means that teams can spend less time fixing security issues and more time delivering secure systems. By shifting left, responsibility for security is no longer confined to a single team, but instead becomes part of everyone’s mandate, resulting in high performing teams delivering more secure applications, infrastructure, and operations.

Security as Code

Security as Code consists of a multipronged approach of converting your security testing, policies and procedures into code. In practice, Security as Code includes pre-approved code, security testing, vulnerability testing, and the automatic enforcement of user and data access policies. This is a multi-step approach to leverage automation and provide transparency, repeatability and visibility into the checks and controls implemented by your security team. When you convert checks and controls into code, you broaden their coverage by applying them at every step of the build pipeline from pull request to testing in production.

Adopting Security as Code brings about many add-on benefits, ranging from smoother collaboration to improved visibility. In turn, this means shorter release cycles and, ultimately, better overall security. Security as Code forces you to turn opaque, manual actions into reviewable and repeatable actions. According to the DORA report, when security is built-in from the start with automated security tests, “high performers spend 50% less time fixing security issues compared to low performers.” Security as Code brings across many of these benefits by simply meeting developers where they are, in that it shares the tools and methodologies they already use. Security as Code brings a level of depth and coverage to an organization’s security posture that was not possible before.

Security Automation

Security Automation is the process of automating security actions whether it is to detect, scan or even remediate. Security Automation is often now associated with Security Orchestration Automation and Response (SOAR). SOAR is the process of automating security operations tasks that would have previously been done manually. Automated remediation, for example, is immediate and can solve problems without paging or distracting SecOps staff from their day-to-day tasks.

Security Automation is all about automating the boring, repetitive tasks so your team can focus on the high value and important targets. Automation brings repeatable, immediate results thereby enhancing your security and scaling your team. Security teams are overwhelmed with toil. They’re overwhelmed with alert fatigue. Security Automation puts your team back in control, allowing them to not just spend all of their time responding to alerts but giving them the freedom to actively make contributions. For example, if you can focus on Security Automation for your operations teams to reduce their workload responding to tickets, they can instead take an active role in hunting for threats. 

How these approaches interact

Shift Left Security, Security as Code and Security Automation can often be conflated with one another, but they interact more like a Venn diagram than concentric circles.

When an organization adopts Shift Left Security, they follow the path that Larry Smith laid out for QA teams, but apply it to their security teams instead. These teams shift their security work to the left (earlier) in the development pipeline by getting involved in design meetings, implementing security testing so that it applies to every pull request, and working with QA and developers to adopt better testing throughout the process. As you’ve noticed, most Shift Left Security changes relate to organizational changes and workflow changes, most of which can be accomplished without Security Automation and Security as Code. 

Security as Code advocates for Security Automation and shifting left where possible, but not all aspects covered by Security as Code can be automated or shifted left. One way to embrace all three approaches—shifting left, adopting Security as Code and deploying Security Automation—is by converting any manual security testing you may be doing late in the pipeline to automation that’s run on every pull request during development. 

Security Automation is best thought of as a subset of Security as Code. It often requires implementing some Security as Code practices, but Security Automation does not cover all of the processes and goals of Security as Code. For example, as compared with Security Automation practices, the more all-encompassing Security as Code practices would direct an organization to implement approved libraries. 

Finally, Security Automation can help with shifting left because it forces the automation of tests while moving them to be run earlier in your pipeline, but both Security as Code and Security Automation encompass much more than Shift Left Security. By adopting them, you improve your organization’s security posture across the board—from your code pipeline to your production assets to corporate assets.

Taking steps that address the common goal of operationalizing security

All three approaches we’ve discussed are sound approaches, but don’t let their broad scope prevent you from taking action. A good first step to begin adopting these security approaches is to assess what can be converted into an automated test or procedure, and implement that. In general, organizations have found it works best to start with simple vulnerability scanning in code repositories and incrementally integrate security into development and operations from that point on.

One extension of Security as Code that you can adopt to bring about an immediate, concrete security improvement—with minimal cost in organizational change—is Policy as Code. Policy as Code automates the workflows for user and data access authorization. Whereas traditional policy management demanded manual input and change tracking tasks that cut across your organization, the Policy as Code approach replaces those manual tasks with code—policy files readable by your team and by the systems that enforce the policies. This means the right people on your team can request, approve, and publish policy changes instantly in an audited system, boosting efficiency and security posture.

If you want to read more detailed examples on how to integrate Security as Code into your operations, check out our blog post on implementing lint and gosec for Golang.