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