Skip to content

Harden CI workflows: 6 SDK ci.yml files lack explicit permissions block #7

Description

@pimfeltkamp

Iter-47 audit found that 6 of 9 SDK ci.yml files don't declare an explicit permissions: block, so the GITHUB_TOKEN runs with whatever the repo default grants. Best practice (and what GitHub's own hardening guide recommends) is to set permissions: contents: read explicitly on every CI workflow — least-privilege from the workflow itself, not relying on repo settings.

Affected workflows

Repo ci.yml Fix
cryptohopper-cli no permissions: add permissions: contents: read
cryptohopper-node-sdk no permissions: add permissions: contents: read
cryptohopper-python-sdk no permissions: add permissions: contents: read
cryptohopper-go-sdk no permissions: add permissions: contents: read
cryptohopper-ruby-sdk no permissions: add permissions: contents: read
cryptohopper-rust-sdk no permissions: add permissions: contents: read

cryptohopper-php-sdk, cryptohopper-dart-sdk, and cryptohopper-swift-sdk already have the block correctly.

Why it matters

  • CI workflows run on PR pushes including from forks. Untrusted-PR code shouldn't have write access to anything.
  • The default GITHUB_TOKEN permissions are configurable per-repo, so the actual token power varies between repos. Hard-coding permissions: contents: read in the workflow makes the security posture self-documenting and resistant to repo-setting drift.
  • release.yml workflows correctly declare contents: write (and id-token: write where needed) — this issue is only about the CI side.

Fix shape

 name: CI
 on:
   push:
     branches: [main]
   pull_request:
+
+permissions:
+  contents: read

 jobs:
   test:
     ...

Six trivial 4-line PRs, one per repo. Or I can comb them — happy to push however you'd prefer.

Why filing here, not as 6 PRs

Same reason as #6: PR review queue is already at 13 across the org and adding 6 more 4-line PRs at the same time felt like noise. Open to either approach — say the word and I'll push the PRs.

Bonus consideration

Worth setting an org-wide default at https://github.com/organizations/cryptohopper/settings/actions → "Workflow permissions" → "Read repository contents and packages permissions". That makes the default for every repo (existing and future) read-only, which means even if a future workflow file forgets the explicit block, it's still safe. The explicit block in each workflow is then belt-and-braces.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions