Rethink your DevSecOps: 4 key lessons for achieving security as code
A survey that the SANS Institute recently conducted of 281 organizations across the world showed that security groups are struggling to keep up with the rapid pace of change resulting from cloud adoption and the increasing velocity of software delivery.
With more IT workloads moving to the cloud, security teams now must contend with new challenges such as those related to vulnerabilities and configuration issues on public cloud infrastructures and those pertaining to API use, containers, and VMs. Production systems increasingly are being deployed in environments where infrastructure is defined through code, so security teams must also get up to speed on how to secure serverless environments.
The trends have put pressure on security teams to evolve their practices. In addition to implementing controls for a wide range of existing threats, security teams are now required to understand and use modern development tools and ensure security in coding. They need to figure out new software development workflows and tooling and add adequate guardrails and controls to the pipeline to ensure security and compliance.
Here are four major takeaways from the SANS report, "Rethinking the Sec in DevSecOps: Security as Code."
1. Security and compliance should be integrated into code
The accelerated adoption of cloud services and digital transformation initiatives since the pandemic forced a shift to a more distributed work environment has made it harder for security teams to detect and block vulnerabilities across the environment.
To keep up, organizations need to integrate security and compliance controls, policies, and processes into a development pipeline that now extends to cloud environments, said Eric Johnson, co-founder and principal security engineer at Puma Security and a senior instructor with the SANS Institute. That means having controls and practices for securing the software development lifecycle and integrating security checks to catch vulnerabilities and other threats in the workflow and the build pipeline.
Increasingly, it is also about understanding workflows that span cloud environments and knowing how to use new tools to build guardrails and secure defaults into the pipeline to ensure compliance with security policies, Johnson said.
A traditional policy might be in a Microsoft Word document sitting in SharePoint and gathering dust because hardly anyone is reading it, Johnson said as an example. The policy might spell out required supply chain vetting and version control for a particular application. Or it might pertain to the need for a particular software environment to meet specific CIS security benchmarks.
Security teams need to learn to script those policies or figure out how to use API calls to collect the information for every build and get that into a dedicated inventory type of system, so it becomes easier to ensure processes and controls are being followed during the development lifecycle, Johnson said.
Programmable configuration management tools are available, including Chef InSpec and Open Policy Agent, that allow security teams to automatically detect and correct policy drift. The effort for security teams now should be to integrate these tools into the development pipeline.
"Security teams need to learn those tools, and they need to learn those policy languages. They need to start writing those very human-readable stories and put them into code rather than just saying, 'This is what we need to do,' and hoping that is going to be the case."
—Eric Johnson
The SANS survey showed that 62% of organizations automatically enforce 50% or more of their compliance policies.
Dylan Thomas, head of product management at Fortify, the application security division of CyberRes, a Micro Focus line of business, said security as code allows organizations to implement security controls and policies in a repeatable, programmatic, and scalable manner—something that is not possible with manual processes.
"Security as code is an extension of the move toward where everything is code."
—Dylan Thomas
2. Software delivery velocity is outstripping the ability of security groups to keep up
The SANS survey showed that many organizations have taken advantage of the cloud, agile development practices, and DevOps to speed up software delivery in a cost-effective manner. Three quarters of organizations now deliver at least one software change per month—an increase of 14 percentage points compared to five years ago. At the same time, security practices have failed to keep up. Only 52% have automated security of any kind, and organizations are still only ramping up on infrastructure and the discipline needed for testing.
A large percentage of organizations have already moved to the public cloud and are using cloud-hosted CI/CD servers and container services such as Kubernetes and AWS ECS, but security teams often are doing things the way they always have done them, Johnson said. The SANS survey showed that 97% of organizations use at least one public cloud provider, and 57% use three or more of these providers for their workloads. Yet more than one-third (37%) of security teams spend less than half their time on cloud security-related issues.
The pandemic and the accelerated adoption of cloud services that it triggered has exacerbated matters and left security teams even further behind the curve, Johnson said.
3. Automation is key
The first step to making security repeatable and scalable is to automate it, said Thomas. "Once you have it automated, then you can start figuring out how to make it programmatic and easily adaptable," he said. The goal is not just about being able to do the same thing repeatedly, but also figuring how to make security processes more adaptable for the nuances of individual use cases, Thomas said. Yet a relatively large number of organizations continue to rely heavily on manual processes that don't scale, and cannot keep up with software delivery speeds or the changes resulting from cloud adoption.
The SANS survey showed that nearly two-thirds (66.2%) of organizations currently use automated builds, and 52% use continuous integration practices in software development. Yet just half (51.6%) use any kind of automated security testing, and only 29% of organizations have automated 75% or more of their security testing. Just 34% are using programmatic tools such as Chef, AWS CloudFormation, and Terraform to provision and configure infrastructure.
Two factors are at play here. One is that the industry is in the midst of a transformation from the security team being the owners of app sec to putting security tools into the hands of the people developing the code. As development and DevSecOps teams begin to take more ownership of security, they are going to want to automate, it, Thomas said. But it's going to be a gradual transition, he said. In fact, so far, only 36% of the responding organizations in the SANS survey said they had sifted security testing to development or DevOps teams.
The second factor is that there are still a lot of applications out there that aren’t modernized. It is unrealistic to expect legacy, monolithic app environments that run critical parts of the enterprise to automate security when the build environment itself is not automated, Thomas said.
4. Technology is not the biggest barrier to DevSecOps
Technology is key to successfully integrating security into the development pipeline. But the success—or failure—of DevSecOps efforts continues to depend heavily on factors that have nothing to do with technology. When respondents in the SANS survey were asked to identify the top five barriers to DevSecOps success at their organizations, people- and process-related issues emerged as the biggest problems.
Half of the respondents cited organizational silos between development, operations, and security as the biggest barrier, nearly 49% described insufficient budget as a problem, and shortage of app skills came in third, with some 38% identifying it as a barrier to success.
Similarly, the top factors contributing to DevSecOps success were people- and process-related as well. Nearly 52% viewed training of developers and engineers as the most important success factor; 51% cited communication between developers, security, and operations teams as crucial; and for some 48%, it was getting management buy-in.
We talk a lot about people, process, and technology, Thomas said. Technology for automating security is available, and it is easy for organizations to say they want to go faster.
"It really is the people and process elements that continued to be the most commonly cited reason for successes, and also the hardest ones to make repeatable and scalable."
—Dylan Thomas
Guardrails are required
Cloud adoption and the increased velocity of software delivery in recent years is forcing security organizations to refine practices for integrating security into the build pipeline. In addition to integrating controls for ensuring code security, security groups must now also acquire new skills for building guardrails into the pipeline to ensure compliance with policies across on-premises and cloud environments.
Download the free SANS report, "Rethinking the Sec in DevSecOps: Security as Code."