The history of the term “DevOps” is a bit murky at best. In truth, there really isn’t even a single agreed-upon definition. However, most agree that somewhere between late 2006 and 2009, the principles of combining developer best practices with classic operational methods as a combined discipline began to take center stage in IT circles. Many organizations realized that the ability to lead in their marketplace was tied to the ability to develop, release, patch, iterate, and operate their applications (customer-facing or internal) in a continuous delivery fashion. The goal of this approach was not only to increase velocity but to do so while maintaining quality and reliability.

In the early stages of this shift, security was not always an integral part of the process. Often, it was relegated to the evaluation of deployed artifacts in their “run-time” state. If issues were discovered, it was incumbent on the deployment team to “roll back” to the previous state and address the issue. While automation frameworks made this process easier, they still cost the business in delays, efficiency gains, and even customer satisfaction. What was needed was the integration of security into this DevOps paradigm. Hence, we have seen terms like DevSecOps emerge to call attention to this need.

When public Cloud Service Providers (CSP) became more widely consumed, so did the various automation frameworks to deploy cloud infrastructure and services. Enterprises deployed their IaaS substrate using native tools like Cloud Formation & Azure Resource Manager (ARM) templates and industry multi-cloud tools such as Hashicorp’s terraform. Organizations that were deploying modern application frameworks on container orchestration engines relied more on declarative modes of deployment leveraging a combination of version control and CI/CD systems. In general, however, the parties responsible for authoring, maintaining, and using these tool sets did not come from the security centers within the organization.

Securing the “Build Phase”

When evaluating the posture of the enterprise cloud estate, it is not enough to evaluate the run-time state of workloads and services. Policy evaluation must also be made at the digital transformation efforts' design and build stages. This is especially important for organizations leveraging automation on an increasing scale.

Cloud Native Application Protection Platforms (CNAPP) must take this growing requirement into account if they are to provide value to these “DevOps” or “Platform Automation” centers of excellence within customer enterprises. They should provide mechanisms for the evaluation of security policies at multiple points along the path. However, it is critical that these solutions maintain three important principles.

First, security and compliance policies must be authored, controlled, and updated by the security teams within the enterprise. We cannot ask platform automation teams to instantly become experts in security and compliance. Nor should they divide their focus away from the enterprise's digital transformation efforts for which they are a critical component. It is not enough to highlight a potential code block that will result in a security violation or risky configuration. The solution should be flexible enough to allow for exceptions as well as provide guidance directly to the code author for a compliant alternative.

Second, it is not feasible to expect that security teams are going to have access or even the expertise to interact deeply with the IDE, version control, or pipelines leveraged by those teams. These tools are firmly in the domain of the DevOps or automation teams. The process by which their code and builds are evaluated against the security and compliance policies of the organization needs to be as transparent as possible.

Third, the ability to “shift-left” (as it has been termed) security into the design and build process needs to be flexible to accommodate operational differences from one organization to the next. Every organization is slightly different in how they handle automation. An effective solution must be able to inject policy evaluation in the following areas.

Integrated development environment (IDE): When the authors of a given infrastructure as code (IaC) manifest are coding, the security teams must assess the organization’s policies directly within their IDE and be notified as to whether or not the file elements are compliant.
Code repository: When a pull request is submitted to a repository owner, any applicable security configuration policies should be evaluated and reported in an automated fashion. This can be done either by giving the originator the responsibility to correct the code settings or by the repository owner who can address it prior to merging into a branch.
Image registry: The resultant images that are built and stored in registries are the next point where policies and vulnerabilities can be investigated. New weaknesses are unknown by the builders and may be discovered after initial builds are stored in a registry. Therefore, performing a consistent and regular scan of these images provides a foundational layer of protection.
CI/CD pipeline: Much like IaC manifests described above, application deployment should also be evaluated against the organization’s security policy framework during the CD phase. CI/CD tools such as Jenkins and Azure pipelines should be integrated into a security platform to ensure that the application manifest is policy compliant prior to deployment.
Post-deployment: Continuous scanning extends into the running environment after the previous steps take place.

Conclusion: Securing Your Foundation

The public cloud increasingly serves as a foundation for the deployment and operations of new services. Along with the obvious scale, resiliency, and flexibility provided by this model, it also lends itself to an ever-increasing level of automation. Any enterprise looking at a CNAPP solution needs to ensure that policy and compliance controls can be linked to specific build and deployment tools. These platforms provide broad risk visibility and mitigation coverage across public cloud infrastructure and services, workloads, and data. Effective CNAPP protections are not only about posture configuration of the cloud environment. They are also the workloads running in those environments, as well as the deployment processes of those functions.

Whether organizations are using traditional instance–based workloads or container–based applications, it is critical to inject security policy assessment that controls and prevents compromised efforts to gain high–velocity digital transformation.

The Zscaler Posture Control (ZCP) platform recognizes the challenges that security and platform teams face in reconciling the needs of security and compliance with the demands of digital transformation. To that end, ZCP allows organizations to evaluate policies at all phases of deployment; from design and build through deployment and run-time.

Learn more: