My last two blogs on DecSecOps for public cloud providers, Automated security testing with AWS CodeStar and The Path to Automated and Integrated Security Testing, showed how complex the digital security landscape can be for organizations. They also talked about how our CyberRes security solutions can help provide security automation and enable a shift left culture within organizations for rapid deliveries with quicker security feedback.

Now in this part of the blog series, we will talk about DevSecOps solution that can be integrated with Azure DevOps CI/CD pipeline. But before we can even discuss that let’s have some understanding on how Azure works.

Azure DevOps Glossary

Azure DevOps is a platform where teams can plan smarter, collaborate better, and ship faster with a set of modern development services. Here are some of the keywords being used in the Azure DevOps world for development and deployment of cloud native applications.

Azure Boards: It is used for Agile planning which deliver value to your users faster using proven agile tools to plan, track, and discuss work across your teams.

Azure Pipelines: This is a continuous delivery service that builds, tests, and deploys with CI/CD that works with any language, platform, and cloud. Connect to GitHub or any other Git provider and deploy continuously. The pipeline consists of multiple things mentioned below:

Build and Release Tasks: A task is the building block for defining automation in a pipeline. A task is simply a packaged script or procedure that has been abstracted with a set of inputs.

When you add a task to your pipeline, it may also add a set of demands to the pipeline. The demands define the prerequisites that must be installed on the agent for the task to run. When you run the build or deployment, an agent that meets these demands will be chosen.

Agent: To build your code or deploy your software using Azure Pipelines, you need at least one agent. You can think of this as dedicated VM or instance consists of build tools to leverage for different application build and releases.

In Azure DevOps you will use either Microsoft provided agents a.k.a. “Microsoft-hosted Agents” or dedicated instances create by yourself a.k.a. “Self-hosted Agents”

Azure Repos: It is source control service (SCM) that hosts private Git repos and collaborate to build better code with pull requests and advanced file management.

Azure Artifacts: It is a managed artifact service that creates, hosts, and shares packages with your team, and adds artifacts to your CI/CD pipelines with a single task.

Cloud DevSecOps Process

Cloud Native application development moves though the process of continuous integration and testing to leverage cloud-based services. 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 how to spell CI/CD in Azure DevOps world, let’s look at how to secure application releases using Azure pipelines.

Here is the depiction of Azure Build Pipeline Process:

Azure Pipeline is a cloud service that we can use to build and test our code project automatically. The Azure pipeline has a lot of capabilities such as continuous integration and continuous delivery to test and build application code and ship to any target regularly and consistently.

Azure has two interfaces for its pipelines:

1. Pipeline as Code, support for YML
2. Classic UI, UI based interface

Since enterprises like to versionize the pipelines as well, every development team would like to go with YML file so that they can keep them updated and reuse as required. So we will understand the structure of the template from YML perspective.

Here are some of the components in the YML template for Azure Pipeline Build:

Stage: It is a logical boundary in the pipeline. It can be used to mark the separation of concerns. Each stage contains one or more jobs.

Job: A stage can contain one or more jobs. Each job runs on an agent. It represents an execution boundary of a set of steps.

Step: It is the smallest building block of a pipeline. It can either be a script or a task. A task is simply an already created script offered as a convenience to you.

The structure looks like the following:

Pipeline

Stage A

Job 1

Step 1.1

Step 1.2

...

Job 2

Step 2.1

Step 2.2

...

Stage B

...

Azure Build Template

Azure Pipeline has specific templates that support continuous integration. This is by default named as azure-pipelines.yml.

Azure-pipelines.yml: This is the default continuous integration (CI) pipeline file created by Azure. However, DevOps team has the flexibility to create as many pipelines as they want for different environment or configuration. Static application security testing (SAST) can be integrated within this process as separate stage/job/step.

Here is the sample of java technology based azure-pipelines.yml:

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

Here is the depiction of AWS CD Process:

Azure Release Process

Azure unlike AWS leverages the same pipeline i.e. azure-pipelines.yml to setup continuous deployment (CD) processes which promotes application artifacts to the next applicable environment i.e. QA, ST, UAT, Staging, Production etc. Dynamic application security testing can be integrated with this process.

Azure-pipelines.yml: DevOps team can have separate Stage for setting up deployment with different environment targets.

Here is the sample of azure-pipelines.yml:

Note: The above example demonstrates java application deploy and the highlighted events can be used to customize application deployment and start activities.

Security testing using Fortify with Azure DevOps pipeline

The Fortify platform can be leverage for security testing process that includes static code assessment (SAST) and Dynamic application testing (DAST).

Fortify supports AzureDevOps pipeline using build and release tasks for On-Premises and On-Demand platform. Please refer to the Azure marketplace for more info.

Fortify has the following build and release tasks available to CI/CD process for applications.

1. Fortify Static Code Analyzer Installation: The task automatically installs and configures Fortify Static Code Analyzer.
2. Fortify Static Code Analyzer Assessment: The task enables you to run Fortify Static Code Analyzer as a build step and passes all parameters required to perform a scan.
3. Fortify ScanCentral SAST Assessment: The task automatically submits a static scan request to Fortify ScanCentral SAST as a build step.
4. Fortify ScanCentral DAST Assessment: The task automatically submits a dynamic scan request to Fortify ScanCentral DAST as a build step. After the scan is complete, you can view the results in Fortify Software Security Center.
5. Fortify on Demand Static Assessment: The task automatically submits a static scan request and uploads code to Fortify on Demand as a build step.
6. Fortify on Demand Dynamic Assessment: The task automatically submits a dynamic scan request to Fortify on Demand as a build step.
7. Fortify WebInspect Dynamic Assessment: The task automatically submits a dynamic scan request to Fortify WebInspect as a build step.

Fortify can be integrated in Azure DevOps pipeline using two (2) approaches:

Approach 1: Native Integration

This approach is more of a native support from Fortify using the SCA tool. This approach is based on the synchronous method. This approach gives ability to build the quality gates since the result can be pulled while pipeline is running. Below are some of the steps and tasks leverage of performing an integration in CI pipeline.

1. Download the SCA Installer file ~1 GB
2. Download the fortify.license file

The first two steps require a publicly available file server or public facing SharePoint server or even application server which can be used to download these two required files by AWS pipeline agent/runner.

Below if the sample PowerShell script to download and save it in given directory:

3. Install the SCA using installer and license file
4. Update the Rule packs

5. Add SCA into windows path

6. Translate the code using SCA CLI
7. Analyze the code using SCA CLI

Note: Before adding the following steps into your pipeline.yaml file, please include “Generic Service Connection” for SSC server to auto update the results to public facing SSC server

Step 6 and step 7 are technology-based and below is the sample script for a JAVA based application, please refer to Fortify documentation for different technology scanning options.

Approach 2: NextGen Integration (ScanCentral Approach)

This approach is based on asynchronous method. Fortify has a ScanCentral engine which enable remote scanning quite easily. Below are some of the steps of performing a NextGen integration in CI pipeline.

1. Leverage the ScanCentral tasks for SAST Scan
2. Configure the client auth param
3. Configure the SSC CI Token
4. Configure if you like to upload to SSC
5. Configure the build tool param

The step 5 is technology based, please refer to Fortify ScanCentral documentation for different build options.

That’s it for this week.

Coming Up

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 below most popular cloud-based DevOps solutions.

1. Integrate with Google Cloud Platform
2. Integrate with GitHub
3. Integrate with GitLab

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 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.