What to build an SPDX inventory in GitLab CI with?

allmende
1

As a sketch, because another question than choosing a license was to find an answer on license compatibility, we can ask how to create an SPDX SBOM of this project with GitLab CI for license transparency, and then comparison. There are several paths that we can take:

  1. Repurposing GitLab’s already available free Trivy integration for security scanning to also supply SBOMs
  2. Using the Go Syft to create an SBOM
  3. Using the Kotlin ORT to create an SBOM
  4. Using the flict compliance-tools image to not only create the SBOM, but also to programmatically evaluate the license compatibility.

Other SPDX tools, like tern, scancode, sbom-tool or spdx-sbom-generater, are left out of discussion for lack of documented GitLab examples.

1. Trivy

GitLab has native integration of Container Scanning via Trivy or Grype, exposed as a reusable components made up of CI/CD templates in the CI/CD catalogue. The capabilities of the free version are naturally limited here, but we can work around that fact with using other components available for the standard that is used.

The Dependency Scanning and the visual Dependency list features in GitLab may be restricted, but the side-effect of Trivy generating a dependency list is not.

The restriction can be found around visualisation- and compliance-related behaviours. The official SPDX web app will be sufficient to provide little interactive framing of what we have at hands here, while other interfaces from the ecosystem remain available.

For Node.js, Trivy supports dependency resolution via the PNPM lock file, and license resolution via package.json.

The GitLab documentation suggests to Enable Container Scanning through an automatic merge request, which happens on the Security configuration · ecobytes / web · GitLab page, which was previously disabled.

Who’d known they’d walk in a workaround without UI to their commercial offer.

More reference about the Trivy integration in GitLab can be found upstream at both vendors:

Ultimately we want to Scan a Docker container for vulnerabilities (Tutorial) | GitLab, but Export [a] dependency list in SBOM format (Tutorial) | GitLab as we would with enterprise features.

2. Syft

In case the Trivy approach does not work out as expected, we can try to implement this with syft alongside these introductions to manually scan container images:

Including a pipeline that starts off from something along the lines of this:

3. ORT

With backing by the FSFs REUSE initiative, there is sufficient reason to also consider ORT as a viable option.

4. flict compliance tools

When we have sufficient reason to believe that a license conflict exists, i.e. by inspection of a SPDX report in one of the workbenches, we could consider mobilising flict and family from the compliance-tools container to provide additional evidence, and programmatic reevaluation of the possible confict with using the OSADL matrix. We may want to rist another peek into that any way.

Just clicking the Configure with a merge request button for Static Application Security Testing (SAST) will currently unfortunately yield the error: „Something went wrong. Please refresh the page, or try again later.“ Not to mention that a reload does not solve the regression. This may be due to a missing container in the package registry in the first place.

All of this will be a nice experiment, another time.