ci: declare workflow-level contents: read on 2 workflows

[arpitjain099]

Pins the default GITHUB_TOKEN to contents: read on 2 workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout.

Left implicit because they reference GITHUB_TOKEN / use a write-scope action / trigger on pull_request_target. Best declared by a maintainer: kotlin.yml.

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.

[CLAassistant]

All committers have signed the CLA.

[steve-the-edwards]

@arpitjain099 - this looks helpful - can I ask why you opened this PR though? Are you attempting to follow up from https://github.com/advisories/GHSA-mrrh-fwg8-r2c3 across github?

Wouldn't this be mitigated by requiring approval for the worklfows to run?

[arpitjain099]

Good questions @steve-the-edwards.

Are you attempting to follow up from GHSA-mrrh-fwg8-r2c3 across github?

Not that specific advisory directly. The trigger for this batch of PRs across repos was CVE-2025-30066 in March (the tj-actions/changed-files supply-chain compromise) - that incident exfiltrated GITHUB_TOKEN from caller workflow logs whenever a transitive action was breached, and the blast radius was whatever scope the token had at trigger time. Per-workflow contents: read caps that for workflows that don't actually need more.

Wouldn't this be mitigated by requiring approval for the workflows to run?

Approval gates help against "new untrusted contributor's PR triggers malicious code on a runner that holds a powerful token" but they don't help against an already-trusted action becoming compromised mid-stream (the tj-actions pattern). Once a workflow is running, the token is whatever scope was granted regardless of who initiated it.

The two layers compose: approval-required gates reduce the surface where malicious code reaches a runner, and explicit per-workflow scopes reduce what a compromised runner can do when it gets there. Happy to close if defense-in-depth on top of approval-required isn't the shape you want for this repo.

[steve-the-edwards]

@arpitjain099 - Thanks for the replies - I will merge this now if you sign the CLA.

[arpitjain099]

@arpitjain099 - Thanks for the replies - I will merge this now if you sign the CLA.

@steve-the-edwards Signed CLA, please merge