Almost all large and medium organizations have implemented CI/CD processes to attain speed and scale in their software delivery process. And gradually, security is getting integrated into the CI/CD pipeline to release software to the market safely and without any vulnerabilities. The responsibility of integrating security is given to architects and the DevSecOps team. And one of the critical facets of security integrations remains DBOM reports.
Delivery Bill of Material or DBOM is a consolidated report about software supply chain and security management in the software delivery process. 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.
Why is DBOM necessary for CI/CD?
The primary reason for DBOM in the CI/CD is to increase the transparency of the risk of an application to all the stakeholders at each delivery stage. The stakeholders include DevOps, Security or GRC team or compliance managers, Application engineers, delivery team, or the operation team. A DBOM provides a systemic sharing of risk analysis by tracking the metadata, such as software components, and tying it to other information while taking an application to production.
A DBOM report helps organizations to effectively and efficiently consume the application status report in the software supply chain.
Difference between DBOM and SBOM
Delivery software bill of materials (DBOM) is an extended version of software bill of materials (SBOM) which is gaining prominence in the world of CI/CD. As per National Telecommunications and Information Administration (NTIA) report, an SBOM is a formal record containing the details and supply chain relationships of various components used in building software. An SBOM provides those who produce, purchase, and operate software along with other license information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks.
On the other hand, DBOM provides more granular information about the software components, such as who used which software, the risk of each element, and the applications at each stage of the delivery process. While SBOM is created solely for record keeping of components used for developing an application, DBOM is created to enhance the decision-making process and alert stakeholders about any unexpected or hidden vulnerabilities due to which software must not be released to production. In a nutshell, SBOM will be a part of DBOM.
What does DBOM contain?
Delivery Bill of Materials (DBOM) contains the foundational code component on which an application is built and its risk status. A DBOM report provides holistic information about an application component and its potential risks at various stages of software delivery- code, build, test, deploy, and production. Although the level of information wrt DBOM can vary from organization based on their requirements, below is a fair estimation of what a DBOM report should contain. ( Also note that SBOM would be a part of DBOM; hence there will be all the elements of SBOM).
How OpsMx SSD generates the DBOM report in CI/CD
In software development organizations where the scale delivery and size of applications are high, DevSecOps must fetch the DBOM at a centralized location. DBOM at a central location dashboard to track DBOM. OpsMx SSD integrates with various DevOps tools in the ecosystem and provides key information (refer to Fig A, B, C, and D) for each phase of the delivery process- Source, Build, Artifact, and Deploy. OpsMx Secure Software Delivery (SSD) extends the capabilities of your current CI/CD tools with application security orchestration, correlation, and posture management.
In the Source phase, SSD would connect with the code quality assessment tool, such as SonaqQube, and fetch all the information, such as 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 B), 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 security scanner tools such as AquaSec to get information about supply chain security, malware protection, cloud security, etc, and populate them in a single dashboard.
Similarly, in the Deploy phase, the DevSecOps team must get information about security benchmarking, such as Center for Internet Security (CIS) benchmarking. OpsMx SSD provides an automated deployment verification module to perform metrics and logs analysis of a new application and its dependencies to provide deployment risk, performance, quality, reliability, and business impact scores. DevSecOps might have a few questions before deciding to roll out software to an environment such as:
Was the right image used in the deployment?
What is the 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 which can be quickly resolved.
Next Step
If you want to learn more about DBOM, watch the Beyond SBOM webinar. You can also learn more about the generation of DBOM using OpsMx SSD to improve your security posture in your software delivery process.
0 Comments