Skip to content

ops: tighten workflow token permissions (Scorecard PR B)#41

Merged
amavashev merged 1 commit into
mainfrom
ops/tighten-workflow-permissions
May 2, 2026
Merged

ops: tighten workflow token permissions (Scorecard PR B)#41
amavashev merged 1 commit into
mainfrom
ops/tighten-workflow-permissions

Conversation

@amavashev
Copy link
Copy Markdown
Contributor

Same pattern as cycles-server#144. Adds top-level read-all to ci-java.yml and ci-python.yml (reusable workflows consumed by every SDK/service repo — fix here strengthens token hygiene across the org transitively); rewrites dependabot-auto-merge.yml. Addresses Token-Permissions in OpenSSF Scorecard.

Same pattern as runcycles/cycles-server#144. Adds top-level read-all to
ci-java.yml and ci-python.yml (reusable workflows consumed by every
SDK/service repo); rewrites dependabot-auto-merge.yml. Addresses
Token-Permissions criterion from OpenSSF Scorecard.
@amavashev amavashev merged commit 18fd75e into main May 2, 2026
@amavashev amavashev deleted the ops/tighten-workflow-permissions branch May 2, 2026 20:45
amavashev added a commit that referenced this pull request May 2, 2026
…s) (#43)

Reusable workflows can only request permissions the *calling* workflow
has granted via its top-level permissions block. PR #41's permissions
sweep added 'permissions: read-all' to ci-java.yml and ci-python.yml,
which expanded to ~15 read scopes (actions, packages, pages, etc.).

Every caller that grants narrower permissions hit this error:

  'workflow is requesting actions: read, artifact-metadata: read,
   attestations: read, ... but is only allowed actions: none, ...'

Concrete impact: cycles-server's ci.yml declares 'permissions: contents:
read' at top level. After PR #41 merged, every CI run on cycles-server
returned startup_failure (no jobs created). Same for any other repo
calling ci-java.yml or ci-python.yml.

Fix: match the working pattern from ci-rust.yml and ci-typescript.yml.
Declare only 'permissions: contents: read' at the workflow level — the
narrowest permission the workflow actually needs (Maven/pip checkout
+ build). Job-level permissions stay as-is.

Scorecard's Token-Permissions check still passes because each workflow
has explicit (non-default) permissions declared at both levels.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant