Publish SBOM on releases

[chrxmvtik]

Publish an SBOM with each release so users and security teams can identify the dependencies contained in a Sofka binary, correlate them with known vulnerabilities, and satisfy software-supply-chain or procurement policies that require SBOMs for third-party tooling.

Correlated pull request #414

[nklmilojevic]

This seems useful. I support adding an SBOM to releases. Before we proceed, please clarify its scope: #414 scans the source directory, while this proposal describes dependencies in the released binaries. Could you please explain what the generated SBOM includes and how you will check its accuracy?

[chrxmvtik]

Change implemented in #414 — scans the entire project directory, it will detect the Cargo.lock|toml files and then generate an SBOM based on it, but if there are also other package managers - those will also be included.

I can make it explicitly to include only cargo files to generate SBOM.

[nklmilojevic]

Limiting the scan to Cargo files would help define the scope, but Cargo.lock also includes development, optional, and platform-specific dependencies. It does not show exactly what each released binary contains.

I suggest we start with a source dependency SBOM for the release tag and document that limitation. Please provide a sample SPDX JSON file and explain how you checked its package names and versions against Cargo.lock.

Please also confirm how development and optional dependencies appear in the output.

We can agree on that scope after reviewing the sample. If the goal remains an inventory of each binary, we need a method that accounts for its target and enabled features.

[chrxmvtik]

We can also modify a little build job and make use of cargo auditable parameter, so in that scenario we would generate SBOM based on built binaries, which does not contain any dev dependencies.

- name: Build
  run: |
    cargo auditable build \
      --release \
      --locked \
      --target ${{ matrix.target }}

- name: Generate SBOM
  run: |
    bin="target/${{ matrix.target }}/release/sofka"
    out="sofka-${RELEASE_TAG}-${{ matrix.target }}.spdx.json"

    syft scan "$bin" \
      --override-default-catalogers cargo-auditable-binary-cataloger \
      --source-name sofka \
      --source-version "${RELEASE_TAG#v}" \
      -o spdx-json="$out"

[nklmilojevic]

This would take care of the inventory goal with binaries. Could you please provide an example of the SPDX JSON file for one of the release targets? Also could you list out the features that are enabled and describe how you verified package name and versions?

[nklmilojevic]

Agreed to track this as a release dependency inventory task. The first step remains the requested sample SPDX JSON, exact build features, and package/version verification. Release integration follows review of that evidence; the issue does not treat the proposed tool chain as verified yet.

Implementation scope and acceptance checks: #647