SBoM - Mix task to generate a Software Bill-of-Materials (SBoM)

This seems awesome.

Version 0.6.0 now available, which adds NVD CPE package identifiers to those Hex packages for which a CPE has been assigned. This allows Dependency-Track, and similar tools, to more reliably match packages to published CVEs.

Release notes:

Enhancements

• Add CPE identification, if known
• Add package description, if available

This is a whole new world to me and quite intimidating! Is there anything library writers should do to help facilitate the linkage between CVE’s and the SBoM world?

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’.

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

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

Update:

I’ve published a Rebar3 plugin as well.

Hex: rebar3_sbom | Hex
GitHub: GitHub - erlef/rebar3_sbom: Rebar3 plugin to generate CycloneDX SBoM · GitHub

I have also sent feedback to GitHub to support CycloneDX format for their security alerts feature. Especially useful with native support for Actions

I’d be very interested in getting GitHub to add support for BEAM languages to their vulnerability management features. Something that Dependabot tried to initiate. Not sure if they’re still pushing for that, now that they’re actually part of GitHub.

Anyway, are you suggesting to use an Action to generate an SBoM and then commit it to the repo for GH to scan? Like a language independent yarn.lock or Gemfile.lock? That would be interesting, but it requires commit permission within the Action. Without automation, committers would have to remember to generate and commit the latest SBoM file.

Maybe the first thing to get GitHub (and Whitesource) on board with would be the use of purl as a way to reliably identify packages.

I was thinking more about something like:

curl -d sbom=@bom.xml -d sha=$GITHUB_SHA -d token=$GITHUB_TOKEN https://github.com/hauleht/my_super_project/security/sbom

In action, such action could be even published by GitHub in the same way the checkout action is published.