M7: Build an ORT Analyzer Plugin which ingests SBoM Information generated by Milestone 5 & 6 and maps to ORT internal data structures

[tsteenbe]

What we want

Build an ORT Analyzer Plugin which ingests SBoM Information generated by...

M5: Create a standalone executable from Milestone 3 so that SBoMs can be produced without bootstrapping a complete Erlang runtime environment

and

M6: Create a standalone executable from Milestone 4 so that SBoMs can be produced without bootstrapping a complete Elixir runtime environment

And maps to ORT internal data structures

Context

The OSS Review Toolkit (ORT) is a FOSS policy automation and orchestration toolkit used to manage open source dependencies strategically, safely, and efficiently. Its modular pipeline—Analyzer, Downloader, Scanner, Advisor, Evaluator, Reporter, and Notifier—collects dependency data, enriches it with findings, evaluates policies, and produces compliance-ready reports and artifacts.

This milestone adds Erlang and Elixir support to ORT by fitting these ecosystems into ORT’s normal analysis model and pipeline. Because Erlang/Elixir projects depend heavily on Hex.pm (and compatible registries), they don’t always work well with ORT’s usual “read the lockfile and resolve dependencies” approach. However, the ecosystem can already generate dependency lists as CycloneDX SBOMs, which are a widely used, portable format. So instead of building a custom resolver, ORT will ingest CycloneDX 1.6 JSON SBOMs (including those produced by the standalone tools from M5 and M6) and convert them into ORT’s internal analyzer result.

To support CI and container workflows, the required SBOM generators will be included in the non-minimal ORT Docker image (while keeping the minimal image small).

Finally, ORT will enrich SBOM data by querying Hex.pm / Hex-compatible registries for missing or more reliable metadata such as licenses, links, checksums, and release information.

What we need to change in the ORT

ORT’s Analyzer

The Analyzer is the ORT component responsible for determining a project’s dependencies and producing ORT’s internal result model: Projects / Packages / Scopes / Issues.

In this milestone, the Analyzer will not rely solely on ORT’s “native lockfile resolver” approach; instead, it will ingest a CycloneDX SBOM (produced by the Erlang/Elixir SBOM generators, including the standalone executables from M5/M6) and convert it into a ProjectAnalyzerResult, so the rest of ORT can operate normally on top of that output.

Downloader (indirectly)

Once the Analyzer produces dependencies, ORT may download source artifacts for scanning. This is where Hex-specific handling matters—e.g., correctly extracting Hex tarballs that contain a nested contents.tar.gz—so the full ORT pipeline works end-to-end for Hex packages.

How to

At a high level, the development approach is to treat CycloneDX as the input contract for Erlang/Elixir dependency graphs and make ORT’s Analyzer understand that contract.

The Analyzer plugin(s) will consume CycloneDX output from the SBOM generators (including the M5/M6 standalone binaries), translate it into ORT’s internal dependency graph and package metadata model, and then optionally enrich missing or incomplete fields using registry metadata from Hex.pm / compatible registries. With that Analyzer output in place, ORT’s existing stages (Downloader, Scanner, Advisor, Evaluator, Reporter, Notifier) can run unchanged, enabling a consistent compliance and reporting workflow for Erlang and Elixir projects.

---

Others

A plugin is a small, separate piece of code that adds a new capability to a larger system without changing the system’s core. In ORT specifically, a plugin usually means: “Teach ORT how to handle a new ecosystem / input.”

For example, a new Analyzer plugin can tell ORT how to understand dependencies for a new package manager (like Mix / Rebar3 / Gleam Packages) or how to read a new format (like a CycloneDX SBOM).

Plugins provide the ecosystem-specific logic and translate that ecosystem’s data into ORT’s common model.

Examples of plugins for different packages manager here

---

Milestone Report

Summary

This milestone delivers ORT support for Erlang and Elixir projects by adding native Analyzer plugins that resolve dependencies for Hex-based ecosystems and use CycloneDX SBOMs as the transport format into ORT. The plugins run the ecosystem-specific SBOM generators, ingest the resulting CycloneDX output, and map it into ORT’s internal analysis model.

Deliverables

• ORT Analyzer plugin that converts CycloneDX 1.6 JSON SBOMs into ORT’s internal ProjectAnalyzerResult
• Support for Erlang and Elixir projects using SBOMs as the dependency source
• End-to-end compatibility with ORT’s pipeline, including downloading and scanning of Hex packages
• Inclusion of required SBOM generators in the non-minimal ORT Docker image to support CI and container workflows
• Metadata enrichment via Hex.pm and compatible registries where SBOM data is incomplete
• Improved ORT Docker support, including ARM builds and automated image publishing

Implementation

Main implementation

• ORT Analyzer plugin: Erlang & Elixir Package Manager Plugins oss-review-toolkit/ort#11319

Additional required changes and fixes

• ORT follow-up fixes: fix(plugins): Filter empty strings when parsing string list options oss-review-toolkit/ort#11324
• ORT Docker ARM support and image publishing: Build & Fix ARM64 Image oss-review-toolkit/ort#11225
• mix_sbom fixes / improvements:
  • Fix Hex Distribution URL erlef/mix_sbom#79 - Fix Hex Distribution URL
  • Expose --exclude-system-dependencies in GH Action erlef/mix_sbom#78 - Expose --exclude-system-dependencies in GH Action
  • Add externalReferences for otp components erlef/mix_sbom#77 - Add externalReferences for otp components
  • Introduce Option to exclude system dependencies from BOM erlef/mix_sbom#76 - Introduce Option to exclude system dependencies from BOM
  • Use ORT to generate SBoM instead of REUSE erlef/mix_sbom#75 - Use ORT to generate SBoM instead of REUSE
• rebar3_sbom improvements:
  • Use ORT to generate SBoM instead of REUSE erlef/rebar3_sbom#35 - Use ORT to generate SBoM instead of REUSE
• bombom fixes / improvements:
  • Install libcbor and libarchive statically erlef/bombom#9 - Install libcbor and libarchive statically
  • Fix artifact download paths in release workflow erlef/bombom#7 - Fix artifact download paths in release workflow
  • Add CI for linux amd64/arm64 erlef/bombom#2 - Add CI for linux amd64/arm64
• Documentation:
  • Elixir SBOM documentation: Add Software Bill of Materials guide to the Documentation elixir-lang/elixir#15067
  • Rebar3 documentation: Include the sbom plugin as recommended tsloughter/rebar3.org#139

Documentation

• ORT Mix plugin documentation: https://oss-review-toolkit.org/ort/docs/plugins/package-managers/Mix (pending)
• ORT Rebar3 plugin documentation: https://oss-review-toolkit.org/ort/docs/plugins/package-managers/Rebar3 (pending)
• Elixir SBOM docs: https://hexdocs.pm/elixir/main/sbom.html (pending)
• Rebar3 SBOM docs: https://www.rebar3.org/docs/configuration/plugins/ (pending)

Outcome

With this milestone completed, ORT can analyze Erlang and Elixir projects using CycloneDX SBOMs as input, enabling consistent policy enforcement and compliance workflows alongside other ecosystems supported by ORT.