Automate SBOM generation

[alexmt]

Summary

Automate SBOM generation and include it as part of release artifacts.

Motivation

SBOM would be useful for end-users and partners to quickly find out which components are used by Argo CD and help to identify components that may be subject to security vulnerabilities, catch components with incompatible licenses etc.

Proposal

Implement a script that would produce markdown document with the table that includes list of components, version and license. The release workflow should use the script to generated SBOM document and attach it to the Github release.

[leoluz]

I did a quick investigation about how to implement this using existing available tooling. The SPDX format is the standard used for producing SBOM documents. I found this github action that will generate a SPDX file automatically inspecting the repository using ORT which is compatible with Golang projects (gomod, dep, etc).

From their docs, an example on how to use the github-action would look like:

  - uses: actions/checkout@v2
  - uses: actions/setup-java@v1
    with:
      java-version: '11.0.13'
  - name: Create spdx-file
    id: spdx-builder
    uses: philips-software/spdx-action@v0.9.1.1
    with:
      project: argocd
      mode: ort
  - uses: actions/upload-artifact@v2
    with:
      name: licenses
      path: ${{ steps.spdx-builder.outputs.spdx-file }}

[alexec]

Might be worthwhile looking into this:

https://github.com/kubernetes-sigs/bom

Used by Kubernetes and ISTIO

[leoluz]

I gave up on the philips-software/spdx-action idea as documentation is lacking and tooling is very complex. I'm currently giving https://github.com/spdx/spdx-sbom-generator a try as it is much simpler and is a community supported spdx generator in Go

[leoluz]

This is a functional github action that generates the SPDX file from the go.mod and upload it as artifact:

jobs:
  spdx-sbom-generator:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-go@v2
      - name: Generate SBOM (spdx)
        id: spdx-builder
        run: |
          wget -q https://github.com/spdx/spdx-sbom-generator/releases/download/v0.0.10/spdx-sbom-generator-v0.0.10-linux-amd64.tar.gz -O generator.tar.gz
          tar -zxf generator.tar.gz
          ./spdx-sbom-generator
          echo "::set-output name=spdx-file::$(realpath bom-go-mod.spdx)"
      - uses: actions/upload-artifact@v2
        with:
          name: licenses
          path: ${{ steps.spdx-builder.outputs.spdx-file }}

[leoluz]

this is a similar github action job that uses sigs.k8s bom suggested by @alexec

jobs:
  spdx-sbom-generator:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-go@v2
        with:
          go-version: ^1.17.2
      - name: Generate SBOM (spdx)
        id: spdx-builder
        run: |
          go install sigs.k8s.io/bom/cmd/bom@v0.2.1
          bom generate -o bom.spdx .
          echo "::set-output name=spdx-file::$(realpath bom.spdx)"
      - uses: actions/upload-artifact@v2
        with:
          name: licenses
          path: ${{ steps.spdx-builder.outputs.spdx-file }}

[leoluz]

As discussed with @alexmt we decided to go with spdx/spdx-sbom-generator as it supports multiple package managers like gomod, yarn, npm as opposed to kubernetes-sigs/bom which is gomod centric.

[alexec]

I'm trying to understand, what files should go in the bom. Not just source code, but also any binaries?

[leoluz]

@alexec

I'm trying to understand, what files should go in the bom. Not just source code, but also any binaries?

I guess it really depends on what we want. If the main purpose is to provide a way to inspect for vulnerabilities in libraries we depend on, analysing the package manage should be enough. If we also want to provide binary report, I guess we would have to inspect our docker image for every binary added to every layer. Docker image inspection is only available in kubernetes-sigs/bom. If that is necessary we can maybe use both tools.

[alexec]

How come you need to yarn install is that in case the actual files are different to the package.json. E.g. you're using some kind of NPM "latest" version?

Docker image creation will bring in new "ingredients" (e.g. from apt). How can we include them in the BOM? With bom you can do this https://github.com/kubernetes-sigs/bom#process-a-container-image.

[alexec]

I see you already answer my question about images.

[leoluz]

@alexec pushed another PR (https://github.com/argoproj/argo-cd/pull/8338) introducing binary inspection from docker image