Setup OSS Review Toolkit SBoM generation

[maennchen]

Implement Source SBoM Generation

Scope

This PR implements source SBoM generation using OSS Review Toolkit
in the following formats:

• CycloneDX (v1.6) JSON / XML
• SPDX (v2.2) JSON / YML

The PR implements a very simple Open Source Policy with a list of allowed licenses. Namely:

• Apache-2.0 (Elixir itself / copied OTP code)
• LicenseRef-elixir-trademark-policy (Elixir Logo)
• LicenseRef-scancode-unicode (Unicode Files)

The idea is that if we add other code / dependencies with other licenses, the inclusion has to be
agreed by the Elixir team and the list extended.

OpenChain

This PR implements the technical parts of OpenChain ISO/IEC 18974:2023.

Specifically:

§ 4.1.5 Standard practice implementation

The program shall demonstrate sound and robust handling procedures of known vulnerabilities and secure
software development by defining and implementing following procedures:

[...]

• Method for detecting existence of known vulnerabilities in supplied software;
  [...]
• Method to export information about identified risks to third parties as appropriate.

§ 4.3.1 Software bill of materials

A process shall exist for creating and maintaining a bill of materials that includes each open source software
component from which the supplied software is comprised.

Verification material(s):

• 4.3.1.1: A documented procedure ensuring all open source software used in the supplied software is
  continuously recorded across the life-cycle of the supplied software. This includes an archive of all open
  source software used in the supplied software;
• 4.3.1.2: open source software component records for the supplied software that demonstrates the
  documented procedure was properly followed.

Future

There's a few things I would like to address in the future:

• Full OpenChain compliance - Since Elixir does not have many dependencies, it should
  be relatively trivial to achieve OpenChain compliance after this PR. I'd like to
  propose the required documentation and certify compliance. (btw. Ericsson including
  OTP is OpenChain compliant and on the way to be certified as well.)
• OSS Review Toolkit currently does not recognize mix / rebar applications as packages.
• While we attest the distribution assets with the SBoMs, the SBoM itself does not list
  the distribution assets. This is not feasible until ORT recognizes mix applications. - Will be handled in a lat er stage with an actual build SBoM.
• Erlang is not listed as a build dependency in the SBoMs. As soon as OTP publishes
  SBoMs themselves, I'd like to incorporate that.
• Source Licenses currently are largely defined with an override in .ort.yml. It would be
  better to include a header in each file to state the license explicitly. This also
  works when code is copied from this repository.
• Copyright is currently only detected because of the copyright text in the LICENSE in the
  root. It would be better to include a header in each file to state the copyright explicitly.
  This also works when code is copied from this repository.

Results

• Example ci.yml run: https://github.com/maennchen/elixir/actions/runs/13029706072
• Example release.yml run: https://github.com/maennchen/elixir/actions/runs/13029706053
• Example GitHub Release: https://github.com/maennchen/elixir/releases/tag/jm%2Foss-review-toolkit-latest

[josevalim]

Since Elixir does not have many dependencies

Theoretically Elixir depends on Make (build-time only) and Erlang, but those are done through the system. Does SBOM make a distinction between build and runtime deps? What about system vs actual deps?

OSS Review Toolkit currently does not recognize mix / rebar applications as packages.

What are mix/rebar applications here? And does it impact this repo in any way, given we don't depend on any of those?

---

Regarding licenses and copyrights, agreed. Let's do that next. :)

[kikofernandez]

Since Elixir does not have many dependencies

Theoretically Elixir depends on Make (build-time only) and Erlang, but those are done through the system. Does SBOM make a distinction between build and runtime deps? What about system vs actual deps?

The only thing that this claims is the source Software Bill of Materials (SBOM), so the files that exist in this repo.
If you provide binaries, the Build SBOM will have to be generated using other tooling.

[maennchen]

Does SBOM make a distinction between build and runtime deps? What about system vs actual deps?

That depends heavily between standards and their versions. I'll have a closer look at that once we add build information to the SBoMs.

What are mix/rebar applications here? And does it impact this repo in any way, given we don't depend on any of those?

Elixir contains multiple "components" like elixir, mix, eex, etc. It would be good if the tooling recognized those distinctly.
Currently, the tooling only recognizes the whole project as SPDXRef-Project-Unmanaged-elixir-[hash]. If it detected the libraries, it would describe the project as a combination of components that can be individually addressed in configuration.

[josevalim]

Elixir contains multiple "components" like elixir, mix, eex, etc.

@kikofernandez is Erlang being broken into multiple components as well or a single one?

I am not sure for Elixir if it makes sense to break them apart. They are always shipped together anyway. Might as well consider as a single entity?

[kikofernandez]

@kikofernandez is Erlang being broken into multiple components as well or a single one?

At the moment, we are going to create a single package for the source SBOM, which will contain all of OTP.
Maybe in the future we do, but for OTP-28, my goal is a single source SBOM that satisfies the minimum NTIA requirements and OpenChain requirements.

[kikofernandez]

If I may, I would suggest that Elixir starts to annotate all files with a license and possibly copyright identifier.
We plan on using REUSE to comply with licenses in an easy way (PR-9360), and that means also adding SPDX license identifiers starting with OTP-28, and we will try to add those licenses wherever we can to all of OTP. This tool allows also the creation of a TOML file to annotate files without adding the license to its source file, which allows people to add license and copyright to images, txt, and other file formats or tests without disrupting them.

I create a REUSE PR (PR-1117) that allows to add easily licenses to Erlang, Elixir, and Gleam

[josevalim]

@kikofernandez we plan to do that in a future PR :)

@maennchen let's focus on shipping Elixir as a single unit for the foreseeable future as well!

[josevalim]

💚 💙 💜 💛 ❤️