SOUP: three reusable workflows for third-party component monitoring

[grafele]

The three reusable workflows for third-party component monitoring. Counterpart to
QuickBirdEng/actions#51, which adds the actions they call and the Work Instruction that
governs the process. Merge this one first: a product caller referencing
QuickBirdEng/workflows/.github/workflows/soup-sbom.yml@main fails until the file is on main.

Workflow	Calls	Does
soup-sbom.yml	actions/soup-discovery	Produce the inventory of a tagged build, assess it, attach it to the release and store it durably.
soup-kev-monitor.yml	actions/kev-monitor	Daily: resolve the version in production, re-assess it against today's vulnerability and exploitation data, write a dated record, notify.
soup-backstop.yml	—	Periodic reconciliation: days without a record, breaches without a decision, expired risk acceptances, missed maintenance windows, parameters that changed unnoticed.

on: workflow_call only, deliberately

A reusable workflow that also declares workflow_dispatch takes its inputs from whichever trigger
fired. On a manual run product arrives empty and runs-on arrives as an empty string, and
fromJSON('') fails the job before any step executes. soup-kev-monitor.yml had exactly that shape
and its manual path was broken.

The trigger belongs in the product caller, which is also how soup-version-check.yml is wired. The
callers are staged in the actions PR under patches/product-repo/:

Caller	Triggers
soup-sbom.yml	workflow_run of the product's release workflow, completed and successful; workflow_dispatch with a tag
soup-kev-monitor.yml	schedule, daily at a per-product minute; workflow_dispatch
soup-backstop.yml	schedule, quarterly for tier Extended or annually for Basic; workflow_dispatch with a window

Why the SBOM workflow waits for the release workflow

Not push: tags. The release workflow is what pushes the images of the tag, and the pipeline scans an
image by pulling it and recording the digest of what it pulled. Starting alongside the release would
record every one of our own images as a gap.

Making soup-sbom.yml a final job of each release workflow instead removes the ordering question
altogether, at the cost of editing every release path. Either is fine; the workflow_run variant needs
no change to an existing workflow. Happy to switch if you prefer the other.

Secrets

All declared required: false, and each absence has a defined consequence rather than a failure:

Secret	Without it
DO_ACCESS_KEY / DO_SECRET_KEY	Records exist as 90-day workflow artefacts only, and the backstop cannot reconcile a longer period.
SLACK_BOT_TOKEN	Runs are recorded and nobody is notified.
REGISTRY_USERNAME / REGISTRY_PASSWORD	Private images are recorded as gaps rather than scanned, and the inventory states that it is incomplete.

[grafele]

The code review of QuickBirdEng/actions#51 found that this workflow never passed release-tag to the action: under workflow_run — the normal trigger — github.ref_name is the default branch, so every bundle came out branch-tier, was never attached to a release, and was stored under the branch prefix. Fixed in 85227d3; version is documented as the release tag and is passed through as such.