Accelerate cloud adoption by leveraging best practices for a DevSecOps pipeline

Financial services companies are required to meet specific regulatory requirements and standards when developing and deploying technology solutions. Cloud services support the rapid development of technology solutions; however, these companies must adhere to the same regulatory requirements throughout the adoption of cloud services.

Cloud services are ubiquitous and software updates have increased exponentially; financial services organizations must create a DevSecOps pattern to automate the build and deployment of software while integrating security at every phase of the lifecycle.

Model DevSecOps pipeline

One of the major pillars that is part of the complete solution within cloud adoption is that of DevSecOps. DevSecOps is shorthand for development, security, and operations. It is an approach to incorporating each of these activities into one unified delivery lifecycle, with a special focus on security. This post will focus on the components of a model pipeline. For DevSecOps automation to be successful, it takes team members of various roles working in conjunction with DevSecOps software components to reach the desired outcomes.

The model DevSecOps pipeline incorporates each discipline into the automation strategy, which improves cohesion and collaboration through well-defined responsibilities and actions. 

Roles in the DevSecOps pipeline

There are several roles involved in the implementation and operation of DevSecOps pipelines. These roles are not new and are already at the heart of delivery of software solutions within each organization. Here are the typical responsibilities associated with each of these roles within the context of DevSecOps:

• Engineers: design and implementation of code-based solutions (infrastructure, pipelines, and software).
• Dev/DevOps Leads: review and approve code solutions, mentor team on operations, and support DevSecOps procedures.
• QA Engineers: ensure the quality standard of the software implemented has been met.
• InfoSec Engineers: define policies and enforce security practices in the infrastructure, pipelines, and software.
• Change Manager: review and process requests for changes in the environments.
• Testing Manager: define patterns, enforce strategies for software quality, and approve of software deployments based on testing in environments.
• Application Manager / Owner: approve the deployment and operationalization of software.

Most organizations will have most if not all of these roles already in place working within the silos of their skillset. DevSecOps promotes the destruction of silos and cooperation and collaboration using cross-functional teams. Furthermore, it incorporates security into each of these roles’ responsibility, decreasing risk and increasing the probability of success.

What are the components of a DevSecOps pipeline? 

There are several major components of a wholistic DevSecOps pipeline. Some of these components are part of the pipeline for automation and other components are required for a complete delivery profile.

• Backlog: the inventory of work managed by the software development lifecycle.
• Source control: the location whereby revisions of the code, which can be built into a versioned artifact, are stored.
• Build: the process by which a versioned artifact is generated, which reflects the pipeline as code, software, and infrastructure as code.
• Security tools: SCA, SAST, DAST, or other security scanning to ensure the appropriate controls have been incorporated.
• Environments: the collection of software and infrastructure that make up a system by which users may interact with the solutions.
• Deployment: a combination of environments and a successful release of a built, versioned artifact.
• Automated testing: the test fixtures which provide quality assurance.

Most organizations will already have many of these components in place. In the next section, we will cover how the roles and components operate together efficiently for the greatest possible success at the lowest possible risk. 

How do these roles and components work together? 

This model pipeline should be viewed as one cohesive unit. This perspective is important to ensure that each component of the solution works wholistically together. While there are several roles and different approaches to engaging with these operations, when viewed as a single operation, each component will complete smoothly.

First, the Engineers will implement the code for the software, infrastructure, and pipelines. Once that has been completed through pull request review by the Dev Leads, then the build pipeline will automatically execute.

The build pipeline will execute the compilation for the software and infrastructure. One objective of the DevSecOps pipeline is to shift-left security. As such, it will run security scanning procedures, such as SCA and SAST. Once security scanning has completed, if there are any vulnerabilities or issues detected, these will be automatically provisioned within the backlog tool for review by the InfoSec Engineers. In addition, automated unit tests are executed, and results are published for review by the QA Engineers. Depending on the results, a versioned artifact is generated for use in deployment to environments. If applicable, container scanning is completed and uploaded to the registry.

Once the build artifact is available, the next stages in the pipeline will automatically deploy this version to the DEV environment. Each environment will subsequently provision the infrastructure required for the solution, then deploy the software. For each of these environments, approval from the Dev/DevOps Managers, Test Managers, and/or Application Managers may be required. Once the software is deployed, various test fixtures can be executed and reporting on the results posted.

Production deployment is unique in that the ITSM tool may be used to ensure additional checks that have been defined by the organization. Once the staging environment has completed deployment, the change manager will review the status of ticket(s) opened in the ITSM tool. The successful completion of the prior stage is used to create ticket(s), and the successful deployment to production will update the ticket(s) with resolution(s). 

What kinds of challenges might a person run into in practice?

Because DevSecOps is typically a complete shift from decentralized teams working in silos to cohesive teams working collaboratively, the most common challenge is related to personnel and breaking the existing processes by adopting the wholistic DevSecOps solutions. Once these best practices are operationalized with the teams, operational successes can be realized.

What aspects of the model pipeline are critical for financial services? 

The model pipeline defined here provides several governance benefits which apply to financial services regulatory compliance.

First and foremost, the compliance requirement benefits that are realized by adopting a “shift left” approach to security scanning are critical. Enabling the detection of security vulnerabilities and license compliance issues before the software makes it to any environment allows a straightforward path to remediation. Since these issues are automatically created within the backlog, they can be resolved within the DevSecOps lifecycle.

Additionally, the build process incorporates infrastructure policy scanning tools to ensure compliance with critical cards and payment standards, such as PCI DSS. The logs and traceability that a complete, end-to-end pipeline provides are a valuable audit trail available for assessments to meet compliance requirements. Incorporating the ITSM as a required step prior to production deployment ensures that change management policies are addressed automatically by the pipeline.

Finally, simply adopting a standard for DevSecOps results in a uniform implementation meeting the required policies defined by the enterprise. These standards may include:

• Secure coding standards
• Peer code review standards
• Access control standards
• Application security scanning standards
• Logging standards
• Business continuity policies
• Vulnerability management standards
• Patch management standards

What tools are available from Microsoft to support DevSecOps?

There are numerous tools that can be used to support DevSecOps. First and foremost is Azure DevOps, which provides the software development and management lifecycle. Boards are used for backlog and work documentation. The development lifecycle is managed through Repos providing Git tools for software revisions. Automated provisioning of infrastructure and installation of applications is possible through Pipelines. Monitoring and observability are enabled by cloud-native tools such as Azure Monitor. 

So what? 

As development cycles are getting shorter and urgency has increased to deliver on expedited timelines, financial services companies are faced with new challenges balancing this software lifecycle and meeting regulatory requirements. Adoption of this blueprint model pipeline alongside support for the teams implementing these principles will result in smooth execution, reduced risk, and increasing reliability of software installation. It takes the support of traditional roles implementing the component automation for the system to operate efficiently. Incorporating security into each phase of the pipeline and promoting the practice with the roles engaged in the delivery of software will reduce risk and improve identification of vulnerabilities earlier in the process.