Summary
The cleanup-staging.yml GitHub Actions workflow hardcodes ref: feat/multicloud-web-frontend on all actions/checkout steps:
- name: Checkout code
uses: actions/checkout@v4
with:
ref: feat/multicloud-web-frontendThis branch is the active development branch and is not the main branch. Once this feature branch is merged and deleted, the cleanup workflow will reference a non-existent branch and silently check out whatever default fallback GitHub applies — or fail. More critically, any commit pushed to feat/multicloud-web-frontend by any collaborator (or a compromised contributor) automatically becomes the Terraform configuration used by the terraform destroy workflow.
This is a supply-chain risk: the destroy workflow should reference a protected, stable ref (e.g. main, a tag, or the workflow's own ${{ github.ref }} with environment protection).
Location
.github/workflows/cleanup-staging.yml lines 58, 120, 183, 248 (current HEAD on main)
Suggested fix
Replace the hardcoded branch ref with:
${{ github.ref }} (triggers on workflow_dispatch, so uses the branch selected at trigger time)- Or omit the
ref entirely (defaults to the branch the workflow_dispatch runs on)
- Add a GitHub Environment (
staging-destroy) with required reviewers so the workflow can only run after explicit approval
Also add a validation step that the checked-out Terraform config matches an expected SHA or tag before applying terraform destroy.
Severity rationale
MEDIUM — only workflow_dispatch triggers this workflow, with the "destroy" confirmation guard. The immediate practical risk is accidental breakage when the branch is deleted. The secondary risk (supply-chain via feature branch) is real but requires collaborator access to the branch.
Summary
The
cleanup-staging.ymlGitHub Actions workflow hardcodesref: feat/multicloud-web-frontendon allactions/checkoutsteps:This branch is the active development branch and is not the
mainbranch. Once this feature branch is merged and deleted, the cleanup workflow will reference a non-existent branch and silently check out whatever default fallback GitHub applies — or fail. More critically, any commit pushed tofeat/multicloud-web-frontendby any collaborator (or a compromised contributor) automatically becomes the Terraform configuration used by theterraform destroyworkflow.This is a supply-chain risk: the destroy workflow should reference a protected, stable ref (e.g.
main, a tag, or the workflow's own${{ github.ref }}with environment protection).Location
.github/workflows/cleanup-staging.ymllines 58, 120, 183, 248 (current HEAD onmain)Suggested fix
Replace the hardcoded branch ref with:
${{ github.ref }}(triggers onworkflow_dispatch, so uses the branch selected at trigger time)refentirely (defaults to the branch the workflow_dispatch runs on)staging-destroy) with required reviewers so the workflow can only run after explicit approvalAlso add a validation step that the checked-out Terraform config matches an expected SHA or tag before applying
terraform destroy.Severity rationale
MEDIUM — only
workflow_dispatchtriggers this workflow, with the"destroy"confirmation guard. The immediate practical risk is accidental breakage when the branch is deleted. The secondary risk (supply-chain via feature branch) is real but requires collaborator access to the branch.