ci: declare workflow-level contents: read on 16 build/regen workflows

[arpitjain099]

Pins the default GITHUB_TOKEN to contents: read on every workflow in .github/workflows/. They are all native-library binding regen workflows (angle, assimp, dxvk, glfw, moltenvk, openal-soft, sdl2, shaderc, spirv-cross, spirv-reflect, swiftshader, vkd3d, vulkan-loader, wgpu) plus bindings-regeneration and codeowners checks. None of them call a GitHub API beyond the initial checkout.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load on each touched file.

[arpitjain099]

@dotnet-policy-service agree

[Perksey]

Pretty sure these workflows make use of write permissions (to push the regenerated bindings)

[arpitjain099]

Good thing to check, and you're right that these workflows do push the regenerated bindings. I looked at how they authenticate that push, though, and it doesn't go through the default GITHUB_TOKEN:

• Each workflow runs actions/checkout@v2 with token: ${{ secrets.PUSHABLE_GITHUB_TOKEN }}, so the persisted git credential is that PAT, and the later push from the nuke build uses it (angle.yml:36, bindings-regeneration.yml:19, sdl2.yml:41, etc).
• The build/regen step that does the actual push gets the PAT via env: PUSHABLE_GITHUB_TOKEN, not the default token.

A workflow-level permissions: block only scopes the default GITHUB_TOKEN. Since none of these 16 use the default token for anything, contents: read doesn't touch the bindings-push path; it just shrinks the default token's blast radius if one of the build actions were ever compromised (the CVE-2025-30066 supply-chain case). These run on push with a powerful PAT in scope, so tightening the ambient token is worthwhile.

I deliberately left build.yml out of this PR for exactly the reason you raised: it's the one that uses secrets.GITHUB_TOKEN directly (PushToNuGet to GitHub Packages at build.yml:81), so it genuinely needs packages: write and isn't a contents: read candidate.

Happy to walk through any specific file if you'd like, or drop any you're not comfortable with.

[Perksey]

Hmmmm, okay I'll merge but I'm not happy with the AI-generated explanation, however accurate it may be. Would appreciate human words next time.