You have probably heard about infrastructure as code (IaC), and the benefits it delivers to those that adopt it. IaC is a great way for development teams to get more control over the deployment and runtime environment of their apps, and it’s a critical technology for those practicing devops with cloud native apps. A lot has been written about what it is, how it helps developers and software shops, and why you should use it, so I’m not going to rehash all of that.

Instead, I’d like to talk about an aspect of IaC that is often overlooked. Specifically, about how it can reduce the time and effort required to secure your apps. That’s true regardless of whether you’re just starting to think about security, or you already have rigorous security controls in your development process.

Security Starts and Ends with Developers

While many people think that security is the responsibility of a specialized security team, today’s reality is that you, the developers, write the code and you are increasingly responsible for the infrastructure upon which it runs. Security starts and ends with you.

Don’t be intimidated. You’re probably not a security expert and you may not even know where to start securing your apps. And getting access to a security expert’s help is rarely easy--they are one of the scarcest resources in most companies. The good news is that IaC actually makes it easy to start securing your apps.

IaC Pulls Everything Together

That’s not to say that security is easy, because it’s not; that’s why security experts exist. But IaC is all about defining your infrastructure as code (that’s literally its name!), and you don’t need deep security expertise to run automated tools on that code to eliminate security risks. IaC codifies the resources and relationships present in your infrastructure, enabling your tools to start the threat modeling process that has historically been done by security experts.

In other words, IaC enables you to start security work earlier and to automate much of that work. In addition to making security more accessible to non-experts, IaC also improves the lives of security experts. With IaC, security experts have a real opportunity to “shift left” and proactively address security risks rather than reactively addressing security risks in the deployed infrastructure.

And that’s the real message here: while IaC is going to make your lives easier as developers, it’s also going to make your security experts’ lives easier. As companies start to adopt IaC, it is important to demonstrate the value created through those efforts. As you build those business cases, the security team may become your new best friends.

Where to Start

Start by defining your security policy as code--establishing policies which can be assessed and enforced during development. Ideally your organization’s security experts can guide your choice of policies, but that’s not strictly necessary. There are already a lot of policies based on security best practices, which are a great place to start without building everything from scratch. The CIS Benchmarks are one example, and many others apply to specific situations, such as PCI DSS, GDPR, and HIPAA. These can help you establish basic protections like ensuring that port 22 (SSH) isn’t exposed to the internet, and your S3 buckets are not world-readable.

Because your infrastructure is defined in code, you can easily use open source tools such as Terrascan to verify that you don’t accidentally violate these policies. Try it out on your workstation, and don’t forget to add it to your pipelines and repo hooks. Congratulations, you’re making real progress toward securing your apps! Even better, as part of an automated process it’s easy, consistent, and you’re able to find and fix problems before customer data is at risk.

Managing Violations

When you first get started, you may have a lot of violations. Don’t worry, you don’t need to fix everything immediately. Managing the list is more a matter of prioritizing the findings so that you know where to focus your efforts, and IaC can help with that too. In addition to defining your resources in code, you also defined the relationships between those resources. Your tools can use this context to effectively prioritize the findings.

This is referred to as “Security as code”. While it may sound simple to prioritize findings, there is a lot happening under the covers (isn’t that always true in the cloud?) For example, one of your violations may relate to an unencrypted database on a private network. In itself, that may not be a big deal. In fact, it may be necessary. But don’t mark it “not a problem” yet. We know that breaches rarely happen through a single vulnerability, so you need to look at the bigger picture.

If there is a way for unauthorized users to access that private network, they could gain access to the unencrypted database. Our knowledge of resources and relationships enables us to put individual violations into broader context to understand relative importance. We can even identify breach paths, or chains of related violations, that could be leveraged to gain access to other resources. When a breach path is identified which exposes the database, you can prioritize fixing the violations along that chain in order to break it and eliminate the risk. Of course, encrypting the database is also a good idea.

That may sound pretty obvious to you as a developer, but this is a constant struggle for your security team. Without IaC, they need to invest a lot of effort into understanding specifications, interviewing developers and architects, monitoring the runtime environment, and so forth. Your use of IaC eliminates weeks of work for them. That’s real value that shouldn’t be overlooked.

Make it Self-Healing

And now for the best part: pretty much all of the work goes into setting things up. Once you are working with IaC and you have your tools in place, you can go back to focusing on developing code. You have protections in place that ensure your infrastructure is secure even before it gets deployed.

If any violations are found, advanced tools can submit merge- or pull-requests with complete fixes that ensure the violations are fixed correctly and easily through your normal code review process. That can even be extended into the runtime environment, creating true self-healing infrastructure--all changes, including those made to IaC during development or those made directly to the production environment, will automatically be assessed. Policy violations or deviation from the IaC baseline will automatically result in fixes submitted for review and merge.

So in addition to all the benefits of IaC discussed elsewhere, you’ll also be helping to establish automated, consistent security enforcement while reducing the effort required to run those tools, prioritize findings, and fix the problems. You’ll improve communication, streamline change management, and ensure that every change is recorded in the repository.