Getting started with GitHub Actions: CI/CD pipelines and security

Read this page in French

Before creating your first workflow, let us take the time to understand what a CI/CD pipeline is, how GitHub Actions works, and above all why security has to be your priority from day one.

What is a CI/CD pipeline?

Picture yourself working on an application. On every code change, you have to:

1. Check that the code compiles and that the tests pass
2. Build the application (an executable, a Docker image, and so on)
3. Deploy it to an environment (staging, production, and so on)

Doing all of that by hand is slow, repetitive and error-prone. A CI/CD pipeline automates those steps.

What does CI/CD stand for?

• CI (Continuous Integration): on every change, the code is tested and integrated automatically. Bugs surface very early.
• CD (Continuous Delivery/Deployment): validated code is automatically prepared for, or pushed to, the target environments.

The idea is small frequent changes, validated automatically, rather than large risky releases once a month.

GitHub Actions: the engine behind your pipelines

GitHub Actions is the CI/CD service built into GitHub. When something happens on your repository (a push, a pull request, a release), GitHub Actions can run tasks automatically.

Concretely:

1. An event triggers the pipeline (you push code)
2. A workflow defines what to do (test, build, deploy)
3. A runner executes the tasks (a virtual machine provided by GitHub)
4. A result comes out (success or failure, artifacts, a deployment)

Why security comes before everything else

This is not optional

A CI/CD pipeline has access to your secrets (API tokens, passwords), your source code, and often your production environments. One configuration mistake can expose your whole system.

Attacks on CI/CD pipelines have exploded. In March 2025, a compromised GitHub action (tj-actions/changed-files) made it possible to exfiltrate the secrets of thousands of repositories within hours. The attack covered every version from v1 to v45, including the ones considered "stable".

The problem with mutable tags

When you write uses: actions/checkout@v4, you are trusting a Git tag. But a tag can be moved at any time by the maintainer.

Here is what can happen:

1. You use actions/checkout@v4 in your workflow
2. The action works perfectly for months
3. An attacker compromises the maintainer's account
4. They move the v4 tag to point at malicious code
5. Your next pipeline runs the attacker's code, without you changing anything at all

That is exactly what happened with tj-actions/changed-files.

The fix: pin by SHA

A SHA (Secure Hash Algorithm) is the cryptographic fingerprint of a commit. Unlike a tag, it is immutable: it cannot be changed without changing the hash itself.

# ❌ DANGEROUS: a mutable tag
- uses: actions/checkout@v4

# ✅ SECURE: a pinned SHA
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

The # v4.1.1 comment keeps a readable trace of the matching version. Tools such as Renovate or Dependabot update those SHAs automatically while preserving the comment.

The three security reflexes

Adopt these practices from your very first workflow.

1. Pin the actions by SHA

# Always use the full SHA, never the tag
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

2. Declare minimal permissions

# By default, a workflow has FAR too many permissions
# Restrict them explicitly to what is strictly needed
permissions:
  contents: read  # Read-only on the code

3. Never print a secret into the logs

# ❌ DISASTER: the secret shows up in the logs
- run: echo "Token: ${{ secrets.API_TOKEN }}"

# ✅ Secrets stay masked when they are used correctly
- run: curl -H "Authorization: Bearer ${{ secrets.API_TOKEN }}" https://api.example.com

You will learn all of this in detail

These concepts appear here so that you understand why they matter. The guide Security: the basics shows you how to apply them concretely.

Your first workflow

Now that you understand the stakes, here is a secure workflow for a Python API:

.github/workflows/ci.yml

name: CI Pipeline

# Minimal permissions, declared at workflow level
permissions:
  contents: read

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      # Actions pinned by SHA
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

      - name: Install Python
        uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b # v5.3.0
        with:
          python-version: '3.12'

      - name: Install the dependencies
        run: pip install -r requirements.txt

      - name: Run the tests
        run: pytest

This workflow:

• declares permissions: contents: read to limit what it can reach;
• uses SHAs instead of tags for its actions;
• does exactly what it is meant to do, testing the code.

The key concepts

Before going further, here is the essential vocabulary:

Term	Definition	Example
Workflow	A YAML file describing your pipeline	.github/workflows/ci.yml
Job	A group of tasks running on the same machine	test, build, deploy
Step	An individual task inside a job	"Install Python", "Run pytest"
Runner	The machine (VM) that executes the job	ubuntu-24.04, windows-2025
Action	A reusable component, like a library	actions/checkout, actions/setup-python
SHA	The unique, immutable identifier of a commit	b4ffde65f46336ab88eb53be808477a3936bae11

Glissez pour voir

Jobs versus steps

A job runs on its own virtual machine. Several jobs can run in parallel on different machines.

The steps of a single job run sequentially on the same machine. They share the same filesystem.

What you will learn

This Foundations module gives you the basics to build and understand your first workflows safely:

What is a workflow? File structure, location, and the anatomy of a workflow

Security: the basics Permissions, SHA pinning, protection against injections

Managing secrets Where to store your passwords, tokens and variables

The GitHub Actions Marketplace Understand the Marketplace, evaluate third-party actions, build the right reflexes

Next steps

You now understand what a CI/CD pipeline is and why it helps, how GitHub Actions fits into your development workflow, why security belongs in the picture from day one, and the three essential reflexes: SHA, permissions, secrets.

• What is a workflow?: the file structure, and your first working pipeline.
• Security: the basics: how to apply the three reflexes concretely.
• Securing GitHub Actions: the full security module, once the basics are in place.

×

📖 Voir la documentation →