Devel to main - SBOM and Image patch

[uk-bolly]

Description of change

• supply chain

  • every release now publishes a software bill of materials, one SPDX 2.3
    document per binary, named to match the binary it describes
    (syver-linux-amd64.spdx.json beside syver-linux-amd64). SPDX was chosen
    over CycloneDX because it is the format most compliance consumers expect,
    and the format is what downstream automation binds to
  • the SBOMs are GPG-signed with the same key as the checksum file, so
    everything in a release carries a signature from one key rather than
    leaving you to guess which artifacts are authoritative. The published key
    is unchanged and verification is documented as before

• container image

  • the published image now upgrades its Alpine packages at build time. The
    base image is republished infrequently, so building alone shipped whatever
    package set had been baked into it months earlier, and the weekly scan was
    reporting OpenSSL advisories against the published image as a result.
    Syver's own binary is statically linked with cgo disabled and calls none of
    those libraries, so nothing syver does was exploitable through them, but
    this image is documented as a base image and an unpatched package here is
    inherited by every downstream FROM

• docs

  • RELEASES.md said Syver "continues goss's version numbering... so that
    v0.6.0 means the same lineage point in both projects". Read cold, that
    implies upstream goss-org/goss released a v0.6.0. It did not; its versions
    run to v0.4.x. This project released v0.5.0 and v0.6.0 itself, under the
    name krameff/goss, before the rename. The lineage section now says so,
    and says plainly that krameff/goss and Syver are one project under two
    names rather than two projects. It also listed a v0.4.0 tag that has
    never existed in this lineage

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.