The Benefits of Involving Developers in Securing Your Infrastructure

Cloud infrastructure simplifies security compared to on-premises datacenters. In the old on-prem world, we had to secure the entire stack from physical security to updating networking equipment and hypervisors, in addition to creating physical and logical separation of networks. Thanks to the shared responsibility model, “security of the cloud” is the responsibility of our cloud provider.

However, the stack above the physical and hypervisor level is still up to us to secure. Luckily, in the cloud that layer is pre-configurable using code. Everything from firewall rules to encryption policies can be defined using Infrastructure as Code (IaC), such as Terraform and CloudFormation. These templates create versioned, repeatable ways to provision cloud infrastructure.

The balance problem

The programmable nature of cloud computing has driven the rise of platform engineers, DevOps engineers, and site reliability engineers (SREs) provisioning their own infrastructure to meet the architectural needs of the applications they support. This has been a boon for increasing developer velocity and innovation. Yet, we’ve seen more than 199,000 potential vulnerabilities in IaC templates, leading to frequent stories of publicly accessible databases with unencrypted sensitive data.

The options are either to bring security assessments at the end of a development cycle or bring them up during the cycle. The first option breaks agile methodologies and takes engineers out of context to make changes.

Instead, we need to embed security in every stage. Security should act as advisors, following the SRE mantra of automating away the toil of security reviews, to ensure that misconfigurations are fixed. Bringing developers into the security process has clear benefits:

Amplified impact of patching early

Each IaC template provisions dozens to hundreds of cloud assets, such as virtual machines, security groups and databases. If each asset has multiple misconfigurations, the result could be thousands of alerts. All of this from a single template.

By fixing misconfigurations during development, we mitigate many of those vulnerabilities in production. We close unnecessary ports and encrypt databases by default. Engineers are saved from on-call headaches while security teams have less alert noise. Both teams are happier and more productive as a result.

Developers outnumber security professionals

There are almost nine times as many developers as security professionals. Security teams can’t keep up without finding ways to scale. Developers have both the context and expertise to know how to patch issues -- and the numbers to do it faster.

But we can’t expect developers to have deep security expertise in all areas of infrastructure security. Providing them with early feedback while they write IaC templates, rather than when they go to deploy or post-deployment, arms them with the ability to repair common misconfigurations.

On the job security training for developers

Research shows that active learning is more effective than lecture style training. By providing developers with feedback on how to make their IaC templates more secure, they can pick up on the patterns for future development.

That way security is baked into the planning phase instead of patching after infrastructure changes make it to production. This learning model will translate to infrastructure that is secure by design, the best possible outcome.

Improved productivity and velocity

Context switching eats up 20-80% of engineering productivity. The traditional method of security reviews brings security patches back to engineers once they’ve already moved on to other development work. Further, research finds it costs 4-5x more to fix a bug in production than in development. When engineers have to remind themselves of the details of the architecture they’ve built when they’ve moved on to other work, it eats into valuable time.

In a competitive digital economy, engineering velocity is a key performance indicator. Security needs to help speed up development without compromising risks. Bringing specific feedback about misconfigurations in templates during normal workflows speeds up patching and lets engineers move on to their next task.

Security as an advisor, not gatekeeper

By prescribing infrastructure using IaC templates, security teams give up some control to other organizations. But providing early feedback and security automation alleviates some of these concerns. Empowering engineers to patch their own templates is a faster, scalable way to improve cloud posture without compromising security.

This also better supports security’s goal -- to help with growth, rather than slowing it down. Many engineers fear the result of the security assessment, but we’re working to change that. Security teams are starting to join scrum meetings and embedding security earlier in development.

The connection between teams is improved with smarter tools like cloud native security platforms. These can help automate security with built-in policy guardrails and actionable feedback when policies are violated, allowing engineers to find and fix misconfigurations in IaC templates on their own. They can also add security checks natively in developer tools like integrated developer environments (IDEs), providing feedback before the build stage. This means fewer failed builds and happier cross-functional teams.

With IaC templates to help DevOps teams move faster and smarter security platforms to protect them, security teams can rest easy knowing policies are in place, while developers don’t have to dread security reviews tearing up their code.

Taylor Smith is a Senior Product Marketing Manager at Palo Alto Networks covering Shift Left and container security. He is passionate about helping customers develop secure cloud native applications and infrastructure. Previously, he held product marketing and strategy positions at Gremlin, Cisco and NetApp.