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

Generates a dependency inventory, or “Software Bill-of-Materials” (SBoM), including package versions and licenses, in a format that can be imported into free or commercial tools for Software Composition Analysis. Currently supports CycloneDX format.

Hex: https://hex.pm/packages/sbom
Hexdocs: https://hexdocs.pm/sbom/
GitHub: https://github.com/voltone/sbom

Blog post, showing the creation of a combined Hex/NPM SBoM for a Phoenix project, including loading the result into an OWASP Dependency-Track server: https://blog.voltone.net/post/24

14 Likes

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

1 Like

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

3 Likes

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

3 Likes

Update:

I’ve published a Rebar3 plugin as well.

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

2 Likes

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.

1 Like

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.

That’s certainly an interesting idea: submitting a standardised SBoM through an API would allow Actions to be created for pretty much any language, without requiring GH involvement. But I imagine it would require some significant changes on GitHub’s side. Right now their tooling is driven off of files found in the repo, as long as they are recognised as supported dependency declaration formats.

Official GitHub Response

Hi Łukasz,

Thanks for your feedback! We’re always working to improve GitHub and we consider every suggestion we receive. I have added your request for CycloneDX support in the dependency graph to our internal Feature Request List.

We can’t say if/when we may add a feature, however your feedback has definitely been recorded.

Thanks,

Steve G.
GitHub Support

So there is chance that this may happen. It still would be easier than implementing each language separately.

1 Like

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

3 Likes