Infrastructure as code (IaC) has fundamentally changed the way we build and manage infrastructure. By transforming cloud resources and their configurations into code, IaC allows us to store, version control and test our infrastructure just like we would our applications in code.
Infrastructure as code security takes advantage of the machine readability of frameworks — such as Terraform, CloudFormation and even Kubernetes manifests — to embed automated scanning for misconfigurations before infrastructure is provisioned or deployed. This process looks similar to static application security testing (SAST) and software composition analysis (SCA), wherein code is scanned for known vulnerabilities.
Although it’s much newer to the security scene and tackles a seemingly different segment of the market, infrastructure as code security is more than just a way to shift cloud security left. With the right approach, it can actually consolidate and streamline your infrastructure and application security efforts.
Streamlining Code Security Tooling and Processes
The core benefits of infrastructure as code are scalability and consistency. Using automation, IaC makes it easier to reliably provision resources across multiple environments at scale. To do this effectively, though, you need both solid templates and efficient workflows to compile, test and deploy resources. Those workflows and processes — from pull/merge request reviews to CI/CD pipelines — are the same workflows used to test application code for functionality and security.
Let’s say you integrate infrastructure as code scanning across the development lifecycle so you can identify and remediate misconfigurations earlier and faster. This is similar to what happens when you use SCA solutions to identify vulnerabilities in open-source packages. While the “what” of the two scanning types bears many similarities, the magic of IaC is that it streamlines the “how.” While infrastructure as code brings major scalability and consistency benefits, IaC’s real superpower is its ability to easily incorporate security into tools and processes you’re already using, such as open-source code scanning with SCA.
As with adopting DevSecOps for securing application code, the key to success when implementing infrastructure as code security is to surface security feedback directly in developer tools, such as integrated development environments (IDEs) and version control systems (VCSs). Giving developers feedback where and when they’re writing code reduces context-switching, improves remediation times and enables developers to get proactive with security.
DevSecOps Bonuses Keep Coming
The additional benefit here is that you can leverage your existing AppSec processes to shift cloud security left. Although the frameworks and languages in place will differ and the teams may not overlap, adding IaC security on top of your existing application security processes will leverage economies of scale and give everyone in your organization a common framework for finding and addressing both misconfigurations and vulnerabilities in code.
While leveraging similar processes and developer tools to surface feedback early is key, the pinnacle of DevSecOps success is having unified policy enforcement throughout your organization. In runtime, you would leverage a consolidated solution for vulnerability and cloud security posture management, and in build-time you would leverage code security checks as part of a golden pipeline. With this approach, you can minimize the risk of deploying misconfigurations or vulnerabilities and ensure that all deployed code is first tested by the same checks.
Unifying Infrastructure as Code Security and AppSec
Adopting infrastructure as code security is the only way to be proactive with cloud risk. But as IaC, containers, Kubernetes and other cloud-native technologies blur the lines between infrastructure and application, it’s more important than ever to unify how we secure them.
For example, an IaC module contains the configurations necessary both to define what a cloud resource will look like in runtime, as well as pull in the images that contain the service logic. As a result, it’s harder to separate infrastructure from application, as you might have done with traditional applications running on VMs.
Historically, the challenges of application and infrastructure security have been solved in siloes. The interconnected nature of cloud-native applications, though — where infrastructure and application code work together — means that securing these apps requires an equally interconnected approach that addresses and combines security across all the layers of your stack.
Without a streamlined approach that consolidates security across your applications and infrastructure, you can end up with coverage gaps. Let’s say your current security approach doesn’t proactively scan container images for vulnerabilities. If your IaC pulls in images, or if your CI/CD pipeline pulls multiple containers, it’s possible that your platform engineer won’t have visibility into potential vulnerabilities because they didn’t build the images in question. Without visibility, they’re likely to assume the images are secured. Preventing coverage gaps requires deeper visibility into the risks that connect your IaC and application components.
…
IaC enables everyone — developers, IT engineers and software testing teams, as well as security teams — to standardize and simplify the way they manage cloud security risks across a modern stack. While infrastructure as code allows you to shift cloud security left, its real benefit comes from enabling you to consolidate all your cloud security efforts within pre-existing processes and workflows.
Want to learn the 6 key features of any complete SCA solution? Download the Software Composition Analysis (SCA) Checklist.