fix(security): prevent GitHub Actions expression injection in build workflows (CWE-94)

[ganeshkumarashok]

Summary

Hardens the build workflows against GitHub Actions expression injection (CWE-94).

Several run: blocks interpolated ${{ }} expressions directly into shell commands. GitHub substitutes these expressions as literal text into the script before the shell runs, so a value containing shell metacharacters is evaluated as code rather than treated as data. Some of the interpolated values originate outside this repository, so they should not be treated as trusted.

This is a well-known Actions anti-pattern; the recommended remedy is to pass values through env: and reference them as quoted shell variables.

Changes

• main.yaml / ci.yaml — all ${{ }} expressions moved out of run: bodies into step-level env: blocks and referenced as quoted shell variables, so values are always data and never code. Applied to every build job, since the pattern was repeated throughout.
• main.yaml / ci.yaml — the Load config steps now validate the driver version and URL read from driver_config.yml and fail the job on anything unexpected. This also prevents newline-based injection of extra $GITHUB_OUTPUT entries.
• auto_update.py — validates the driver version and URL before writing them to driver_config.yml, so unexpected values are rejected at the point they enter the repo rather than at the point they are consumed. The URL must be https on the expected download host.
• update_grid_driver.yaml — same env: indirection for the azure/cli inline script, plus quoted $GITHUB_OUTPUT writes.

The resulting shape at each build step:

- name: 'Build and Push'
  env:
    DRIVER_URL: ${{ steps.load_config.outputs.grid_url }}
    DRIVER_VERSION: ${{ steps.load_config.outputs.grid_version }}
    REGISTRY_SERVER: ${{ secrets.AZURE_REGISTRY_SERVER }}
    VERSION: ${{ steps.semver.outputs.version }}
  run: |
    image_ref="${REGISTRY_SERVER}/public/aks/${IMAGE_REPO}:${VERSION}"
    docker buildx build --build-arg "DRIVER_URL=${DRIVER_URL}" ... -t "$image_ref" .

Note on the validation anchors

Validation uses whole-string matching — \A...\Z in Python and bash [[ =~ ]] in the workflows — because Python's end-of-string anchor also matches before a trailing newline, and grep -E matches line by line. An initial version using ^...$ was not equivalent; that was caught during testing and corrected.

Note on validation strictness

The version and URL patterns are deliberately narrow. If the upstream driver location ever changes shape, the job fails loudly and a human reviews the change rather than the pipeline accepting it automatically. Every version and URL currently published upstream satisfies the patterns, so this is not expected to trigger in normal operation.

Compatibility

No job, step, action version, or build argument was changed — only the way values reach the shell. A structural diff against main confirms the job/step graph is equivalent apart from run: bodies and added env: blocks.

azure/cli@v3 forwards step-level env: into the container it runs the script in (verified against the action source — the omit list contains only runner/system variables), so AZURE_KV_NAME / APP_PRIVATE_KEY_SECRET_NAME resolve as before.

Validation

• actionlint clean on all three workflows.
• Programmatic scan confirms zero ${{ }} remain inside any run: or inlineScript block.
• Structural diff vs main: job/step structure identical for all three workflows.
• Build commands compared before/after with substituted values: image tag, push target, --platform, --build-arg, and cache flags are equivalent for all six build jobs.
• yq lookups verified against the real driver_config.yml for all four config keys (cuda, cuda_lts, grid, grid_v20).
• Validation exercised against every driver version and URL currently published upstream: all are accepted.
• auto_update.py run end to end: real data validates and produces an unchanged driver_config.yml.

[ganeshkumarashok]

The red checks here are pre-existing and unrelated to this PR. This is a fork PR, so it receives no secrets — ${{ secrets.AZURE_REGISTRY_SERVER }} evaluates to an empty string and buildx rejects the resulting /public/aks/... tag. PR #161 failed with the identical error on an unmodified ci.yaml, and a local simulation shows the pre-change and post-change code paths produce the same invalid tag when the secret is empty.

#173 fixes that separately (with A/B evidence from a secret-less fork run). Suggested order: merge #173 first, then I will rebase this PR — the two touch the same docker buildx build lines, so a small conflict is expected and I will fold the fallback into the env: block here.

[ganeshkumarashok]

Superseded by #174 — same commit, re-opened from a branch on this repo so CI has access to repository secrets. (A PR's head branch can't be changed after creation, hence the new PR.)