Shifting left on security with Google Cloud infrastructure

The concept of “shifting left” has been widely promoted in the software development lifecycle. The concept is that introducing security earlier, or leftwards, in the development process will lead to fewer software-related security defects later, or rightwards, in production.

Shifting cloud security left can help identify potential misconfigurations earlier in the development cycle, which if unresolved can lead to security defects. Catching those misconfigurations early can improve the security posture of production deployments.

Why shifting security left matters

Google’s DevOps Research and Assessment (DORA) highlights the importance of integrating security into DevOps in the 2016 State of DevOps Report. The report discussed the placement of security testing in the software development lifecycle. The survey found that most security testing and tool usage happened after the development of a release, rather than continuously throughout the development lifecycle. This led to increased costs and friction because remediating problems found in testing may involve big architectural changes and additional integration testing, as shown in Figure 1. For example, security defects in production can lead to GDPR violations, which can carry fines up to 4% of global annual revenue.

Figure 1.jpg
Figure 1: Traditional Testing Pattern

By inserting security testing into the development phase, we can identify security defects earlier and perform the appropriate remediation sooner. This results in fewer defects post-production and reduces remediation efforts and architectural changes.  Figure 2 shows us that integrating security earlier in the SDLC results in overall decreases in security defects and associated remediation costs.

Figure 2.jpg
Figure 2: Security Landscape After Shiting Left

The 2021 State of DevOps Report expands the work of the 2016 report and advocates for integrating automated testing throughout the software development lifecycle. Automated testing is useful for continuously testing development code without the need for additional skills or intervention by the developer. Developers can continue to iterate quickly while other stakeholders can be confident that common defects are being identified and remediated.

From code to cloud

The DORA findings with regard to code security can also be applied to cloud infrastructure security. As more organizations deploy their workloads to the cloud, it’s important to test the security and configurations of cloud infrastructure. Misconfigurations in cloud resources can lead toward security incidents that could lead to data theft. Examples of such misconfigurations include overly permissive firewall rules, public IP addresses for VMs, or excessive Identity and Access Management (IAM) permissions on service accounts and storage buckets. 

We can and should leverage different Google Cloud services to identify these misconfigurations early in the development process and prevent such errors from emerging in production to reduce the costs of future remediation, potential legal fines, and compromised customer trust.

The key tools in Google’s toolshed are Security Command Center and Cloud Build. Security Command Center provides visibility into misconfigurations, vulnerabilities, and threats within a Google Cloud organization. This information is critical when protecting your cloud infrastructure (such as virtual machines, containers, web applications) against threats, or identifying potential gaps from compliance frameworks (such as CIS Benchmarks, PCI-DSS, NIST 800-53, or ISO 27001. 

Security Command Center further supports shifting security left by allowing visibility of security findings at the cloud project level for individual developers, while still allowing global visibility for Security Operations. Cloud Build provides for the creation of cloud-native CI/CD pipelines. You can insert custom health checks into a pipeline to evaluate certain conditions (such as security metrics) and fail the pipeline when irregularities are detected. We will now explore two use cases that take advantage of these tools.

Security Health Checker

Security Health Checker continuously monitors the security health of a Google Cloud project and promptly notifies project members of security findings. Figure 3 shows developers interacting with a Google Cloud environment with network, compute, and database components. Security Command Center is configured to monitor the health of the project.

When Security Command Center identifies findings, it sends them to a Cloud Pub/Sub topic. A Cloud Function then takes the findings published to that topic and sends them to a Slack channel monitored by infrastructure developers. Just like a spell checker providing quick feedback on misspellings, Security Health Checker provides prompt feedback on security misconfigurations in a Google Cloud project that could lead to deployment failures or post-production compromises. No additional effort is required on the part of developers.

Figure 3.jpg
Figure 3: Security Command Center in a Google Cloud Environment

Security Pipeline Checker

In addition to using Security Command Center for timely notification of security concerns during the development process, we can also integrate security checks into the CI/CD pipeline by using Security Command Center along with Cloud Build as shown in Figure 4.

Figure 4.jpg
Figure 4: Security Pipeline Checker Architecture

The pipeline begins with a developer checking code into a git repository. This repository is mirrored to Cloud Source Repositories. A build trigger will begin the build process. The build pipeline will include a short waiting period of a few minutes to give Security Command Center a chance to identify security vulnerabilities. A brief delay may appear undesirable at first, but the analysis that takes place during that interval can result in the reduction of security defects post-production. 

At the end of the waiting period, a Cloud Function serving as a Security Health Checker will evaluate the findings from Security Command Center (Connector 1 in Figure 4). If the validator determines that unacceptable security findings exist, the validator will inject a failure indication into the pipeline to terminate the build process (Connector 2 in Figure 4). Developers have visibility into the failure triggers and remediate them before successfully deploying code to production. This is in contrast to the findings in the 2016 State of DevOps Report wherein organizations that didn’t integrate security into their DevOps processes spent 50% more time remediating security issues than those who “shifted left” on security.

Closing thoughts

DORA’s 2016 State of DevOps report called out the need for “shifting left” with security, introducing security earlier in the development process to identify security vulnerabilities early to reduce mitigation efforts post-production. The report also advocated for automated testing throughout the software development lifecycle. 

Google looked at two ways of achieving these objectives in Google Cloud. The Security Health Checker provides feedback to developers using Security Command Center and Slack to notify developers of security findings as they pursue their development activities. The Security Pipeline Checker uses Security Command Center as part of a Cloud Build pipeline to terminate a build pipeline if vulnerabilities are identified during the build process. To implement the Security Heath Checker and the Security Pipeline Checker, check out the GitHub repository. Google hope these examples will help you to “shift left” using Google Cloud services. Happy coding!