How to secure your GitHub Actions
summary
Covers concrete, actionable GitHub Actions security: how secrets leak in logs and via third‑party actions, why to pin commit SHA for actions, how self‑hosted runners expose network and persisted caches so never use self-hosted runners for public repos, and why to fork actions into your org and run a sync/verification workflow. Demos a fork‑updater bot and shows repo/org settings (allowlist, verified creators, secret scopes). Watch if you need step‑by‑step controls you can implement today; skip if you only want high‑level theory.
AI-written summary · about
chapters (25)
- 0:00GitHub Actions Security
- 1:54What are GitHub workflows?
- 2:57Workflow example
- 4:50Repository security
- 5:04Code - Who has access?
- 7:16Configuring access
- 7:39From the user
- 8:31Workflow secrets
- 10:04Who has access to your secrets?
- 14:57Your code - Best practices
- 16:16Your code/repo – trace changes (org level)
- 20:01Self-hosted runners
- 20:42Self hosted runners
- 22:18Workflow Runners Security
- 22:58Best practice: Run the action inside of a container
- 24:42Persisting data between runs
- 25:47Workflow runners - Best practice
- 29:13Protective measures
- 36:03Recommendation
- 37:26Forking actions
- 39:49Enable DevOps teams to test actions
- 41:31Staying up to date
- 42:45Create an update process yourself
- 43:11Automate the update Use a workflow
- 50:09Best practices summarized
related talks
56mHow to use GitHub Actions with Security in mind
45mGitHub Actions & Security
15mGitHub Actions: a time bomb for supply chain security
55mBeyond the Commit: Weaponizing and Hardening GitHub Actions
57mGitHub Actions: A Cloudy Day for Security
32mHacker Traction Through GitHub Actions: Is Your (Open Source) Project Safe?
42mProtecting CI/CD from malicious deploys
43mGitHub Actions Best Practices