Cloud security fundamentals part 3: Empower your developers

In our previous blog breaking down The 5 Fundamentals of Cloud Security, we looked at the value of prevention and secure design. Mapping resource relationships and enforcing security guardrails throughout development helps greatly reduce an available attack surface. But who will enforce these guardrails when your security team is busy with other work? This should be where developers are able to step in. So let's look at another vital element in cloud security: empowering developers. 

Back in 2013, authors Gene Kim, Kevin Behr, and George Spafford wrote the book on DevOps: The Phoenix Project. The goal of the book was to promote DevOps, but their work was more prophetic than the authors imagined — especially when it came to cloud security. 

DevOps sought to better integrate IT operations teams into the software development life cycle, or SDLC, and enable teams to build and deploy better infrastructure at a faster pace. IT operations learned to understand development pressures, but perhaps more importantly, developers learned to plan and develop applications and infrastructure together more holistically.

You’ve likely heard a new term, though: DevSecOps. This term has arisen for many reasons, one of which stands out among the rest. Gene Kim explains:

The ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1. When Infosec is that outnumbered, without automation and integrating information security into the daily work of Dev and Ops, Infosec can only do compliance checking, which is the opposite of security engineering.

Essentially, this ratio reveals the number one priority of many companies: building software — not securing it. The solution is to empower developers to build security engineering into their development workflows.

In this article, we’ll lay out three principles cloud leaders can use to empower their developers and create a stronger, less costly security posture.

1. Use infrastructure as code wherever possible

Software has not only eaten the world — it’s eaten the cloud.

Cloud infrastructure can now be 100% software; in facts far as cloud customers are concerned, cloud infrastructure is 100% software. With infrastructure as code tools, such as Terraform and AWS CloudFormation, developers can build and manage cloud environments programmatically.

In the past, cloud security was a siloed activity, like most security functions. Security teams were stuck using Cloud Security Posture Management tools, which they used to scan running environments that engineering teams provisioned. Security teams then identified misconfigurations, prioritized them by severity, and assigned remediation tasks to DevOps teams.

But a major problem rose to the surface: misconfigurations, as well as other security issues, can only be caught after the fact. A 2017 IBM study laid out one reason why this is problematic. “It can cost up to 15 times more to fix a software bug found during the testing phase than fixing the same bug found in the design phase.”

Infrastructure as code changes the conversation. By enabling development teams to define, through code, the configuration of their cloud environments, companies can shift left — meaning they can move security work to earlier points in the SDLC for cloud infrastructure.

Security checks can then occur prior to deployment. The result is less runtime misconfiguration, fewer deployed bugs, and a much stronger security posture, much sooner.

2. Prioritize developer tool integrations

Security sometimes gets a bad reputation among developers because it’s often a series of steps companies tack on to the end of the SDLC, and this results in developers getting stuck doing a lot of manual work. Bugs and other flaws are not only harder to catch in later stages, they’re also harder to identify and remediate, often requiring time-consuming and costly rework.

The key is to find tooling that offers comprehensive, relevant integrations and use those integrations to add security capabilities to the development workflow. The goal isn’t to change how developers work, but to thread security into the way developers already work.

Focus on integrating security checks into developer tools, source code repositories, and CI/CD toolchains. Further, whenever you’re shopping for security tools, consider both the range of available integrations and the quality of those integrations. Both will be necessary to make security an integral part of the development workflow. Security tools for developers are only good if your developers use them.

3. Make developer guidance useful

DevSecOps isn’t merely an additive benefit. When developers have infrastructure as code and tight security tooling integrations at their disposal, they have the ability to get better and better at security engineering. As you empower developers and provide them the tools to use that power, their abilities start to scale.

With infrastructure as code, developers can learn how to build environments that are secure at an architectural level. And when companies infuse DevSecOps approaches into their cloud security programs, engineers automatically get security feedback and guidance as they code.

Developers can then get better at security engineering over time, meaning they eventually introduce fewer issues during development. Even when runtime issues arise, developers can better identify where in the infrastructure to apply fixes.

The key here is for security teams to act as internal tool vendors to developers. The best version of this practice is when security teams work closely with the development and cloud engineering teams to understand their use cases and workflows. From there, security teams can build, buy, and integrate tools that provide useful, timely feedback as well as specific guidance for remediation.

Sooner, faster, better, stronger

The earlier you can fix misconfigurations, bugs, and vulnerabilities, the better.

FormHero, which had one full-time security person alongside a 10-person development team, found this principle to be true when they were searching for tools to improve their time to remediation.

Says Ryan Kimber, Founder and CEO: “If you aren’t addressing problems during the developer workflow and you’re finding them and dealing with them in QA, it will take you 10 times longer to fix.”

With infrastructure as code, security tooling with tight integrations, and automatic developer guidance, cloud leaders can capture this 10x improvement and scale it across their cloud environments — leading to stronger, less expensive security.