GitHub Actions & Security
summary
Concrete takeaways and concrete risks: workflow secrets are injected into runs and can be exfiltrated if a step prints or mangles them so treat secrets as public and rotate short‑lived keys; self‑hosted runners expose network, disk and cache risks so use GitHub‑hosted runners for public repos or run steps in containers; most code comes from dependencies (about 70% third‑party and 99% of delivered code not written in repo), so pin actions by commit SHA and fork and vet actions into an org and automate updating those forks.
AI-written summary · about
chapters (24)
- 0:00Intro
- 1:32What are GitHub workflows?
- 2:54Workflow example
- 4:00GitHub Actions Security
- 4:29Repository security
- 6:07Workflow secrets
- 8:02Who has access to your secrets?
- 17:25Best practice:Run the action inside of a container
- 19:26Persisting data between runs
- 20:55Workflow runners - Best practice
- 24:52Protective measures
- 31:16Recommendation
- 31:50Workflow attack vectors
- 32:06Forks of public repos
- 34:40Common fields
- 35:50Remediation
- 36:34Forking actions
- 37:58Staying up to date
- 38:19Update action versions
- 40:07Keep your forked action up to date
- 41:03Review before merging
- 41:16Automation
- 41:52Pros of forking
- 43:04Best practices summarized
related talks
56mHow to use GitHub Actions with Security in mind
51mHow to secure your GitHub Actions
15mGitHub Actions: a time bomb for supply chain security
52mGitHub Actions Security: From CI Nightmare to Supply Chain Sentinel
57mGitHub Actions: A Cloudy Day for Security
43mGitHub Actions Best Practices
55mBeyond the Commit: Weaponizing and Hardening GitHub Actions
41mSecuring Self-Hosted GitHub Actions with Kubernetes & Actions-Runner-Controller