GitHub Actions runs your code with elevated privileges: access to your
secrets, write rights on the repository, the ability to publish packages. This
section explains how the platform works, what it costs, and above all how to
secure it, from the GITHUB_TOKEN permissions to provenance attestations.
The English pages focus on security, the part that is most often treated
last and where the real incidents happen.
What is GitHub Actions?
GitHub Actions is the CI/CD (continuous integration and continuous delivery) automation platform built natively into GitHub. Launched in 2019, it runs code automatically in response to events on your repository.
Concretely, GitHub Actions lets you:
- Automate the tests: on every push or pull request, your tests run by themselves
- Build and publish: compile your code, create Docker images, publish to npm or PyPI
- Deploy: push automatically to AWS, Azure, GCP, Kubernetes, or your own infrastructure
- Maintain your code: check the formatting, analyse the security, update the dependencies
- Orchestrate tasks: schedule recurring actions, react to issues or releases
How does it work?
Everything rests on workflows: YAML files placed in the .github/workflows/
directory of your repository. Each workflow defines:
- When to run (push, pull request, schedule, manually, and so on)
- What to do (a series of tasks called jobs and steps)
- Where to do it (on virtual machines called runners)
# A minimal workflow examplename: Tests
on: [push, pull_request]
jobs: test: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 - run: npm testWhen you push code, GitHub detects the workflows automatically, provisions a virtual machine, runs your tasks, and shows the results in the interface.
The Marketplace: an ecosystem of actions
One of the strengths of GitHub Actions is its Marketplace: thousands of ready-made actions built by the community and by vendors. Rather than rewriting the logic to "deploy to AWS" or "send a Slack notification", you use an existing action.
But be careful: using an action means running third-party code with access to your secrets. The security of your pipeline depends on the trust you place in those actions. That is why this section insists on SHA pinning and on verifying the sources.
What does it cost?
GitHub Actions is free in two situations that cover a large share of real usage: public repositories on standard runners, and self-hosted runners, whatever the visibility of the repository. Everything else draws on a monthly included quota, then bills per minute.
| Plan | Included minutes per month |
|---|---|
| GitHub Free | 2,000 |
| GitHub Pro | 3,000 |
| GitHub Team | 3,000 |
| GitHub Enterprise Cloud | 50,000 |
Beyond the quota: a price per machine
The old multiplier model (a Windows minute counted twice, a macOS minute counted ten times) has disappeared from the GitHub documentation, replaced by a per-SKU price list. Each runner type now carries its own per-minute rate:
| Standard runner | Price per minute |
|---|---|
| Linux 2-core (x64) | $0.006 |
| Linux 2-core (arm64) | $0.005 |
| Windows 2-core (x64) | $0.010 |
| macOS 3 or 4-core | $0.062 |
The order of magnitude has not changed, a macOS minute still costs roughly ten times a Linux minute. What changed is the reading: the price is read directly, and the same list covers the larger runners (4 cores and above) and the GPU runners, billed significantly more.
The escape hatch: self-hosted runners
Self-hosted runners (machines you manage yourself) consume no minute of the GitHub quota, and using Actions on them is free. It is the economical option for large volumes or specific needs (GPU, internal network). The trade-off is not financial but security-related: you inherit the isolation, the hardening and the lifecycle of those machines.
Following your consumption
Go to Settings, then Billing and plans, then Plans and usage to see your current consumption. You can also configure alerts to avoid surprises.
For open source projects, everything is free and unlimited. That is one of the reasons GitHub Actions became the de facto standard for open source CI/CD.
Why this course?
You have a GitHub project. With every change, you run the tests by hand, you deploy by copying files, you check manually that nothing is broken. That lost time adds up, and human errors end up slipping through.
GitHub Actions solves this problem. But GitHub Actions is not just about "running the tests automatically". It is a powerful tool that, badly mastered, can become a source of technical debt, security flaws and workflows nobody can maintain.
The 2025-2026 incidents make the case better than any argument. The compromise
of tj-actions/changed-files, an action used by more than 23,000
repositories, copied the secrets of the workflows running it into their
public logs. GhostAction stole 3,325 secrets across 817 repositories.
Shai Hulud v2 spread to 796 npm packages. And on the night of 1 March 2026,
the Trivy repository was wiped after an autonomous AI bot exploited a
vulnerable workflow.
None of those attacks needed an unknown flaw (zero-day). They walked through
doors you control: a badly secured pull_request_target, mutable tags,
excessive permissions, command injection and uncontrolled network egress.
Each case is detailed in the
analysis of the attacks.
This course takes you from the first workflow to a secure, professional-grade CI/CD. No shortcuts, no blind copy-pasting: you will understand each concept so you can make the right decisions.
Prerequisites
To follow this course you need a GitHub account (free), the basics of Git (clone, commit, push, branches, pull requests), and to be comfortable with the command line.
No prior CI/CD experience is required. We start from zero and build up step by step.
What you will be able to do at the end
By the end of this course, you will be able to:
Build workflows. You will master the YAML syntax, the triggering events, the execution conditions and the parallelisation strategies. Your workflows will be readable, maintainable and fitted to your real needs.
Secure your pipelines. This is the heart of the course. You will learn to set minimal permissions, pin actions by SHA, use OIDC to avoid static secrets, and understand the risks of pull requests from forks. You will know how to audit an existing workflow and spot its flaws.
Optimise performance. You will know how to use the cache wisely, share artifacts between jobs, and cut minutes off your pipelines' run time. Every second counts while you wait for your tests' feedback.
Manage runners. You will understand the difference between GitHub-hosted and self-hosted runners, when to use each, and how to secure your execution infrastructure. You will know how to set up ephemeral runners for sensitive environments.
The course path
The course follows a logical progression. Each module builds on the previous ones to grow your skills step by step, from the first workflow to the hardened pipeline and its runners.
Write your first workflow
What is a workflow? Where does it go? How does it work?
The structure of the YAML files, the triggering events, secrets management, and the first security reflexes set from the start.
Design dynamic workflows
Contexts, conditions, matrices, reusable workflows
Test several versions in parallel, factor a CI that adapts to the branch and the event, create composite actions.
Defend the supply chain
The heart of the course
Real attacks, SHA pinning, zizmor and poutine, minimal permissions, OIDC, provenance attestations and runner hardening.
Lab: a hardened pipeline end to end
Five workshops on a reproducible public repository
Governed bootstrap, CI with zero findings, SLSA-attested build signed with Cosign, branch ruleset, then an OpenSSF Scorecard score taken apart.
Deliver: environments and deployments
A green CI is no licence to deploy
Environments, human approval, promoting an artifact by digest, releases and GHCR images, rollback and concurrency.
Speed up, then choose your runners
Cache, artifacts, concurrency, then the execution infrastructure
Diagnose a slow pipeline, cut useless runs, then decide between hosted and self-hosted runners, up to ephemeral runners.
Key points
What this page sets up is less a list of features than a priority: security is learned from the first workflow, because that is where the incidents begin.
- A workflow is a YAML file in
.github/workflows/that says when to run, what to do and where. - Public repositories and self-hosted runners run for free; everything else draws on a monthly quota.
- The 2025-2026 attacks used no zero-day: they walked through five doors you control.
- Those doors are
pull_request_target, mutable tags, broad permissions, command injection and uncontrolled egress. - The fastest first step is the security checklist: fifteen minutes on your own workflows.
FAQ: frequent questions
These questions come back constantly, from the first workflow to the first security audit.
.github/workflows/ directory at the root of your repository. The files must carry the .yml or .yaml extension. GitHub picks up every file in that directory automatically.permissions:, pin actions by full SHA rather than by tag, never store secrets in the code, use environments with approval for production, and avoid pull_request_target unless you understand the risks.@v4 are mutable: the maintainer can change them at any moment. If the action is compromised, your workflow will run malicious code. A full SHA such as @11bd71901bbe5b1630ceea73d27597364c9af683 points at one exact, immutable version of the code.actions/upload-artifact and actions/download-artifact actions. Each job runs on a different machine, so files are not shared automatically. Artefacts are kept for 90 days by default.ubuntu-latest point at a version that changes without warning when GitHub updates its runners. One day your workflow works, the next it breaks. Use an explicit version such as ubuntu-24.04 for reproducible builds.workflow_dispatch trigger to the on: section of your workflow. That adds a 'Run workflow' button in the GitHub Actions interface. You can also define inputs to pass parameters at launch time.${{ secrets.SECRET_NAME }} syntax. GitHub masks secrets in the logs automatically with ***.act tool, which simulates GitHub Actions on your machine with Docker. Be aware that not every feature is supported (notably GitHub secrets, some events, and the macOS and Windows runners).actions/cache, run jobs in parallel where possible, filter the triggers with paths: to avoid useless runs, and configure concurrency to cancel obsolete runs.pull_request_target trigger bypasses it and must be used with care.