DevOps | Aug 19, 2021

Is Security as Code and DevSecOps the Future of Security?

Is Security as Code and DevSecOps the Future of Security? banner image

I don’t envy those on Infosec and compliance teams.  In addition to holding accountability for the security of company and customer data, they need to maintain compliance with appropriate regulations and standards, they need to satisfy the auditors that verify compliance.  On top of all of that, they have very little control over vulnerabilities that exist in the portfolio that they are responsible for protecting.

Security Teams Identify Risks, Development Teams Fix Them

Vulnerabilities, for the most part, are introduced into the portfolio by developers, and developers are the ones that remove vulnerabilities by implementing code changes.  When the security team finds a vulnerability that needs to be fixed, they first need to convince a developer that (a) it really is a vulnerability, (b) it really needs to be fixed, and (c) it really needs to be fixed now.  Then they probably need to help determine how best to fix it, because most developers are not security experts.  That’s a lot of work, multiplied by a lot of potential vulnerabilities.

It’s no wonder that backlogs are growing faster than problems are being fixed – and in most organizations, security teams are nowhere close to assessing all new releases.  There is simply too much friction in the process.

Many envision DevSecOps as a solution to this problem: embed security experts and/or security expertise into the development teams so that problems are found and fixed earlier and more often.  It’s a great idea.  I mean, DevOps has been a rousing success so it makes sense to apply the same approach to security.

Converting security findings into security fixes requires a lot of communication and manual effort

If we could appoint a single transformational change as the MVP that enabled DevOps in cloud teams, I think that Infrastructure as Code (IaC) has a strong claim to that title.  Operations was mostly a manual, or at least ad hoc, endeavor which required long lead times and lots of one-off effort.  Virtualization certainly helped to improve that, but provisioning often took days or weeks and could clearly not be included in automated processes.

IaC changed all of that, enabling DevOps teams to describe exactly what they need in code.  They can leverage tools such as Terraform and Kubernetes which provision (or deprovision) infrastructure to those specifications automatically and on demand.  It opened the door to new levels of reliability, predictability, scalability, elasticity, and governance.

Security as Code Enables Development Teams to Proactively Address Security

Security is facing a lot of the same types of friction.  Security assessments often take days or weeks, and security processes such as threat modeling, assessments, triage and prioritization require a lot of manual, ad hoc effort.  Extending that “as code” approach to security might help enable many of the same benefits.

With Security as Code, DevSecOps teams could describe in code exactly what security and compliance goals they need to achieve.  Assuming security as code tools analogous to those used for IaC are available, teams could leverage those to enforce compliance to the codified goals throughout the development process, ensuring continuous compliance and eliminating all meaningful security risks before applications are ever deployed.  The codified goals could even follow the application into the runtime environment to provide for enforcement at runtime as well.

Security as code can automatically enforce security policy and prioritize remediation efforts
Security as code can automatically enforce security policy and prioritize remediation efforts

The challenge — and security teams are already facing this — is building or finding tools that can effectively transform the manual steps into automated ones.  Probably the most difficult of those are the triage and prioritization of findings, because they require a deep understanding of the system architecture in order to determine which findings are exploitable, which are exposed to untrusted users, which have access to sensitive data, and so forth.

But isn’t that exactly what IaC provides?  An understanding of the system topology, resources, and relationships from which we can infer what is exposed to untrusted users on the internet; we can determine which resources have access to sensitive data stores; we can compute potential attack paths into the architecture.

Security as Code Addresses Risks In Development and Runtime

With this information, tools can automate the prioritization of findings and focus attention on those that are exploitable and must be fixed.  They can automate meaningful pass/fail conditions in pipelines, for example to break the build if and only if it contains high risk findings that expose sensitive data.  They no longer need to interrupt development teams with findings of dubious value; when they raise an alert, it is by definition something that is exploitable and must be fixed.  This type of tool can be effectively integrated into automated DevSecOps workflows without fear of disrupting productivity.

As security as code gains traction, expect to see lots of new approaches and improvements.  It’s a particularly good fit for approaches like GitOps, which already leverage a lot of automation based on codified infrastructure and deployment information.  Security as code can augment those automated workflows to ensure security risks are blocked before they are exposed to users.

But the best part is that this capability is available today!  Please contact us to schedule a discussion with our experts to learn how to build security as code into your processes.

Coming Soon: Code to Cloud Security Summit

Accurics at KubeCon + CloudNativeCon North America 2021

Accurics at DevOps World 2021 by CloudBees

We use cookies to ensure you get the best experience on our website. By continuing to browse this site, you acknowledge the use of cookies.