Skip to content

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

@pimfeltkamp

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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions