We saw in my previous blogs on DevSecOps for public cloud providers,  Automated security testing with Azure DevOps, Automated security testing with AWS CodeStar, and The Path to Automated and Integrated Security Testing that the complexity of the application release cycle increases with the security landscape and how CyberRes solutions can play the security role as enabler and not the bottleneck. This includes a shift-left culture along with a continuous feedback loop for a secure release cycle. 

Now in this part of the series, we will talk about the DevSecOps solution that can be integrated with Google Cloud Platform CI/CD. But before we even discuss that let’s have some understanding of how Google Cloud Platform (GCP) looks at the CI/CD process and what tools they have in their kit to support it.

Google Cloud Platform DevOps Glossary

Google Cloud Platform (GCP) DevOps is a platform where organizations aim to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders.

GCP provides the DevOps using its managed services such as:

Cloud Build: Define custom workflows for building, testing, and deploying across multiple environments. DevOps team has full access to cloud-hosted and fully managed CI/CD workflows within their private network. Cloud Build scales up and scales down with no need to pre-provision servers. Pay only for what you use. With private pools, you get access to the same serverless benefits within your private network.

Artifact Registry: A single place for your organization to manage container images and language packages i.e., Maven and NPM. It is fully integrated with Google Cloud’s tooling and runtimes and comes with support for native artifact protocols. This makes it simple to integrate with your CI/CD tooling to set up automated pipelines. Please visit Artifact registry page for understanding how your artifacts can be stored and accessed. 

Cloud Run: Managed to compute platform that enables the organization to deploy and run containers that are invocable via request or events. It abstracts almost all infrastructure management which helps the DevOps team to focus on business applications only. The operations team can leverage this service to build a continuous deployment strategy. Please visit  the Cloud Run page for understanding how your built docker images are deployed.

Secret Manager: Stores API keys, passwords, certificates, and other sensitive data. It provides convenience while improving security. In scenarios where the DevOps team looking to store and access credentials, tokens or any other sensitive information can leverage Secret Manager inside cloud build service. Please visit the Secret Manager page for understanding how your secrets can be stored and accessed in Cloud Build.

Binary Authorization: deploy-time security control that ensures only trusted container images are deployed on Cloud Run. With Binary Authorization, you can require images to be signed by trusted authorities during the development process and then enforce signature validation when deploying.

Operations Suite (Stackdriver): Integrated monitoring, logging, and trace managed services for applications and systems running on Google Cloud and beyond.

Cloud DevSecOps Process

Cloud-Native application development moves thru the process of continuous integration and testing leverage cloud-based services. Google embraces serverless architecture, microservices, and container deployment to quickly build, deploy and manage business applications. In a typical CI and CD flow, a code change triggers the build. Successful builds result in artifacts that are a deployable package. Now, since we know what services Google Cloud Platform (GCP) offered, let’s look at how to secure application releases using GCP.

Here is the depiction of Google Continuous Deployment Process:

Major CI process has been taken care of by CloudBuild services using the cloudbuild.yaml configuration file.

Google CloudBuild CI Template

Google CloudBuild has specific templates/configurations that support continuous integration. This is by default named as cloudbuild.yaml.

cloudbuild.yaml: This is the default continuous integration (CI) configuration file created by Google. However, the DevOps team has the flexibility to create as many pipelines as they want for different environments or configuration. Static application security testing (SAST) can be integrated within this process as separate steps.

Here is the sample of java technology-based cloudbuild.yaml:

Note: The above example demonstrates java application docker, and the events can be used to customize application artifacts.

Google CloudBuild CD Template

In Azure Codestar, the release/deployment has been handled using appbuild.yml. However, with Google Cloudbuild.yaml, the deployment can be part of the same template, here is an example of the CD process.

Here is the sample of java technology-based cloudbuild.yaml:

Note: The above example demonstrates java dockerize application deploy and could be used to customize application deployment and start activities.

Security testing using Fortify with Google Cloud Build

The Fortify platform can be leveraged for security testing process that includes static code assessment (SAST) and Dynamic application testing (DAST). Fortify supports Google Cloud Platform using Cloud Build for On-Premises and On-Demand platform.

How you may ask? Well, that’s the easy part. You have the option to integrate Fortify with the below approach. 

Approach: NextGen Integration (ScanCentral Approach)

This approach is based on asynchronous scanning. Fortify has a ScanCentral engine which enables remote scanning quite easily. This approach is based on the public accessible ScanCentral controller part of the On-premises Fortify platform. Below are some of the steps of performing a NextGen integration in the CI pipeline.

Note: Step 4 is technology-based, please refer to Fortify ScanCentral documentation for different build options.

Let’s understand each step and build a Cloud Build YAML file that integrates Fortify platform to initiate a scan.

1. Pull fortify docker image
2. Run fortify docker

The first two (2) steps leverage Fortify public docker image for tools that can be used to pull and run docker image by GCP Cloud Build.

Below is the sample YAML section to pull and run the docker image:

3. Post commands to update the client.properties file

This step is required when the ScanCentral controller requires a client token for the initial handshake.

Below is the sample yaml extended to include client token:

4. Package the code using build tool integration

5. Translate the code (conditional)

6. Upload the code via ScanCentral Client to ScanCentral Controller

7. Results will be uploaded to SSC

8. Quality Gate (maybe in next release)

These steps package the code using build tool integration and then uploaded it into the ScanCentral controller to initiate a scan and upload it into the SSC application.

Now, to upload it into a publicly accessible controller requires a few parameters to be passed into the ScanCentral command. You can leverage GCP Secret Manager to get the information or use Cloud Build substitution variables as well, for simplicity I am using the latter. Here is the snapshot of the Cloud Build trigger.

Here is the final Integration step which can be injected into Cloud Build YAML to initiate Fortify SAST scan.

That’s it for now.

Coming Up

This blog is one in a series where I will cover most of the cloud providers to ensure DevOps teams understand the different approaches of integration and automating application security activities. In the next upcoming series, I will discuss how to integrate Fortify as part of your CI/CD process for the below most popular cloud-based DevOps solutions. I wanted to cover GitHub and GitLab also but there are many videos available on Fortify Unplugged YouTube channel, so I am revising to add Oracle and Wrecker CI tool integration.

1. Integrate with AWS CodeStar
2. Integrate with Azure DevOps
3. Integrate with GCP Cloud Build
4. Integrate with Oracle Cloud Infrastructure
5. Integrate with Wrecker

Learn more:

• Fortify DevSecOps Integrations
• Seamless Application Security
• Fortify CI Integrations Part 1 (GitHub, GitLab, Bamboo)
• Fortify CI Integrations Part 2 (Jenkins, Azure DevOps)

Join our Community | Fortify discussion forum | Tips & Info | What is Application Security