I have created GitHub Action for generating SBoM using this project. I hope that this will help with adoption.

Version 3.7.1 of OWASP Dependency-Track comes with Hex integration, flagging available package updates:

Screen Shot 2020-01-23 at 9.35.552046×1058 126 KB

Thanks for the suggestion - updated all my libs with the :licenses key as you suggest. Now to check out @hauleth’s GitHub action!

Specifically for CVEs there isn’t anything that can be done: CVEs use CPE values to identify affected software components, and CPEs are assigned by NVD or a CVE Numbering Authority (CNA) if and when they are needed. For open source projects hosted on GitHub the CPE is often derived from the account and repo names, but that’s not guaranteed. Officially a CPE value does not exist until it is added to the NVD database.

An alternative scheme, called purl, allows for more reliable package identification, regardless of whether or not a vulnerability was previously reported for it. This scheme is preferred over CPEs by CycloneDX, Dependency-Track and services like Sonatype’s OSS Index. I have proposed a formal definition of Hex package URLs to the Hex team.

One thing package maintainers can do to help SBoM tools, though unrelated to vulnerabilities, is to specify a package’s license using official SPDX Identifier in mix.exs:

  def project do
    [
      # ...
      package: [
        licenses: ["BSD-3-Clause"],
        # ...
      ]
    ]
  end

This ensures the package license is properly identified, and the SBoM scanner doesn’t have to fall back to heuristics or just mark the license as ‘unknown’.

Update:

I’ve published a Rebar3 plugin as well.

Hex: https://hex.pm/packages/rebar3_sbom
GitHub: https://github.com/voltone/rebar3_sbom