Add workflow to expand telemetry tags from PR command

[Groenbech96]

Summary

• add new workflow to trigger telemetry tag expansion from /telemetry-tags PR comments
• support manual workflow_dispatch with PR number
• push updates when possible and fall back to patch artifact + PR comment for fork PRs

Validation

• YAML parse smoke test passed locally
• Trigger and job presence validated in workflow file

[github-actions]

Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234'

[github-actions]

Copilot PR Review

Iteration 2 · Outcome: completed

All 15 AL-scoped sub-skills ran but found no worklist (the PR's real diff, taken against the git merge-base rather than the stale origin/main tip, contains no AL source changes - see finding message for details on the base-branch divergence). The super-skill's own cross-cutting self-review pass over the added GitHub Actions workflow surfaced one high-impact agent finding.

Knowledge source: https://github.com/microsoft/BCQuality@809af9708e265f110ced6752fd8f2e40f1efc820

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Agent	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

Orchestrator pre-filter (2 file(s) excluded)

• layer-disabled (knowledge) : 2 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 809af9708e265f110ced6752fd8f2e40f1efc820. Reply 👎 on any inline comment to flag false positives.}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 2}}$

Note on true severity: the underlying impact of this finding is a critical/blocker-grade CI supply-chain vulnerability; it is capped to 'minor' here only because no BCQuality knowledge file backs it (agent-finding rule), not because the real risk is low - it should be triaged as a blocker and a corresponding knowledge article should be authored.

Important scoping note: this review was asked to diff against origin/main, but the PR branch (HEAD) is 26 commits behind origin/main and only 2 commits ahead of the merge-base (f7f34ab). A raw 'git diff origin/main' therefore shows ~285 unrelated files (a Job->Project rename, several unrelated bugfix reverts, etc.) that are just divergence noise from the stale base, not part of this PR. The actual PR content, diffed against the merge-base, is a single new file: .github/workflows/ExpandTelemetryTagsFromPRComment.yaml (304 lines), which adds a maintainer-triggered '/telemetry-tags' comment workflow with 'contents: write' and 'issues: write' permissions. In the 'Comment result on PR' step, several GitHub Actions '${{ }}' expressions whose values are attacker-controlled are interpolated directly into the PowerShell run: script text instead of being passed through env: variables (the safe pattern the same workflow already uses elsewhere, e.g. HEAD_REF in the 'Commit and push updates' step). Specifically: '${{ steps.context.outputs.headRef }}' (the PR's head branch name, which is fully attacker-chosen by whoever opens the PR - git ref names permit backticks, double quotes, '$', and parentheses) is embedded inside a double-quoted PowerShell string, and '${{ steps.expand.outputs.errorMessage }}' (a raw exception .Message that can originate from processing attacker-supplied .al file content checked out from the PR) is embedded inside a PowerShell here-string. Because GitHub Actions performs textual substitution of these expressions before the script runs, a PR author can choose a branch name or craft file content that breaks out of the surrounding string/here-string and injects arbitrary PowerShell that executes in this job's context - which holds 'GH_TOKEN: ${{ github.token }}' with 'contents: write' and 'issues: write'. The exploit fires as soon as any maintainer (who is otherwise trusted and simply runs the intended '/telemetry-tags' command on the attacker's PR) triggers the workflow; the authorization check only gates who can invoke the command, it does not sanitize the untrusted headRef/errorMessage values that are later interpolated. This is the classic GitHub Actions 'script injection via untrusted input' / pwn-request pattern and would let an external contributor push arbitrary commits or exfiltrate the workflow token.

Recommendation:

• pass every value derived from PR-controlled data (head ref, exception messages, file paths/content, comment bodies, etc.) into the run: step exclusively via the env: block (as already done correctly for HEAD_REF in the push step) and reference it only as $env:VarName inside the script; never interpolate '${{ ... }}' expressions carrying such data directly into run: script text.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}