Cyber risk is a major concern in today’s threat landscape, including attacks on the software supply chain. It is estimated that these attacks will impact 45% of organizations worldwide. These risks, known as supply chain risks, involve the inclusion of vulnerable code from open source or third parties.
In critical systems like IT infrastructure and financial services organizations, these attacks are even more damaging. There is often a conflict between the need for innovation and agility in banking solutions and the security, compliance, and regulatory requirements that CISOs (Chief Information Security Officers) and CROs (Chief Risk Officers) must ensure for their financial institutions.
IBM Cloud for Financial Services
IBM Cloud for Financial Services addresses this gap by providing security and compliance while supporting innovation. Its goal is to offer security and compliance solutions tailored for financial services companies, leveraging industry standards like NIST and the expertise of more than a hundred financial services clients in the Financial Services Cloud Council.
IBM Cloud for Financial Services enables clients to build secure and compliant hybrid cloud solutions, focusing on the entire software lifecycle (continuous integration, continuous delivery, continuous deployment, and continuous compliance) using IBM Cloud DevSecOps, also known as One Pipeline.
However, in cases where third-party code is involved and running a complete CI process is not possible, alternative approaches must be applied. This blog will describe these alternative approaches.
What is IBM Cloud DevSecOps and how can it ensure secure and compliant applications?
The DevSecOps pipelines, or One Pipeline, are used to deploy applications on IBM Cloud by checking for vulnerabilities and ensuring auditability.
The continuous integration (CI) pipeline is responsible for building the application, including best practices like unit testing, build, dynamic scans, evidence collection, artifact signing, and vulnerability checks.
The continuous delivery/deployment (CD) pipeline supports the continuous deployment of the application, including evidence collection, GitOps-based inventory flow, asset promotion between environments, change management, and compliance scans.
The continuous compliance (CC) pipeline periodically scans the deployed application for continuous compliance, repeating many of the scans from the CI pipeline to detect and flag new vulnerabilities.
For more information about the DevSecOps toolchains, please read our documentation.
The default approach for using IBM Cloud DevSecOps
In typical scenarios, applications are both built and deployed in IBM Cloud DevSecOps. The continuous integration toolchains build, test, and package the code and 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 that assert the completion of various required checks, such as unit tests, code scans, and pull request reviews.
These two repositories are created in the CI process and linked to the continuous deployment/delivery toolchain to complete deployment readiness checks. The inventory determines what should be deployed, and the evidence locker determines if the application is secure and robust enough for deployment.
Different build tools
However, it is not always possible or desirable to use IBM Cloud DevSecOps to build applications, especially when it involves third-party code. This can be due to various reasons, such as teams being more familiar with other build tools, the application not being suitable for the pipeline processes, or teams not having enough time for a complete transition to One Pipeline.
For IBM Cloud for Financial Services, we still want applications to go through a One Pipeline deployment to ensure security and required checks. To achieve this, we need to have the inventory and evidence pieces in place.
Fortunately, the One Pipeline CI and CD toolchains have their pipeline code logic mostly contained within the DevSecOps (or cocoa) CLI. The CLI includes all the necessary components to build the inventory and evidence lockers. In cases where the One Pipeline CI cannot be used, the DevSecOps CLI can be integrated into existing CI systems like Jenkins, Travis, or GitLab. The CLI is available from Artifactory as 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.
For the complete CLI command reference, please refer to our documentation.
Case study: Financial Transaction Manager (FTM)
Financial Transaction Manager (FTM) is an example where a full One Pipeline-based solution could not be adopted. FTM is an existing monolithic application built using Jenkins with a complex build structure. Dependencies, build orders, and long build times make it unsuitable for One Pipeline continuous integration.
However, we still wanted to be able to install FTM on IBM Cloud for Financial Services using One Pipeline. We worked with the FTM team to integrate the DevSecOps CLI into their existing Jenkins-based pipelines.
This ongoing process involves making the FTM Jenkins pipelines generate the required inventory and evidence items used in a One Pipeline deployment pipeline.
The FTM team approached the problem by creating utility classes in their Jenkins script libraries to simplify the interaction with cocoa. These utilities enable them to easily upload evidence or inventory items to a Git repo, including tool types, results, evidence types, etc. Here is an example of evidence collection:
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 needed and integrate it into any part of their Jenkins infrastructure. Here is an example of adding an inventory item:
In this exercise, we have shown how to create a secure and compliant DevSecOps pipeline, especially for CD and CC toolchains, while keeping existing CI build processes for an application. By incorporating specific open-source tools and capabilities like SBOM generation and evidence lockers, we can enhance existing pipelines and secure the software supply chain, preventing and protecting against software supply chain risks.
Learn more about IBM Cloud for Financial Services.
DevSecOps Architect, IBM Cloud for Financial Services
Distinguished Engineer, Financial Services Cloud