Creating an SBoM for Mix projects

Posted 2019-10-24 19:44:48.169213

Any non-trivial modern software project relies, directly or indirectly, on a large number of third party dependencies. Keeping track of updates, known vulnerabilities and license obligations can be a real challenge. Luckily there are tools that can help, both free and commercial.

In order to leverage such tools it is necessary to generate an inventory of the dependencies, including their versions and licenses, in a format the tools can understand. This is called a Software Bill-of-Materials, or SBoM, and an example of an SBoM format is CycloneDX. Tools exist for generating CycloneDX files for various ecosystems, and now there is one for Elixir too.

In this post I will show how to generate an SBoM for a Mix project, and how to use the output with OWASP Dependency-Track.


Let’s pick a real-life Phoenix project with some JS assets as an example and see how this might work in practice. For this post I’ve picked the application, the code for which is publicly available on GitHub.

First let’s install the tools we need to generate the BoM:

$ mix archive.install hex sbom
Are you sure you want to install "sbom-0.5.1.ez"? [Yn] Y
* creating ~/.mix/archives/sbom-0.5.1

$ npm install -g @cyclonedx/bom
/usr/local/bin/cyclonedx-bom -> /usr/local/lib/node_modules/@cyclonedx/bom/bin/cyclonedx-bom
+ @cyclonedx/bom@1.0.4
updated 3 packages in 4.636s

Now we clone the project and fetch the Elixir and NPM dependencies:

$ git clone
Cloning into ''...

$ cd

$ mix deps.get
* Getting scrivener_html (
* Getting ranch (Hex package)

$ cd assets && yarn && cd -
yarn install v1.19.1
✨  Done in 16.73s.

Next we generate the BoM for the Mix project:

$ mix sbom.cyclonedx -o elixir_bom.xml 
* creating elixir_bom.xml

And finally we generate the BoM for the NPM packages while importing the BoM we just generated, to produce a single BoM for the entire project:

$ cd assets
$ cyclonedx-bom -o ../bom.xml -a ../elixir_bom.xml
$ cd -

The output is a big XML file, which is not very exciting to look at. Let’s see what we can do with it.

Importing into OWASP Dependency-Track

OWASP Dependency-Track is a free “Software Supply Chain Component Analysis platform” that can ingest CycloneDX BoMs. You can quickly spin up an instance in a Docker container for testing using these instructions. When starting the server for the first time a lot of data is fetched from various sources and imported into the database: this may take a couple of minutes…

Once the server is running, look up an API key with “BOM_UPLOAD” permission by going to Administration -> Access Management -> Teams -> Automation -> API Keys. We’re going to need the API key in a minute.

Next, create a project:

Dependency-Track Create Project dialog

Now open the new project and copy the project UUID from the address bar (yes, I know, there should be a better way to do that). We can now call the API to upload the BoM we generated earlier:

$ curl -X "POST" "" \
       -H 'X-Api-Key: ymsPB5M8grpzWRVGEPeaLiCc5O+TlWFa' \
       -F "project=68e01035-84a7-4a55-9a8e-f9d815a79af0" \
       -F "bom=@bom.xml"

It may take a couple of seconds for the initial analysis to complete. Once that’s done you should see something like this:

Dependency-Track Project Overview

To have a closer look at the dependencies that were found, head over to the Dependencies tab:

Dependency-Track Project Dependencies

Let’s search for some Elixir packages:

Dependency-Track Project Dependencies filtered

At this time there is no reliable way to correlate vulnerabilities for Hex packages: the CVEs from the NVD do not contain sufficient information to identify the package, and services such as Sonatype OSS Index do not provide coverage for Hex at this time. But hopefully this will change, and in the meantime there are several things Dependency-Track can help with:

Dependency-Track Project Audit

Update 11/11/2019: version 0.6.0 of the SBoM package adds NVD CPE package identifiers to those Hex packages for which CPEs have been assigned. This allows Dependency-Track, and similar tools, to more reliably match packages to published CVEs. The first Elixir vulnerability has since been flagged on my Dependency-Track server.

What’s next?

Further tooling and integrations are needed before supply chain vulnerability management for Hex packages can match what’s available for other ecosystems. If you want to help, please reach out to me or to the EEF Security WG. Let’s push things forward together!