Cyber risk is preeminent in today’s threat landscape, and that includes attacks on the software supply chain. In fact, the increase in cyberattacks on software supply chains is estimated to affect 45% of organizations worldwide. These are referred to as supply chain risks, and they include vulnerable code that may be included from open source or third parties.

These attacks are even more detrimental in critical systems, which include IT infrastructure and financial services organizations. There is also a great deal of tension within financial markets between the requirements on innovation and agility for banking solutions versus the security, compliance and regulatory requirements that CISOs (Chief Information Security Officers) and CROs (Chief Risk Officers) need to guarantee for their financial institutions.

IBM Cloud for Financial Services

This is where IBM Cloud for Financial Services shines—it helps clients to fill that gap by supporting innovation while guaranteeing security and compliance. The goal of IBM Cloud for Financial Services is to provide security and compliance for financial services companies. It does so by leveraging industry standards like NIST and the expertise of more than a hundred financial services clients who are part of the Financial Services Cloud Council.

IBM Cloud for Financial Services helps clients create secure and compliant hybrid cloud solutions with a focus on the complete software lifecycle (including continuous integration (CI), continuous delivery, continuous deployment and continuous compliance) by using IBM Cloud DevSecOps (also known as One Pipeline).

Depending on how third-party code is obtained, it is not always possible to run a complete CI process as part of their build. In that case, we need to apply alternative approaches, which will be described in this blog.

What is IBM Cloud DevSecOps and how can it be used to guarantee secure and compliant applications?

The DevSecOps pipelines, also referred to as One Pipeline, are used to deploy applications on IBM Cloud—checking for vulnerabilities and ensuring auditability.

The continuous integration (CI) pipeline is used to build the application, which includes DevSecOps best practices like unit testing, build, dynamic scans, evidence collection, artifact signing and vulnerability checks.

The continuous delivery/deployment (CD) pipeline supports continuous deployment of the application, including evidence collection, GitOps-based inventory flow and promotion of assets between environments, change management and compliance scans.

The continuous compliance (CC) pipeline periodically scans the deployed application for continuous compliance. It repeats many of the scans from the CI pipeline, ensuring that new vulnerabilities are detected and flagged.

Read more about the DevSecOps toolchains here.

The default approach for using IBM Cloud DevSecOps

Typically, applications are both built and deployed in IBM Cloud DevSecOps. The continuous integration toolchains build, test and package the code, and then they update two important repositories—the inventory and the evidence locker:

• The inventory tracks artifact deployments, signatures, and components in a GitOps model.
• The evidence locker contains items asserting that various required checks have been completed—unit tests, code scans, pull request reviews, etc.

These two repositories are created in CI and linked to the continuous deployment/delivery toolchain so that deployment readiness checks can be completed. The inventory determines what should be deployed, and the evidence locker determines if the application is secure and robust enough to be deployed.

Different build tools

It isn’t always possible to have IBM Cloud DevSecOps build applications, particularly from third parties. This can be for a variety of reasons—teams are more familiar with other build tools, the application may not be suited to the pipeline processes or teams may not want to devote time to a full transition to One Pipeline.

With regards to IBM Cloud for Financial Services, we still want applications to be run through One Pipeline deployment so that we can verify that the application or component is secure and has gone through the required checks. But for this to be achieved, we require the inventory and evidence pieces to be in place.

DevSecOps CLI

Fortunately, the One Pipeline CI and CD toolchains have their pipeline code logic mostly contained within the DevSecOps (or cocoa) CLI. This includes all of the pieces required to build the inventory and evidence lockers. So, in the event the One Pipeline CI cannot be used, the DevSecOps CLI can be integrated into existing CI systems, such as Jenkins, Travis or Gitlab. The CLI is available from Artifactory as either an npm module or a standalone binary file.

Here are some sample commands used in the CLI:

• cocoa check pull-request-approval: Checks the approval state of a pull request for a given commit.
• cocoa change-request check-approval: Checks the approval state of a change request (for deployment).
• cocoa inventory add: Adds an artifact to the inventory repository.
• cocoa inventory promote: Promotes inventory entries from one environment to another.
• cocoa incident add: Creates an issue for a failing task in a pipeline run.
• cocoa locker evidence add: Adds evidence to the evidence locker.
• cocoa locker evidence summary: Returns evidence summary for a given asset.

The full CLI command reference can be found here.

Case study: Financial Transaction Manager (FTM)

Financial Transaction Manager (FTM) is one such example where we could not adopt a full One-Pipeline-based solution. FTM is an already existing monolithic application, built using Jenkins with a complex build structure. Pipeline dependencies, build orders and a long build time make it a very imperfect candidate for One Pipeline continuous integration.

However, we still wanted to be able to install it on IBM Cloud for Financial Services using One Pipeline. We worked with the FTM team to integrate the DevSecOps CLI in their existing Jenkins-based pipelines.

This is an ongoing, gradual process to make the FTM Jenkins pipelines work to generate the required inventory and evidence items that are used in a One Pipeline deployment pipeline.

For an example of how the FTM team approaches the problem, they first created utility classes in their Jenkins script libraries to make interaction with cocoa as easy as possible. These utilities make it easy to upload a piece of evidence or inventory item to a Git repo, along with tool types, results, type of evidence, etc. An example of evidence collection is below:

cocoaUtils.collectEvidence( imageName, "icr-va", "success", "com.ibm.cloud.image_vulnerability_scan", "artifact", "app-image")

This allows the FTM team to add evidence wherever it is deemed useful, and it can be integrated into any part of their Jenkins infrastructure. Here is an example of an inventory item being added:

cocoaUtils.addInventory( imageName )

Conclusion

In this exercise, we showed how we can create a secure and compliant DevSecOps pipeline (especially CD and CC toolchains) while keeping existent CI build processes for an application. By adding specific open-source tools and capabilities—like the generation of an SBOM and evidence locker—we are able to augment existent pipelines and secure the software supply chain, preventing and protecting against software supply chain risk.