attempt to protect repo against GitHub Action Worms

[jhpoelen]

I just watched DEF CON 31 - The GitHub Actions Worm - Asi Greenholts - @asi-cider https://forum.defcon.org/node/246123 https://youtu.be/j8ZiIOd53JU and am now eager to lockdown my github repo configuration to reduce possibility of malicious GitHub Action Worms eating my code. Kudos to Asi Greenholts et al. 2023 for demonstrating how GitHub Actions can be hijacked and spread. @cboettig @mbjones @mielliott

[jhpoelen]

Added the following rulesets to preston repo -

{
  "id": 574272,
  "name": "disable force push",
  "target": "branch",
  "source_type": "Repository",
  "source": "bio-guoda/preston",
  "enforcement": "active",
  "conditions": {
    "ref_name": {
      "exclude": [],
      "include": [
        "~ALL"
      ]
    }
  },
  "rules": [
    {
      "type": "deletion"
    },
    {
      "type": "non_fast_forward"
    },
    {
      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": false,
        "require_code_owner_review": false,
        "require_last_push_approval": false,
        "required_review_thread_resolution": false
      }
    }
  ],
  "bypass_actors": []
}

and tag protection

{
  "id": 574283,
  "name": "protect tags",
  "target": "tag",
  "source_type": "Repository",
  "source": "bio-guoda/preston",
  "enforcement": "active",
  "conditions": {
    "ref_name": {
      "exclude": [],
      "include": [
        "~ALL"
      ]
    }
  },
  "rules": [
    {
      "type": "deletion"
    },
    {
      "type": "non_fast_forward"
    },
    {
      "type": "update"
    },
    {
      "type": "creation"
    }
  ],
  "bypass_actors": []
}

see also attached json.

Am open to suggestions . . .

protect tags.json disable force push.json

[jhpoelen]

Also, I've set the GITHUB_TOKEN permissions to be read-only by default.

before:

after:

[cboettig]

@jhpoelen thanks for sharing this, really appreciate it.

Do you know if there's any mechanism to 'bulk update' tokens in existing CI from the historic behavior of 'all permissions' to the new default read-only? I understand why they didn't want to push that change on users and break workflows that need permissions, but still, I have always been so puzzled why GitHub tokens have such vast permissions. I've never understood why GitHub tokens also get access to a "all the user's repos and organizations" by default? Is that still the case or can a token be scoped to a repo (or at least to an org?). Do you know how long GitHub tokens issued to CI are given before they expire?

I know the talk covered a lot of other issues, but the token thing seems the most universal secret here.

[jhpoelen]

@cboettig

Do you know if there's any mechanism to 'bulk update' tokens in existing CI from the historic behavior of 'all permissions' to the new default read-only?

Assuming that all actions available via the website are available via the GitHub API, I imagine that scripting the token permissions is possible, but haven't seen any big buttons to click. I've updated the permissions via point-and-click workflows provided by GitHub web interface.

Is that still the case or can a token be scoped to a repo (or at least to an org?). Do you know how long GitHub tokens issued to CI are given before they expire?

Not quite sure, I'd have to look. Perhaps others know more about this . . . I'd be curious to learn more.