Dependency Tracking using CycloneDX & OWASP's Dependency Track. Learn more about the benefits that this platform can offer to your projects quality, security, maintainability, and license manageability.
Dependency Track
Third-Party and open source components, which language or framework doesn't rely on them? Whether it's using NPM, Nuget, Maven, Python, Hex, or any other package managers, their strength lies in not having to re-invent the wheel. Simply install or import the package of your choosing, and you're set!...right?
Over the years, we've put a lot of faith in third party modules or packages, so much that almost all projects are depended on them. We not only trust that their functionality keeps up over the years, but also that their security in our projects stays up-to-date. But what happens when we have not one, but ten, or maybe a hundred projects? Each with their own list of dependencies. We lose track of them.
🔥 That's where Dependency Track comes in! 🔥
Dependency Track helps you keep track of all your software components, licenses, and their respective versions, and analyses said components for vulnerabilities against databases like the Sonatype OSS Index, and NPM Audit. Dependency Track continuously analyses each project and it's corresponding Software Bill of Materials for changes and vulnerabilities, and displays them in both an overview by ways of graphs, and detailed tables. Let's start by giving you a brief overview of the different views Dependency Track offers to their end users!
The Dashboard view will display the amount of projects at risk, the number of vulnerabilities, an inherited risk score, policy violations and more! This all neatly wrapped in graphs displaying the changes over time!
Attachment 1. Preview of the Dependency Track Dashboard view
To view the specific details of a projects components, we head over the Projects view. This will show a detailed version of the information displayed on the Dashboard, in chart form. Important note that this is the primary location to see when the Last BOM Import has taken place (We'll get to that later!), and the total amount of vulnerabilities on each specific project.
To view the details of a specific project, we head over the projects detail view, where we find the overview of all it's Components, and the Audit Vulnerabilities. Now it gets interesting! By heading over to the Components we can find all the components for this specific project, their corresponding package/component version, their license, their risk score, and their amount of vulnerabilities! Here we can, if we wish to do so, manually add and remove components. But we're talking DevOps here, so we'll get to automating this!
Attachment 2. Preview of a project's Component detail view.
By heading over to the Audit Vulnerabilities tab, we find the specific components that have known Vulnerabilities on their specific version, the severity of the vulnerability, and the details on what the vulnerability entails. Of course, we might want to know more! Since when have been at risk? What versions of this component have this same issue? Maybe I don't agree with the analysis, can I do something about that? The answers are, Dependency Track has you covered!
You will be able to see when the vulnerability was first reported in the same Audit Vulnerabilities view, you'll be able to see which version the package has these issues in it's audit description, and you can Suppress the analysis if you wish to do so (And even specify your reason for it!)
Attachment 3. Preview of a projects Audit Vulnerabilties View
Alright, so we've mentioned how we can get more insights in our projects, and how it automatically analyses their components for vulnerabilities while neatly displaying them for us. How do we tell Dependency Track which components we actually have? That's where CycloneDX comes in!
CycloneDX
Because of Dependency Track's versatility, it does not automatically integrate into your project's DevOps Pipeline to analyses which components your projects have. That's where we use CycloneDX! CycloneDX is a lightweight software bill of materials (BOM) standard designed for use in application security contexts and supply chain component analysis. On the CycloneDX website you can find a wide range of tools to audit any sort of application, whether it's a NodeJs, .NET, Python, PHP, Gradle, Maven or Ruby application, you name it! Not only can you find tools to generate said BOM by hand, it also offers variety of DevOps integrations, for example GitHub Actions!
The result of all of these tools will be an BOM file (JSON/XML), that contains a detailed list of all the components your project contains, with their respective meta-data that a tool such as Dependency Track uses to index, find and match said package to any package store of your choosing (All configurable!). See the following XML snippet for an example on how to structure an BOM XML file.
For more information on CycloneDX, check out https://cyclonedx.org/
Now that we've got our Bill of Materials, we can either upload them by hand in the Dependency Track Dashboard, or we can use it's extensive API to upload the BOM right from our DevOps pipeline! If you have some troubling uploading the BOM right from your pipelines to Dependency Track, here's a useful code snippet I found by Jasper Gilhuis, that makes uploading your BOM using a Powershell script a breeze!
Getting Started
Dependency Track can run both standalone, and in a Docker environment! Simply add the Docker container to your Swarm, or launch it using Docker Compose, and you're good to go, as easy as that!
After that, head over to (the default address being) localhost:8081, login using username & password 'admin', and you're ready to explore Dependency Track!
For now, I'll leave you to experiment with both the Dependency Track platform & CycloneDX on your own. For more details, visit https://dependencytrack.org/ to learn more about the platform and it's features!
Â
*Additional Information: This article is written based entirely on my own personal experiences. I am in no way associated with either CycloneDX or the OWASP Foundation. For this article, version v4.0.0 of the Dependency Track Platform was used.
