Cyber risk is a top concern in today’s threat landscape, including IBM, with software supply chain attacks on the rise. It’s estimated that these attacks could impact up to 45% of organizations globally. These are often termed as supply chain risks and involve vulnerabilities in code, which can originate from open-source or third-party sources.
These attacks are particularly worrisome in critical systems, including IT infrastructure and financial services organizations. Financial markets face a unique challenge where the demand for innovation and agility in banking solutions conflicts with the need for security, compliance, and regulatory adherence that Chief Information Security Officers (CISOs) and Chief Risk Officers (CROs) must ensure for their financial institutions.
IBM Cloud for Financial Services stands out in bridging this gap, enabling clients to balance innovation with the assurance of security and compliance. Its primary aim is to deliver security and compliance solutions tailored to the needs of financial services companies. This is achieved by adhering to industry standards such as NIST and drawing upon the collective expertise of over a hundred financial services clients who are part of the Financial Services Cloud Council.
IBM Cloud for Financial Services empowers clients to establish secure and compliant hybrid cloud solutions with a specific focus on the entire software development lifecycle, encompassing continuous integration (CI), continuous delivery, continuous deployment, and continuous compliance. These objectives are realized through the application of IBM Cloud DevSecOps, also known as One Pipeline.
In certain situations where third-party code acquisition doesn’t permit the execution of a comprehensive Continuous Integration (CI) process within their build, alternative approaches become necessary. These alternative strategies will be detailed in this blog.
The DevSecOps pipelines, often referred to as One Pipeline, serve as the means to deploy applications on IBM Cloud while simultaneously inspecting for vulnerabilities and maintaining auditability.
The continuous integration (CI) pipeline is responsible for constructing the application. This process incorporates DevSecOps best practices, including unit testing, building, dynamic scanning, evidence gathering, artifact signing, and vulnerability assessments.
The continuous delivery/deployment (CD) pipeline facilitates the ongoing deployment of the application. This involves processes like evidence collection, a GitOps-based inventory flow, asset promotion across different environments, change management, and compliance scans.
The continuous compliance (CC) pipeline performs regular scans on the deployed application to ensure continuous compliance. This pipeline replicates many of the scans conducted in the CI pipeline, ensuring that any new vulnerabilities are promptly identified and reported.
Want to know more about IBM? Visit our course now.
In IBM Cloud DevSecOps, applications typically undergo both construction and deployment. The continuous integration toolchains are responsible for building, testing, and packaging the code. Subsequently, they update two vital repositories: The Inventory and The Evidence Locker.
These two repositories are established during the continuous integration phase and are connected to the continuous deployment/delivery toolchain. This linkage enables the completion of readiness checks for deployment. The inventory defines what needs to be deployed, while the evidence locker assesses whether the application is sufficiently secure and reliable for deployment.
In certain cases, it may not be feasible to have IBM Cloud DevSecOps construct applications, especially when dealing with third-party software. This can occur for various reasons, such as teams being more accustomed to alternative build tools, the application not aligning with pipeline processes, or teams preferring not to allocate time for a complete transition to One Pipeline.
However, in the context of IBM Cloud for Financial Services, we still aim to subject applications to One Pipeline deployment to ensure that the application or component undergoes the necessary security checks. To accomplish this, it is essential to have the inventory and evidence components in place.
Thankfully, the CI and CD toolchains of One Pipeline have the majority of their pipeline code logic encapsulated within the DevSecOps (or cocoa) CLI. This includes all the components necessary for creating the inventory and evidence lockers. Therefore, in cases where the One Pipeline CI cannot be employed, the DevSecOps CLI can be seamlessly integrated into existing CI systems like Jenkins, Travis, or Gitlab. The CLI can be obtained from Artifactory in two forms: as an npm module or as a standalone binary file.
Below are some example commands used with 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.cocoa locker evidence summary: Returns evidence summary for a given asset.In the case of Financial Transaction Manager (FTM), we faced limitations in adopting a complete One-Pipeline-based solution. FTM is an established monolithic application that was originally built using Jenkins and has a complex build structure. With dependencies in the pipeline, specific build orders, and extended build times, it wasn’t an ideal fit for One Pipeline’s continuous integration approach.
Nevertheless, we aimed to ensure that FTM could still be deployed on IBM Cloud for Financial Services using One Pipeline. To achieve this, we collaborated with the FTM team to incorporate the DevSecOps CLI into their existing Jenkins-based pipelines.
The FTM team has been steadily working on adapting the Jenkins pipelines to produce the necessary inventory and evidence items for use in a One Pipeline deployment. Their approach to this challenge involves a gradual process of integration.
As an illustration of their approach, the FTM team began by developing utility classes in their Jenkins script libraries. These utilities are designed to simplify the interaction with cocoa (the DevSecOps CLI), making it straightforward to upload various pieces of evidence or inventory items to a Git repository. These uploads can include information about tool types, results, evidence types, and more. Here is an example of evidence collection:
cocoaUtils.collectEvidence( imageName, "icr-va", "success", "com.ibm.cloud.image_vulnerability_scan", "artifact", "app-image")
The approach adopted by the FTM team enables them to incorporate evidence wherever it is considered necessary, making it highly adaptable across their Jenkins infrastructure. Here is an example of adding an inventory item:
cocoaUtils.addInventory( imageName )
In this exercise, we demonstrated how to create a secure and compliant DevSecOps pipeline, particularly for CD and CC toolchains, while retaining existing CI build processes for an application. By incorporating specific open-source tools and capabilities, such as generating a Software Bill of Materials (SBOM) and an evidence locker, we can enhance existing pipelines and ensure the security of the software supply chain. This helps prevent and protect against software supply chain risks.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com