Why security is important in the CI/CD process
Almost all of the best practices for DevSecOps teams revolve around improving their security posture. That is because every organization that has implemented CI/CD, has done it with the intention of attaining speed and scale in their software delivery process. Although the time to market has increased exponentially with CI/CD processes, a new challenge has emerged wrt security. Deployment speed is one thing, but without proper software checks, developers may introduce security vulnerabilities inadvertently, leading to grave risks to business operations. Organizations are either making DevOps responsible for ensuring the security of their delivery process or creating a dedicated DevSecOps team for the same goal.
In this article, we will discuss the top 7 best practices that the DevSecOps team implements in CI/CD process to make their software delivery process more secure.
Challenges faced by DevSecOps to ensure security
Here are a few reasons why ensuring security in CI/CD process has become a challenge for the DevSecOps team:
- Diverse DevOps toolchains in CI/CD processes lead to fragmented security-related data.
- Evaluation of software risks involves processing a lot of data at various stages- build, test, and deploy.
- Manual checks to ensure SDLC compliance with numerous incremental software changes every week are overwhelming for the DevSecOps team.
- Vulnerability management is an issue. There is no proper mechanism to allow specific low-critical vulnerabilities to production and keep track of them.
- Auditing an application at regular intervals is time-consuming, with the DevSecOps team trying to review system logs manually.
DevSecOps team needs to re-think their strategies and implement new tools and best practices to ensure security in the software delivery process.
Step-1: Integrate security testing into CI/CD pipeline
With the rise of open-source tools and libraries, applications can be vulnerable. Hence security testing to analyze source code and find security vulnerabilities should be automated. Without proper checks, vulnerabilities can go into production, and applications will be susceptible to attack. Famous security testing is Static/Dynamic Application Security Testing (SAST/DAST) to find source code and binary vulnerabilities.
DevSecOps must attempt to automate the security scanning completely by integrating with CI/CD pipelines. Refer to Fig A, where the static analysis in SonarQube is made a part of the CI/CD pipeline. The stage is automatically executed after the build process is completed in Jenkins. And based on the software quality and vulnerability, the pipeline would proceed to the next step or fail.
OpsMx ISD for Spinnaker provides a CI/CD pipeline that can integrate with most of the security scanners in the market, such as:
- Sonarqube
- Prisma Cloud
- HCL AppScan
- Jfrog Xray Scanning
- Aquawave
Step-2: Understand the risk of applications and dependent services
DevSecOps must empower application owners to understand the security risks of an application and all of its services. Holistic information about security vulnerabilities wrt each service, deployment date, and developers will help owners make decisions faster regarding deployments and delivery.
OpsMx SSD is the first platform to introduce the DevSecOps control plane (refer to Fig B), where all the information related to application supply chain security will be outlined for faster decision-making.
Step-3: Track the Delivery Bill of Materials (DBOM) for each software in CI/CD
The Delivery Bill of Materials (DBOM) is a software supply chain and security management building block. DBOM includes the data such as security risk reports, quality and performance reports, testing reports, and development & deployment history of the application, tools used to deliver the application, etc. DevSecOps must attempt to fetch the DBOM at a centralized location to expedite the decision-making and delivery process.
In software development organizations where the scale delivery and size of applications are high, it might be cumbersome for DevSecOps to fetch the DBOM at a centralized location. To help the DevSecOps team, OpsMx SSD offers a dashboard to track DBOM. SSD integrates with various DevOps tools in the ecosystem and provides key information (refer to Fig C, D, E, and F) for each phase of the delivery process- Source, Build, Artifact, and Deploy.
In the Source phase, SSD would connect with the SonaqQube and bring all the information, wrt vulnerability test reports or source code analysis, in a consolidated view for the application owner. They can now take a look and formulate faster decisions. With SSD, DevSecOps can make all the stakeholders aware of the software delivery. This will ensure there are no exceptions and no bugs which are introduced without the notice of managers in a team.
In the Build phase, SSD can connect with build or CI tools such as Jenkins or Travis CI to aggregate the data (Fig D), which DevSecOps can get at the fingertips. If there is a policy violation, they can quickly hinder the progress of a pipeline or inform the individual team to stall the release process. E.g., an application can refrain from deployment if it has not passed enough test cases or test scenarios in the build phase.
In the Artifact phase, DevSecOps should be empowered to get information about vulnerabilities wrt to its dependencies. SSD integrates with tools such as AquaSec to get information about supply chain security, malware protection, cloud security, etc, and populate them in the DevSecOps control plane.
Similarly, in the Deploy phase, the DevSecOps team must get information about security benchmarking, such as Center for Internet Security (CIS) benchmarking. OpsMx SSD fetches the data from other tools. OpsMx ISD Delivery intelligence provides deployment verification and logs analysis scores, metrics analysis scores, quality scores, reliability scores, and business impact scores. DevSecOps might have a few questions before deciding to roll out software to an environment such as:
- Did the right image used in the deployment
- Risk of the new application wrt various dimensions
- Who approved the deployment
All this verification information from various tools will be adequate to help progress a release.
A consolidated dashboard to track the Delivery BOM (DBOM) has several benefits.
- DevSecOps don’t have to run around to fetch information from sources such as source code systems, CI systems, scanners, etc.
- They independently monitor the software delivery and control it from a security perspective.
- DevSecOps team can see various security patterns from an organizational perspective (something that can be significantly different from developers working in silos) and can implement policies to improve security posture.
- If required, various teams and stakeholders can be brought under the same umbrella using the DBOM dashboard to discuss further an issue or doubt wrt supply chain security, and can be quickly resolved.
Step-4: Make SBOM a part of your DBOM for dynamic deployments
One of the core responsibilities of the DevSecOps team is maintaining a software bill of materials (SBOM)- a list of all the open-source and third-party components in a codebase. SBOM also involves:
- A list and name of the license application components.
- The versions of the ingredients used in the codebase.
- Their patch status.
SBOM is always handy for security teams to track associated security or license risks.
Today’s deployments are dynamic, with changing infrastructure and dependencies (all the time). DevSecOps team must automate the tracking and maintenance of SBOM in a single place. When the delivery is faster, the question remains how to take more immediate actions regarding each deployment and their respective vulnerabilities. By making SBOM part of delivery BOM (DBOM), supply chain and security-related information can be understood in one place, and policies can be formulated and implemented quickly.
Refer to the below image, where information such as service, package name, package URL, publisher, License, status, and vulnerabilities are stored in a system as a part of SBOM. Based on this information, many rules and policies can be created, such as preventing deployment if the critical vulnerabilities are more than ten or License is not from MIT and Apache, etc.
Step-5: Create policies and take automated actions in CI/CD
Once all the information is in place, the DevSecOps team should be able to create policies and implement them. E.g., policies to prevent a deployment based on a threshold of particular metrics such as code vulnerabilities or security scores. An automated mechanism to create new rules and enforce them in the delivery pipeline should be implemented to attain a risk-free software delivery process.
DevSecOps can use OpsMx SSD on top of their CD tools to create policies and implement their automated pipelines. By default, SSD supports the integration of security policies to CD tools like Spinnaker, Argo, and Jenkins.
Step-6: Central Exception Management for Distributed Teams
There can be instances when the scanner and risk-assessment tool can provide high risks to specific dependencies or libraries, which may not be harmful as the way the environment is set up. DevSecOps should be able to handle such exceptions without any hiccups, like bringing the delivery process to a halt.
There should be a mechanism to understand a situation where open-source libraries may not be exploitable as per the setup and allow developers to proceed with the deployment activities.
For e.g., Developers deploying applications with open-source libraries in a sandbox environment or a Dev instance to test their ideas may introduce vulnerable open-source libraries. But if the environment is in a VPC behind a firewall, then the DevSecOps team may consider allowing those exceptions for a specific time period. And management of these exceptions from a central repository is critical.
OpsMx SSD offers an exception management system to document the software delivery exceptions with information about who and when an exception was created and for what purpose. This will help an organization track all the exceptions for all the teams in a central location.
Step-7: Audit and Attestation
DevSecOps conducts an auditing exercise to ensure their applications adhere to SDLC standards and regulations. Instead of manually fetching the information from 10 disparate systems, they should automate software auditing in their ecosystem.
OpsMx SSD offers Audit and Attestation dashboard to get all the audit reports for a chosen period highlighting who, what, and when pipeline execution and policy violations. OpsMx SSD allows internal or external auditors to list, search, and filter on deployment, environment, and event data collected from workflow tasks or pipeline activities and deployments in a single pane.
The image below represents the SLSA L3 attestation report, proving the application and software delivery process is following all the organization standards.
Conclusion
DevSecOps is a new concept with new responsibilities of enforcing security into CI/CD processes. Leading American organizations prioritize security and look at their DevSecOps team to lead the transformation. Due to the speed and scale of the CI/CD process, the DevSecOps team might find themselves in fire-fighting mode- ensuring security with manual checks of each release process. The manual approach at each application level can be overwhelming and risk missing out on certain security checks from an organizational perspective. DevSecOps team needs to understand the best practices and adopt new tools and technologies to avoid burnout from manual activities. In order to avoid burnout from manual activities it is essential to adopt new tools and technologies, and also understand the best practices DevSecOps teams must implement.
OpsMx helps large organizations such as Apple, Google, Salesforce, and Cisco to implement CI/CD processes and secure their software delivery process. We offer Secured Software Delivery (SSD) for enterprises to prevent potential security issues, discover and resolve vulnerabilities in their environment, and demonstrate secure software delivery and deployment.
0 Comments