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.

Example

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 changelog.com 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 https://github.com/thechangelog/changelog.com
Cloning into 'changelog.com'...
[...]

$ cd changelog.com

$ mix deps.get
* Getting scrivener_html (https://github.com/jerodsanto/scrivener_html.git)
[...]
* 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:

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" "https://dtrack.example.net/api/v1/bom" \
       -H 'X-Api-Key: ymsPB5M8grpzWRVGEPeaLiCc5O+TlWFa' \
       -F "project=68e01035-84a7-4a55-9a8e-f9d815a79af0" \
       -F "bom=@bom.xml"
{"token":"4826257e-bba2-f2c6-60dc-a92c35e2a79a"}

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

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

Let’s search for some Elixir packages:

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:

• Tracking licenses of Elixir and NPM dependencies
• Serve as a reference for which projects use which package versions, when manually triaging Hex package vulnerabilities
• Report on NPM package vulnerabilities, with powerful auditing tools at the project or component level:

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!