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.

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.

[mergify]

This pull request does not have a backport label. Could you fix it @arpitjain099? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[swiatekm]

Can you elaborate a bit more on why you want to pin the permissions at workflow level in these specific workflows? Are these the only readonly ones we have?

[arpitjain099]

Hi @swiatekm, sure.

Both workflows just do actions/checkout + a Go validate step (elastic-agent-changelog-tool and mage check:docsFiles). Neither writes anything via the GitHub API, so capping the token to contents: read is safe. It's the same per-workflow shape docs-deploy.yml, release-notes.yml, and the other 37 workflows in this repo already use. Wider context is CVE-2025-30066 (the tj-actions/changed-files compromise last March), where caller workflows leaked whatever token scope they had at trigger time.

On scope: I audited all 42 workflows. 39 already pin permissions. These 2 plus add-issues-to-ingest-board.yml are the 3 that don't. I left the third one out because it writes to the project board, but on a closer look it uses secrets.PROJECT_ASSIGNER_TOKEN for that, not GITHUB_TOKEN, so its workflow-level token could probably also drop to contents: read or {} without breaking anything. Happy to add it here if you want.

Whichever backport branch fits, just let me know or label it yourselves.

[swiatekm]

@arpitjain099 thanks for explaining! I think we should cover the third workflow as well, if we can do so without losing functionality. I'll take care of the backport labels.

[infra-vault-gh-plugin-prod]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[v1v]

Permissions should be granted always at the job level in case they need any write access or other scopes. I like the principle of least-permissive access by default, thanks for this.

[swiatekm]

buildkite test this

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: cfb1e78

Failed CI Steps

• Win2022:sudo:fleet

cc @arpitjain099

[github-actions]

@Mergifyio backport 9.4 9.3 8.19

[mergify]

backport 9.4 9.3 8.19

✅ Backports have been created

Details

• #14386 [9.4] (backport #14331) ci: declare workflow-level contents: read on 2 workflows has been created for branch 9.4
• #14387 [9.3] (backport #14331) ci: declare workflow-level contents: read on 2 workflows has been created for branch 9.3
• #14388 [8.19] (backport #14331) ci: declare workflow-level contents: read on 2 workflows has been created for branch 8.19 but encountered conflicts

Cherry-pick of 5bebb64 has failed:

On branch mergify/bp/8.19/pr-14331
Your branch is up to date with 'origin/8.19'.

You are currently cherry-picking commit 5bebb643b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   .github/workflows/fragment-in-pr.yml

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by us:   .github/workflows/validate-docs-structure.yml

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally