Day by day, we see new vulnerabilities popping up, and we need to remediate the risk faster. Let’s take an example of the log4j vulnerability, which impacted almost all big MNCs. A lot of components were affected because of it. It’s becoming common to see new vulnerabilities. Identifying the impact across all the applications is not straightforward, and mitigating the issues becomes harder.
What if we could find these issues and address them before pushing a new release? Can we manage to track vulnerabilities within the dependencies of our application? Yes, we can automate the above steps using a tool like Dependency-Track, which is an open source intelligent component analysis platform. It would reduce risk & vulnerabilities in the supply chain by utilizing Software Bill-of-Materials (SBOM).
Another critical aspect for an organization is maintaining compliance, various software security policies, and auditing. Dependency-Track can help us set up policies and retain the best practices.
Dependency-Track is a tool by the OWASP foundation which helps you visualize and track software components and libraries. It helps you get a list of all the libraries which you use currently and manage reported findings. It is an open source component analysis platform that allows organizations to identify and reduce risk in software supply chains. It does this by leveraging SBOM.
An SBOM is effectively a nested inventory, a list of ingredients that make up software components. Software transparency is often achieved through the publishing of SBOM. There are multiple SBOM standards, including CycloneDX, SPDX, and SWID, each having their own strengths and use-cases they were designed to solve.
CycloneDX is the preferred standard for application security requirements. Evaluating SBOM standards to determine which are applicable to an organization’s requirements should be part of an overall Cyber Supply Chain Risk Management (C-SCRM) strategy.
Most software today is developed using a mix of third-party and open source components. With so many components used along with the native code, it becomes critical to analyze all such components for risks and vulnerabilities. That’s where component analysis tools like Dependency-Track come in. It allows teams to identify and reduce risk quickly. Let’s take a quick look at what benefits does Dependency-Track brings to the table:
Dependency-Track isn’t the only component analysis tool available out there. Based on your stack, you could choose one of the below-listed tools that fit your requirement.
Different software ecosystems have different terminologies to represent software components. This makes it difficult to represent the list of these components outside of these ecosystems.
The Package URL specification addresses these concerns and provides a uniform way to represent these components.
pkg:email@example.com?arch=i386&distro=jessie\ pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c\ pkg:firstname.lastname@example.org?platform=java\ pkg:email@example.com?packaging=sources\ pkg:firstname.lastname@example.org\ pkg:nuget/EnterpriseLibrary.Common@6.0.1304\ pkg:email@example.com\ pkg:firstname.lastname@example.org?arch=i386&distro=fedora-25
Package URL is important to track software components and is supported by CycloneDX.
Dependency-Track consumes CycloneDX BOMs. The process of generation of BOMs can be automated in the build pipeline using tools provided by CycloneDX (check out the tool center).
In CI/CD, Dependency-Track Jenkins Plugin is the recommended method for publishing CycloneDX BOMs to Dependency-Track in Jenkins Environment. In GitHub workflow environments Dependency-Track GitHub Action is recommended.
If you have a different environment, you can still automate the publish part using curl (or similar); read more about it in the CI/CD document.
The generated BOM file can be manually fed into Dependency-Track using user interface/REST API – being API-first design, Dependency-Track facilitates easy integration with other systems.
Let’s understand the use case using a hands-on example.
Now, run the below commands in the terminal.
$ curl -LO https://dependencytrack.org/docker-compose.yml $ docker-compose up -d
Terminal output example:
[+] Running 3/3 ⠿ Network dependency-track-demo_default Created 0.0s ⠿ Container dependency-track-demo-dtrack-apiserver-1 Started 0.4s ⠿ Container dependency-track-demo-dtrack-frontend-1 Started 0.8s
You will be able to access the dashboard at
localhost:8080 and credentials by default are admin:admin.
A project is a high-level categorization and collection of components (dependencies once added) along with sub-projects. A project could represent a software application, an environment, a medical or IoT device, or an automobile. Vulnerabilities from dependent components and sub-projects are reported up to the project level.
Now, create a project under Project > Create Project and give it a name of your choice and select classifier of project as Application.
Organisations can create policies and measure policy violations across the portfolio, and against individual projects and components.
Create a Security Violation policy under Policy Management > Create Policy. Give it any name and set its violation state to warn and add two conditions
Note: Policy conditions can specify the severity of vulnerabilities. A vulnerability affecting a component can result in a policy violation if the policy condition matches the severity of the vulnerability. Read more about Policy Compliance.
For this hands-on exercise, we will use minikube source code to generate SBOM.
Clone the minikube repository on your local system and run the below command to install cyclonedx-gomod library.
$ go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
Note: There are multiple libraries present supporting different languages and platforms, you can check this out in CycloneDx Tool Center.
Within the root directory of the minikube repository run below command to generate BOM.
cyclonedx-gomod mod -licenses -type application -output bom.xml
It will generate a bom.xml file within the root directory as specified in command itself. Terminal output example:
9:49AM WRN no licenses detected email@example.com 9:49AM WRN no licenses detected firstname.lastname@example.org 9:49AM WRN no licenses detected email@example.com 9:49AM WRN no licenses detected firstname.lastname@example.org 9:49AM WRN no licenses detected email@example.com 9:49AM WRN no licenses detected firstname.lastname@example.org
Note: The library gives a warning if license information is missing for any dependency.
There are multiple ways in which you can configure how to publish your BOM to the Dependency-Track server. Let’s understand two methods.
Note: Best practice is to include generation & publishing in the CI pipeline. There are plugins available to achieve this.
Once the BOM is generated you need to login to Dependency-Track UI and navigate to Project > Components > Upload BOM, select the BOM file you want to upload.
If you have API Key, or you don’t have UI access, you can do it via Rest API. This gives flexibility to integrate API methods in CI pipeline for ingestion of BOM.
The following small guide will give you an idea of how to generate an API Key.
You can find the Project UUID by navigating to Projects and then clicking on your project name. This will open up the project dashboard. Click on view details link present under the project name, which will display the details of the project in a dialog box. The value in the last field named Object Identifier is the Project UUID.
$ curl --location --request POST 'http://localhost:8081/api/v1/bom' \ --header 'X-Api-Key: API_KEY_HERE' \ --form 'project="PROJECT_UUID_HERE"' \ --form 'bom=@"BOM_FILE_LOCATION"'
Read more on CI/CD integration.
Once you upload the BOM wait for some time for Dependency-Track to analyse the file. After some time the dashboard will get populated and we can analyse this data.
The components tab will let you dig through all the components used in your project. This can be useful in understanding which dependencies the project uses. This can be used to find risky software components which you might not be aware that you are using.
You can also look out for a Dependency graph tab which helps you to figure out which dependencies are related to which component.
The other feature which is useful is the Audit vulnerability tab. Here you will find all the software components which have a known vulnerability. Using this you can start remediating these risks.
One of the interesting features is Policy compliance, if you remember we created a policy named P-1 which is showing where the violation is happening as per our defined rule.
Dependency-Track also includes a robust and configurable notification framework. It is capable of alerting users or systems of the presence of newly discovered vulnerabilities, previously known vulnerable components that are added to projects, as well as providing notifications on various system and error conditions.
As these vulnerabilities are found in your dependency, you can choose to notify in the supported notification framework by Dependency-Track.
As new vulnerabilities come into the picture, so does the need to remediate the risk faster. Organizations are turning to simplified risk management solutions, and tools like Dependency-Track can help us in risk analysis. In this blog post, we learned about possibilities & ease in the overall process of supply chain risk management and alternative solutions based on requirements. How supply chain risk management is helping organizations in delivering secure & reliable solutions.
This blog post is co-written by Sudhanshu Prajapati and ex-Infranaut Frederick (Freddy) Fernando. If you have any questions to boom with, feel free to reach out to either Sudhanshu or Freddy. We would be happy to help!
Looking for help with cloud native security consulting & implementation? do check out our capabilities how we’re helping startups & enterprises as an cloud native security services provider.