feat(ci): add a full SBOM - app deps, OTP/Elixir runtime, container OS packages

[bougyman]

Summary

Closes #53.

mix.lock has exact versions + checksums for the Hex dependency tree, but it's not a real SBOM - wrong format (Erlang-term syntax, not SPDX/CycloneDX), no license data, and doesn't cover the OTP/ERTS runtime Burrito bundles into each binary or the Alpine packages baked into the container image.

Two real SBOMs, kept as separate files since a container SBOM has no use to anyone not using the container:

• App + Hex deps + Erlang/OTP + Elixir runtime, via erlef/mix_sbom (verified: includes the OTP standard library apps - kernel/stdlib/crypto/ssl/etc - and Elixir at the exact pinned version by default, no manual merge needed). Generated in the burrito job, attached to the release as sbom.cdx.json in the same atomic gh release create call that creates the release.
• Container OS packages (Alpine/apk), via aquasecurity/trivy-action (--format cyclonedx). Generated in the container job, which runs after the release is already published (and thus immutable, Releases ship with zero assets - GitHub's Immutable Releases locks them before the build finishes #18) - published as a workflow artifact, not a release asset, since it genuinely can't be attached to the already-locked release.

Test plan

• mix test - 182 passed
• mix format --check-formatted - clean
• Ran mix sbom.cyclonedx for real locally and inspected the actual output - confirmed it includes elixir at our exact pinned version (1.20.3) plus the OTP standard library apps, alongside all real Hex deps (67 components total)
• Verified aquasecurity/trivy-action's format input passes straight through to Trivy's own CLI (checked entrypoint.sh directly - only sarif/github are special-cased, cyclonedx isn't)
• Confirmed the exact local image tag ci/build_image.sh produces (linear-cli-ex:<tag>, no registry prefix) so Trivy scans the right reference
• Both edited workflow/doc files validated (ruby -ryaml, asciidoctor -o /dev/null)
• Next real release should show both new steps succeed, sbom.cdx.json attached to the release, and a container-sbom workflow artifact on the container job

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds automated generation and publishing of Software Bill of Materials (SBOM) outputs as part of the release pipeline, covering both application/runtime dependencies and container OS packages, and documents the new artifacts for users.

Changes:

• Generate an app/runtime CycloneDX SBOM during the Burrito release job and upload it with the GitHub release assets.
• Generate a separate CycloneDX SBOM for container OS packages via Trivy and upload it as a workflow artifact.
• Document the SBOM outputs in the README and add the SBOM tooling dependency to the app.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

File	Description
Readme.adoc	Documents the new SBOM outputs and where they are published.
app/mix.exs	Adds the :sbom dependency for local/dev SBOM generation.
app/mix.lock	Locks new transitive deps introduced by :sbom.
.github/workflows/main.yaml	Implements app SBOM generation/upload in the release job and container SBOM generation/upload in the container job.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.