6 minute read time

DevSecOps with Public Cloud Providers: Automated security testing with Oracle Cloud Infrastructure (OCI) DevOps

by Micro Focus Employee in CyberRes

Oracle Cloud InfrastructureWe saw in my previous blogs on DevSecOps for public cloud providers, such as Google Cloud (Automated security testing with Google Cloud Build), Microsoft Cloud (Automated security testing with Azure DevOps), Amazon Web Service (Automated security testing with AWS CodeStar) and The Path to Automated and Integrated Security Testing show 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 the 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 Oracle Cloud Infrastructure CI/CD. But before we even discuss that let’s have some understanding of how Oracle Cloud Infrastructure (OCI) looks at the CI/CD process and what services they use to support it.

Oracle Cloud Infrastructure DevOps Glossary

OCI DevOps service easily builds, test, and deploy software and applications on Oracle Cloud. The DevOps build and deployment pipelines reduce change-driven errors and decrease the time customers spend on building and deploying releases

OCI delivers DevOps service using the following:

DevOps project: A placeholder of DevOps resources, needed to implement a CI/CD workflow. DevOps resources can be artifacts, pipelines, source code repo links, triggers, and environments.

Environment: A compute resource (such as Virtual Server, Container, etc.) where artifacts are deployed. An environment can also be a group of Compute instances, or a Container Engine for Kubernetes (OKE) cluster.

Artifact: A collection of binaries and deployment manifests that are delivered to the target deployment environment. DevOps artifacts can be a container image, an instance group deployment configuration, a Kubernetes manifest, or a generic artifact. Artifacts can be hosted on OCI repositories: Container Registry and Artifact Registry.

Code repository: Private Git repositories (repo) hosted by the DevOps service. You can store, manage, and develop source code with the DevOps code repositories. You also could link your external code repo hosted in GitHub and GitLab using external connection interface.

Build Pipeline: Defines a set of stages (single step in the pipeline) for the build process: building, testing, and compiling software artifacts, delivering artifacts to OCI repositories. Every pipeline works with a build specification file that contains build steps and instructions that are run by the build agent/runner.

Deployment Pipeline: A sequence of steps for deploying a set of artifacts to a target environment. A deployment pipeline contains stages that run sequentially or in parallel.

IAM Policies: DevOps services rely upon IAM policies to authenticate and authorize cross-service functions.

Cloud DevSecOps Process

Cloud-Native application development moves though the process of continuous integration and testing to leverage cloud-based services. Oracle embraces serverless architecture, 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 the Oracle Cloud Infrastructure (OCI) DevOps service offered, let’s look at how to secure application releases using OCI DevOps.

Here is the depiction of Oracle Cloud Infrastructure DevOps Continuous Deployment Process:

Oracle Cloud Infrastructure DevOps Continuous Deployment Process

Major CI process has been taken care of by Build Pipeline services using the build_spec.yaml configuration file.

Oracle Cloud Infrastructure (OCI) DevOps Build Pipeline build_spec Template

Oracle DevOps Build Pipeline service has specific templates/configurations that support continuous integration. This is by default named as build_spec.yaml.

Build_Spec.yaml: The build specification contains build steps and settings that the build pipeline uses to run a build. This is the default continuous integration (CI) configuration file used by Oracle DevOps service. However, the DevOps team has the flexibility to use another file defined while creating build pipeline. Static application security testing (SAST) can be integrated within this process as separate steps.

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

java technology-based build_spec.yaml

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

Security testing using Fortify with OCI DevOps 

The Fortify platform can be leveraged for security testing process that includes static code assessment (SAST) and Dynamic application testing (DAST). Fortify supports OCI DevOps Platform using Build Pipeline 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.

NextGen integration in the CI pipeline

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

Let’s understand each step and change the Build_Spec YAML file that integrates Fortify platform to trigger a scan.

1. Download Fortify Tool Installer
2. Install ScanCentral Client

ScanCentral Client

The above statements leverage Fortify public Git repo for FTI tool that can be install and used to setup and configure required fortify tools.

Please note that the client auth token (${client_auth_token}) can be an environment variable or a fixed value.

3. Translate the code (conditional)
4. Upload the code via ScanCentral Client to ScanCentral Controller
5. Results will be uploaded to SSC
6. Quality Gate (maybe in next release)

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

upload into the ScanCentral controller

Now, to upload it into a publicly accessible controller requires a few parameters to be passed into the ScanCentral command. You can leverage Oracle Vault to get the information or use standard variables as well, for simplicity I am using the prior. 

Here is the snapshot of the Oracle vault with build­_spec environment variables link.

Oracle Vault

Here is the final snippet which can be injected into Build Spec YAML to initiate Fortify SAST scan. After changing the environment variables to your actual Fortify platform values, of course!

Fortify SAST scan 2

Fortify SAST scan 3

You can go to the Fortify Cloud DevSecOps GitHub home page where you will find templates to integrate Fortify On Demand or ScanCentral Controller as well.

That’s it for now. 

Summary

This blog is a series where I like to cover most of the cloud providers to ensure DevOps teams will 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 youtube channel https://www.youtube.com/c/FortifyUnplugged, 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

Learn more:

Join our Fortify Community. Have technical questions about Application Security products? Visit the Fortify discussion forum.  Keep up with the latest Tips & Info about Application Security. We’d love to hear your thoughts on this blog. Log in or register to comment below.

Labels:

Application security