A key goal of DevSecOps is to reduce friction between developers, DevOps and security. At most software companies, DevSecOps focuses on shifting security left (earlier in the development pipeline). However, teams often overlook emerging security risks at the other end of the pipeline (the cloud) which can end up causing more friction. Fortunately, new tools can help find and proactively mitigate those risks before they lead to data breaches.
When cloud infrastructure is not configured correctly, it can introduce substantial security risks. Such configuration problems are common, partly because of mistaken assumptions about who’s really responsible for cloud security, and lack of comprehensive and consistent monitoring.
“Many people believe that cloud infrastructure is intrinsically secure, because cloud providers have done a good job marketing public clouds as a secure solution,” said Guy Eisenkot, co-founder and vice president of product for Bridgecrew. “The platforms themselves are very secure. But the truth is, what you do inside your own part of a public cloud is up to you. So you have to ask yourself: Do the people on your team who are operating systems in your cloud infrastructure have the knowledge and tools to avoid mistakes?”
When code replaces hardware in a public cloud, security becomes similarly codified. “It used to be that you’d build a firewall by attaching it to data storage, with wires on the floor and hands on the devices. Today, that firewall is effectively 17 lines of code,” Eisenkot explained. “Security and DevOps used to manage configurations via knobs or switches in a web user’s interface. Now, those configurations are included in code manifests.”
The problem is that default settings for cloud configuration files are often less than fully secure. That is not always obvious to engineers and DevOps; nor are options to enhance security always obvious. This gap is not the fault of engineers. It is not realistic to expect every infrastructure engineer to develop strong expertise in their own cloud infrastructure, while also tracking the hundreds of policies and security best practices (and all the ongoing changes to them) related to maintaining a strong cloud security posture.
Additionally, it is increasing common for organizations to configure their cloud via infrastructure as code (IaC). This means using code to manage and provision computing resources, rather than manually configuring resources in the cloud. IaC simplifies and automates the provisioning of cloud infrastructure, while enhancing scalability and repeatability. IaC helps teams to save time and resources, but it also can introduce new complexity and risk.
For example, a classic cloud security misconfiguration occurs when a new cloud resource is provisioned via infrastructure as code and its default setting (which is to be public) isn’t correctly configured. Imagine keeping track of hundreds if not thousands of resources and modules for which that configuration needs to be assessed.
“There’s just a small set of mandatory arguments that engineers must fill in before deploying to the cloud,” Eisenkot said. “The rest is at the discretion of the developer. That includes crucial security settings. It’s a little different for every cloud provider, and each platform has its own programming language. It’s a lot to keep track of, and it keeps changing all the time.”
How to Make DevSecOps Comprehensive
Since IaC is relatively new technology, many engineers may not realize that cloud security policies can be enforced at IaC level, as well as in more traditionally recognized parts of the development/deployment pipeline. This common blind spot can undermine the practice of DevSecOps.
An emerging challenge to comprehensive DevSecOps is an outdated vision of what “security” means. For instance, cloud security risks are not security vulnerabilities in the classic sense, since they do not provide a clear path to exploit. Instead, cloud security risks emerge from interactions between layers of infrastructure. Whether a particular configuration presents a security risk depends on the needs of applications and users.
Identity and access management presents similar concerns for cloud configuration. It’s often challenging for engineers to define cloud access roles that have exactly the right permissions to execute a particular function. Cloud providers’ default settings for roles tend to be overly permissive, potentially allowing unauthorized access to sensitive systems and data. This type of error contributed to the major data breach at Capital One in 2019.
For cloud-native teams, realizing the full promise and value of DevSecOps demands a comprehensive approach to security which addresses cloud configuration and compensates for knowledge gaps. This presents two key challenges:
- Visibility. It’s impossible to for team members to manually review every configuration file, and to keep up with every cloud provider’s best practices. Automating visibility is the only way to provide complete and continuous coverage.
- Response. Security professionals are responsible for enforcing security policies. However, most of the real work of IaC security happens in code, and many security professionals lack the skills to immediately fix cloud security problems. This gap means that cloud security risks tend to linger, and that software engineers must spend time chasing down these issues when they should be writing new code.
Appropriate tooling can help both security and engineering automate cloud security visibility and quickly implement remediations.
Bridgecrew helps teams bridge gaps between infrastructure engineering and security best practices by implementing cloud security policy as code. Its policy engine automatically implements best security practices through automated scanning. This tool is embedded throughout the development pipeline via continuous integration/continuous deployment (CI/CD).
Bridgecrew also helps developers reduce information and task overload as the development pipeline accelerates, and as more automated solutions are put in place. “We not only alert developers of cloud configuration problems; we get them as close to the fix as possible, and we give it to them before it makes its way into the cloud,” Eisenkot said. “With our integrations, an engineer might receive an alert that says: ‘That code you just wrote might introduce a particular misconfiguration. Here’s a three- or four-line code fix to avoid that, if you want.’”
By consistently and automatically applying the right security controls at the right time, this approach helps teams reduce DevSecOps friction and enhance productivity.