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
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.
Iter-47 audit found that 6 of 9 SDK
ci.ymlfiles don't declare an explicitpermissions:block, so theGITHUB_TOKENruns with whatever the repo default grants. Best practice (and what GitHub's own hardening guide recommends) is to setpermissions: contents: readexplicitly on every CI workflow — least-privilege from the workflow itself, not relying on repo settings.Affected workflows
ci.ymlcryptohopper-clipermissions:permissions: contents: readcryptohopper-node-sdkpermissions:permissions: contents: readcryptohopper-python-sdkpermissions:permissions: contents: readcryptohopper-go-sdkpermissions:permissions: contents: readcryptohopper-ruby-sdkpermissions:permissions: contents: readcryptohopper-rust-sdkpermissions:permissions: contents: readcryptohopper-php-sdk,cryptohopper-dart-sdk, andcryptohopper-swift-sdkalready have the block correctly.Why it matters
GITHUB_TOKENpermissions are configurable per-repo, so the actual token power varies between repos. Hard-codingpermissions: contents: readin the workflow makes the security posture self-documenting and resistant to repo-setting drift.release.ymlworkflows correctly declarecontents: write(andid-token: writewhere 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.