There’s No Such Thing as DevSecOps

This article was published on devops.com on June 7th, 2018

After years of debate, few doubts remain about the viability of the public cloud for enterprise workloads. Enterprises are shifting to cloud-first and cloud-only strategies, looking to take advantage of all the good the public cloud has to offer. For applications built and deployed in the public cloud, it is all about automation. The cloud enables you to be elastic, reduce costs and deliver products faster. To achieve these goals, you need to automate your processes—building, testing and deployment.

Security Challenges of DevOps

This need for faster innovation led to the rise of DevOps, a set of practices and tools that result in tighter collaboration between development and operations. In the past, controlling the deployment processes was the responsibility of dedicated teams that wrote scripts. However, with DevOps, development and deployment merge. Software engineers must do more than write their infrastructure and business logic code; they also need to write the automation that surrounds it and take responsible for deploying it through the different stages until production.

However, even as development and operations come closer together, security has remained a function apart. While DevOps workflows are heavily automated, security checks for application and infrastructure code often are manual. DevOps and security teams are measured differently—delivery versus protection—and often are at odds with each other. The siloed approaches to security hardening that worked in the past are incompatible with the holistic, iterative software development and deployment model of DevOps.

For a developer, adding the responsibilities associated with DevOps is not complicated, but securing the environment is a different level of challenge that requires mindset shifts in multiple areas:

– Knowledge:  Software engineers are great at writing business logic. They write efficient code and develop highly available environments that can handle millions of concurrent users. However, the vast majority of developers don’t know about the latest CVEs or the proper configurations of SSL/TLS in the load balancer.

– Pace:  Successful development organizations move fast, frequently adopting new development trends and frameworks. Public cloud vendors release new features every week, and it can be difficult to follow and keep up, as engineering is usually measured by the ability to deliver and the quality of output. DevOps enables rapid release cycles, and the security must not hold them back.

– Scale:  Modern applications make the transition to work with microservices. When each development team owns its cloud environment (and sometimes multiple environments), the security teams suddenly find themselves dealing with huge distributed deployments. They can’t manually configure security when new features are released a few times a day in different environments.

– Heterogeneity:  Multi-cloud deployments are another emerging trend. New product teams are often given a free hand choosing their tools and infrastructure, and they may pick a new cloud vendor. While security teams have a voice in this decision, they do not have the last word. It may have taken the security team years to learn to deal with the existing cloud solution, and suddenly the organizational policy needs to be applied across different infrastructures.

– Consistency:  Enforcing organizational policy across different development teams is challenging. Each team has its own style, environment and development frameworks, meaning it’s never easy to ensure the security is applied uniformly.

However you choose to address all these challenges, one thing must be clear: Your DevOps cycle is not complete without handling the security.

 Choosing a Security Solution

Clearly, you can’t deploy services without properly securing them—you don’t want anyone to hack into your systems and steal your (and your customers’) information. Since cloud environments are dynamic and deployments tend to span across dozens of accounts, manual steps are not an option. Automation is necessary. Whether you acquire an enterprise security solution, adopt an open source security project or write your own tools, you need to make sure that they are: 

1. CI/CD ready: The solution can easily integrate into the continuous integration/continuous compliance pipeline. User-friendly APIs are required.

2. Scalable: Assessing hundreds of cloud environments requires the solution to be scalable and robust. When covering more cloud vendor capabilities, performance becomes critical and increasingly challenging.

3. Flexible: Each organization is different, and security needs can vary with each deployment. The baseline configuration of your security solution will never meet your requirements by 100 percent, so it’s important that you be able to adapt it to your needs.

4. Continuously updated: Cloud vendors add new features at a rapid pace, which also means new potential misconfigurations are generated all the time. Whatever solution you choose, it needs to match the cloud vendors’ speed and agility. Security solutions that are not being updated soon become useless.

5. Conveniently Reportable: Aggregated reporting is critical. Consuming the security findings in a convenient manner can assure that issues are properly mitigated.

6. Automatic remediation-capable: Many of the findings are easy to remediate automatically. Applying automatic remediation would enable the security team to focus on complicated tasks and reduce alert fatigue.

DevOps and DevSecOps Are (or Should Be) the Same Thing

Security is clearly an integral part of DevOps. DevSecOps is emerging to bring security and compliance management practices in line with the rest of DevOps. DevSecOps serves to call out the temporary chasm that exists between security and DevOps.

As security checks and controls get automated and integrated, DevOps and DevSecOps are converging to the same thing. Just like adjusting the mirrors and putting on the seat belt are part of standard procedure before pulling your car out of the driveway, assessing your security posture before releasing a new version of your product must become habit. To remain relevant, your security team must integrate into the CI/CD and make sure the newly created environments meet organizational policies.