Supply-Chain Incident Response

Freeze release automation fast and recover with evidence.

During a supply-chain incident, speed and containment matter more than elegance. This runbook is for freezing publication, suspending high-trust credentials, inspecting recent releases, and restoring trust in a controlled order.

Decision matrix

Immediate containment order

Immediate containment order.

Priority	Action	Why it comes first
1	Disable GitHub Actions or restrict them to approved workflows only until the cause is understood.	Stops further workflow-triggered token minting, package publication, or release mutation.
2	Suspend openbao-operator-release-pr and openbao-operator-release-tag if release automation is in scope.	Cuts off the highest-trust automation identities before new tags or draft releases can appear.
3	Freeze semver tag creation and updates through repository rulesets.	Prevents a forged or replayed release tag from triggering the stable release pipeline.
4	Rotate app private keys, the release-tag signing key, and any affected repository secrets.	Assumes any app key, signing key, or workflow-level credential may already have leaked.

Inspect

List recent high-trust workflow runs

bash

gh run list --repo dc-tec/openbao-operator --limit 30 --workflow "Release"

gh run list --repo dc-tec/openbao-operator --limit 30 --workflow "Release Please PR"

gh run list --repo dc-tec/openbao-operator --limit 30 --workflow "Release Tag"

gh run list --repo dc-tec/openbao-operator --limit 30 --workflow "Publish Edge"

Start here when you need a quick view of the workflows that can mutate releases, tags, GHCR publication state, or public manifests.

Inspect

Inspect recent release state

bash

gh release list --repo dc-tec/openbao-operator --limit 20
git ls-remote --tags origin

crane ls ghcr.io/dc-tec/openbao-operator | tail -n 20
crane ls ghcr.io/dc-tec/openbao-init | tail -n 20
crane ls ghcr.io/dc-tec/openbao-backup | tail -n 20
crane ls ghcr.io/dc-tec/openbao-upgrade | tail -n 20

Compare recent tags, draft releases, and registry publication state to what should have been produced by the workflows you trust.

Decision matrix

What to verify before restoring automation

What to verify before restoring automation.

Area	What to prove	Where to check
Workflow integrity	Pinned actions, workflow helper sources, and release logic still match reviewed repository state.	Default branch commits, workflow diffs, and recent PR history.
Release identities	Only the tag app has semver-tag bypass and the PR app has no release-tag authority.	Repository rulesets, app installation settings, and repository secrets.
Published subjects	Recent images, charts, checksums, and releases still verify against the expected workflow identity and source ref.	Release verification commands, provenance index, and GHCR digests.
Credential hygiene	Suspicious app keys, release-signing keys, tokens, PATs, sessions, or SSH keys have been revoked or rotated.	GitHub account sessions, SSH keys, GPG signing keys, app private keys, and repo/org secrets.

Recovery checklist

• Re-enable GitHub Actions only after the triggering cause is understood and contained.
• Unsuspend the PR app first; keep the tag app suspended until release creation is safe again.
• Run a controlled prerelease or RC before restoring normal stable-release activity.
• Record the affected workflow run IDs, tags, releases, GHCR digests, and remediation steps in the incident notes.

Single-maintainer constraint

This runbook improves speed and consistency, but it does not create multi-party approval. If the maintainer account is compromised, treat repository settings, Actions secrets, GitHub Apps, and release state as potentially affected until proven otherwise.

After containment

Supply chain securityReturn to the underlying trust model once the immediate incident is contained.Release managementUse the concrete release workflow when you are ready to run a controlled validation release.Continuous integrationInspect the implementation surface that may have allowed the incident path in the first place.