Security-as-Code Gains More Support, but Still Nascent

Google and other firms are adding security configuration to software so cloud applications and services have well-defined security settings — a key component of DevSecOps.

5 Min Read
Photo of Google Cloud office building
Source: John Crowe via Alamy

The increased adoption of cloud infrastructure by companies looking to improve agility and support a hybrid workforce has led to more development teams adopting security-as-code as a way to build security into software and products.

Over the past year, for example, Google has pushed security-as-code as a fundamental component of its cloud offerings, identifying in January "software-defined infrastructure" as one of the eight megatrends driving the security of the cloud. Encoding security configuration as code that can be an input into development and deployment processes lets organizations analyze their security configuration, change and redeploy easily, and continuously monitor the state of their security configuration to evaluate whether it matches policies.

The result is analyzable security configuration and continuously verifiable controls, says Phil Venables, vice president at Google and CISO for Google Cloud.

"The great thing about security-as-code is that you know the configuration that you have deployed exactly corresponds to what you had specified and analyzed as meeting your security requirements," he says. "Many breaches out there are not necessarily the result of an unknown risk, but are usually the result of some control that the organization thought they had not being deployed and operating when they needed it the most."

Security-as-code is an extension of the infrastructure-as-code movement that has come about as software-defined networks and systems have become more popular. DevOps teams have adopted infrastructure-as-code as the de facto standard for building and deploying software, containers, and virtual machines, but now companies are betting that the shift to cloud-native infrastructure will make security-as-code a key part of a sustainable approach to security.

How Security-as-Code Works
In 2021, consulting firm McKinsey and Company identified security-as-code as perhaps the only way to secure cloud application and infrastructure at the speed at which modern businesses move.

"Capturing value in the cloud requires most companies to build a transformation engine ... to integrate cloud into business and technologies, drive adoption in priority business domains, and establish the foundational capabilities required to scale cloud usage safely and economically," the consulting firm wrote in a position paper. "SaC is the mechanism for developing foundational capabilities in cloud security and risk management."

Google intends to make the concept much more functional and part of any cloud infrastructure. In November, the company's Cybersecurity Action Team announced a Risk and Compliance as Code (RCaC) solution.

Companies that have embraced DevOps know that repeatable software builds rely on being able to specify the configuration of infrastructure elements — whether software applications, pipeline builds, or containers — as code in a file. This infrastructure-as-code approach allows developers and operations specialists to express and analyze the configuration before it is deployed.

Security-as-code aims to do the same thing for security, in an approach that many have called DevSecOps. Security-as-code expresses the security configuration of a variety of elements, including what security testing should be performed, the criteria for vulnerability scanning, encryption requirements, and access controls.

How Does it Affect SBOMs?
Google sees the current efforts to make software bills of materials (SBOMs) more explicit and functional as a key component of the future of software-as-code. The components of a software program could be analyzed during any build and the policies described in the security-as-code file would be applied. Using a component that is vulnerable to a specific threat, such as Log4j, could stop the build. Other requirements, such as a high level in the Supply Chain Levels for Software Artifacts (SLSA), could also be specified, Google's Venable says.

"This mechanism allows you to start making richer decisions," he says. "This programmability of the environment to enforce security policy is pretty transformational compared to what any of us used to be able to do in traditional on-premise environments."

Google is joined by others blazing a trail into the security-as-code arena. The growing movement to encode security as a configuration file that can be incrementally improved led security firm Tenable Network Security to acquire Accurics, a maker of security-as-code technology.

"It's far more effective to find and fix the issues at the point of creation in code, rather than where they manifest in the cloud," Renaud Deraison, chief technology officer for Tenable Network Security, said in a blog announcing the acquisition. "In this way, we can ensure that what is deployed is secure by default and that any fixes are a simple merge request rather than a patch or operational afterthought."

Not everyone is convinced that security configurations will be ensconced in code anytime soon. While configuration files traveling along with software-defined infrastructure components could bring significant benefits — such as the audit ability and improved change management — companies are still too reactionary to adopt the technology, says Brian Fox, chief technology officer and co-founder of Sonatype, a software-management and security firm.

Software composition analysis (SCA) services that can automate the identification of risky software components — a service that Sonatype provides — provides some of the automated benefits of security-as-code. Most businesses have no idea of even what components make up their software, Fox says.

"We are super early in the adoption cycle with this," he says. "All the reasons that infrastructure-as-code made sense will make sense with security-as-code, but the industry is not quite there yet, because so many people do not have the mechanisms to even do this, never mind doing it as code."

About the Author(s)

Robert Lemos, Contributing Writer

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights