feat(PLT-3863): add incident hotfix deploy support to frontend-deploy-workflow

[jhuliano]

Overview

Jira ticket: https://typeform.atlassian.net/browse/PLT-3863

Adds incident hotfix deploy support to the shared frontend-deploy-workflow. When an app's deploy.yml is dispatched with an INC-* reason, the workflow validates the incident number, posts a 🚨 war-room notification before deploying, and reports the result to #tfprod-deploy.

Changes

• Add optional incident-number input (default '')
• Add war-room-notification job that validates INC-* format and posts to #war-room via slackapi/slack-github-action
• Gate deploy job on war-room-notification succeeding or being skipped
• Normal (non-incident) deploys are completely unaffected

Testing

To be tested end-to-end via the Typeform/chief PR (PLT-3863-hotfix-deploy).

Docs

• Yes! ✋ I have updated the documentation.

For contributions to the Typeform/.github repo

• This PR only changes an existing workflow.

[gitstream-cm]

🚨 gitStream Monthly Automation Limit Reached 🚨

Your organization has exceeded the number of pull requests allowed for automation with gitStream.
Monthly PRs automated: 250/250

To continue automating your PR workflows and unlock additional features, please contact LinearB.

[pr-auditor]

⚠️ Security Analysis Results

Analysis Summary:

• 📁 Files reviewed: 1
• 🟡 Medium severity: 1 issues

🟡 Medium Severity Issues

Issue 1: mcp_output_injection

📁 File: .github/workflows/frontend-deploy-workflow.yml (Line 795)

📝 Description:
The Slack chat.postMessage payload is constructed by directly interpolating several unvalidated GitHub Actions context variables — ${{ inputs.app-name }}, ${{ github.ref_name }}, and ${{ github.actor }} — into a raw JSON string. Only inputs.incident-number is validated (via the preceding shell step). If any of the remaining interpolated values contain a double-quote character (e.g. a branch named main" or an app-name input value containing "), the resulting payload is either malformed JSON (causing the Slack call to fail and blocking the deploy due to the success gate) or, in a carefully crafted scenario, structurally modified to override JSON fields such as channel, redirecting the war-room notification away from the war-room channel entirely.

⚠️ Exploit Scenario:
A developer with write access to a repository that calls this reusable workflow triggers a manual workflow dispatch for an incident deploy, passing app-name as myapp", "channel": "attacker-controlled-channel", "dummy": ". The expression ${{ inputs.app-name }} is substituted verbatim into the payload string before the slackapi/slack-github-action step executes. Depending on how the Slack API resolves duplicate or injected keys, the war-room notification may be silently delivered to a different channel, depriving the on-call team of the expected 🚨 alert during an active incident while the deployment still proceeds (if the API returns HTTP 200).

🔧 Recommendation:
Do not construct the JSON payload via string interpolation. Instead, use the slackapi/slack-github-action action's structured input method (passing individual key-value pairs it serialises internally), or pre-build the payload in a dedicated shell step that uses a tool like jq to safely encode all user-supplied and context values: e.g. jq -n --arg inc "$INCIDENT_NUMBER" --arg app "$APP_NAME" --arg ref "$REF_NAME" '{channel:"war-room",text:("🚨 ... " + $inc + " of " + $app + " branch " + $ref)}'. The validated incident-number is already safe; apply the same envelope to the remaining interpolated fields.

🎯 Confidence: 3/5

---

---

💡 Trigger a new security scan by commenting @pr-auditor rescan on this PR.

Security analysis powered by Claude Sonnet 4.6 via pr-auditor | Questions? Contact #dx-team or check out this page