Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Actions pinnés par SHA - dependabot

Date de l'article:18-12-2025
CI/CD Github-Actions
Remplacement des tags mutables des GitHub Actions par leurs SHA de commit pour sécuriser la supply chain, Nous ferons la configuration de Dependabot pour les mises à jour automatiques
INFO PROJET
App Spring Boot : Flashcards - readme CI
Docker Image Hub
Qualité/couverture: sonarCloud projectSonarQube Cloud
Sécurité Supply Chain et tags mutables

Les attaques de supply chain ciblent le pipeline CI/CD et ses dépendances

Un vecteur courant est l'usage de tags mutables comme @v1 ou latest dans les workflows, qui peuvent être redirigé vers un commit malveillant, entraînant ainsi l'exécution de code compromis

Éviter @v6.0.1 ou latest et les tags majeurs

Épingler les versions par SHA (référence immuable: SHA commit)
     ou digest d'image
Configurations des fichiers et mise en place: Actions pinnés par SHA

GitHub Actions encourage l'utilisation d'actions de son marketplace, qui sont des composants réutilisables permettant d'automatiser des tâches spécifiques

Process example avec l'action checkout

Pour chaque action, on se rends sur le lien Github de l'action: actions/checkout, ici l'action est de récupérer le repository.
On parcours le readme, on regarde les màj et la version qui nous corresponds. Pour l'instant, la dernière version est la v6.0.2

→ Pour obtenir le SHA court, on clique sur " Tags" (ou release),
→ cliquez ensuite sur le lien du SHA court, représenté comme suit: de0fac2.
→ Dans la page suivante, le SHA long apparait dans l'url: https://github.com/actions/checkout/commit/de0fac2e4500dabe0009e67214ff5f5447ce83dd:
→ en vert, la partie qu'il faut remplacer dans les actions des pipelines:

Dans le pipeline:
Remplacez la version v6.0.2 
steps:
- name: Checkout code
  uses: actions/checkout@v6.0.2
Par le SHA long, comme ceci: 
steps:
- name: Checkout code
  uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
Ajouter la version en commentaire est aussi une bonne pratique. Pour vous, mais aussi, lors de la mise à jour, Dependabot modifie également le commentaire
Configurer Dependabot

Utiliser des SHA rend la mise à jour manuelle pénible. La solution standard est d'utiliser le Dependabot de GitHub

doc officielle : dependabot-quickstart-guide | demo example : dependabot-demo

Ajout du fichier .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

Configuration complète (couvre les workflows, le Dockerfile et les dépendances Java)
Le contenu du fichier dépend uniquement de ce que l'on veut surveiller
     Il suffit d'ajouter, par exemple; - package-ecosystem: "github-actions",
     de lui donner le chemin d'accès, et l'interval à suivre pour qu'il s'occuppe de tout, où presque

Centralisation: Dependabot n'utilise qu'un seule fichier
     Il scanne tous les fichiers yaml, situés dans le dossier .github/workflows/

Automatisation des SHA: Dependabot détecte si une nouvelle version existe,
     Il crée ensuite une PR (de plusieurs fichiers parfois) en mettant à jour le(s) SHA,
     Il ajoute un commentaire avec le(s) numéro(s) de version

Stabilité: On recoit les mises à jour sur une branche séparée.
     On peut ainsi tester les mises à jourt AVANT de les merger dans les différentes branches

Le fichier "Dockerfile"

Utiliser un SHA pour l'image de base, c'est comme pour les Actions;
On utilise un SHA pour le FROM afin d'être 100% reproductible

Dans ce cas, il va surveiller la ligne FROM gcr.io/distroless/java17-debian12 et proposer une "Pull Request" dès qu'une nouvelle image de base, plus sécurisée, sera publiée par Google

Une fois que l'on à le SHA, modifiez le Dockerfile ainsi:
FROM gcr.io/distroless/java17-debian12@sha256:le_sha_ici

Tester avant de procéder au changement

Avant d'accepter les changements, il est impératif de les tester!

Avec Docker

Récupérer la dernière version de l'image:
docker pull gcr.io/distroless/java17-debian12

Afficher le SHA exact (le Digest)
docker inspect --format='{{index .RepoDigests 0}}' gcr.io/distroless/java17-debian12

Avantage majeur : Si Google pousse une mise à jour qui casse l'application, le build ne bougera pas car il est "verrouillé" sur le SHA spécifiquement configuré
Le scan Maven

Pour Java, c'est encore plus puissant:
Dependabot analyse le fichier pom.xml. Si on mets à jour une dépendance, il vérifie les versions disponibles sur Maven Central. Il regroupe les mises à jour si on utilise l'option groups, ce qui évite d'avoir 50 PRs ouvertes

optimizing-java-packages-dependabot

Le regroupement réduit le "bruit" des Pull Requests en fusionnant plusieurs mises à jour liées, en une seule PR

Efficace pour les frameworks comme Spring où les dépendances doivent souvent être mises à jour simultanément pour éviter les conflits de version
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      production-dependencies:
        patterns: ["*"]
        dependency-type: "production"
      minor-and-patch:
        update-types: ["patch", "minor"]
Configuration des secrets

Si vos workflows contiennent des secrets, il faudra les configurer ou les copier dans la section spécifique au secrets dependabot:

settings → secrets/dependabot

C'est la condition pour qu'il puisse tourner la CI dans les PR
Dependabot secrets
Secrets are credentials that are encrypted. Anyone with collaborator access to this repository can use these secrets for Dependabot.

Secrets are not passed to forks.
Repository secrets                     
Name                    Last updated
 POSTGRES_PASSWORD     2 days ago
Tableaux de bords des mise à jour
Depuis l'onglet Insights → Dependencies graph où nous avons 3 tabs:
  • Dependencies: Contient une liste de dépendance, On peut filtrer par eco-system (Maven, Github Actions), on peux aussi activer la soumission automatique afin de recevoir des alertes Dependabot pour les vulnérabilités connues
  • Dependents:
  • Dependabot: Affiche les récentes mise à jour et les fichiers modifiés
Tableaux de bords des alertes
On voit les notifications d'alertes depuis le projet, onglet Security 1 Cliquez sur Dependabot dans le menu de gauche pour accéder aux alertes: 
Vulnerability Alert
       Dependabot 1
Dependabot alerts
Dependency files checked 6 hours ago

 is:open

 Apache Tomcat Vulnerable to Improper Resource Shutdown or Release   Low 
#1 opened 2 days ago • Detected in org.apache.tomcat.embed:tomcat-embed-core (Maven) • pom.xml    #132
Process de mise à jour CI/PR
D'une part, on recoit un email nous avertissant d'une mise à jour mais on peux aussi le remarquer, au dessus de l'onglet pull requests
Cibler la branche

Pour ma stratégie Git, les alertes de mise à jour sont envoyés sur la branche [develop], idéale pour suivre le cycle normal des PR/merges

version: 2
updates:
  - package-ecosystem: "github-actions"
    target-branch: develop
    directory: "/"
    schedule:
      interval: "weekly"

    groups:
      github-actions:
        patterns:
          - "*"
Déroulé du PR: CI FAILED

Contexte:
Le build est rouge et on a fermé le PR, on reçoit alors un message avec des instructions: →

On peut aussi configurer le fichier pour n'autoriser que les versions majeurs: 
groups:
  major-and-patch:
    update-types: ["patch", "major"]
Email notification: 
Bump org.apache.tomcat.embed:tomcat-embed-core from 10.1.45 to 10.1.47 (PR #132)
dependabot[bot] left a comment : 

OK, I won't notify you again about this release, 
but will get in touch when a new version is available. 

If you'd rather skip all updates until the next major or minor version, 
let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.
Déroulé du PR: CI SUCCESS
Une CI verte enclenche le processus de merge habituel
(develop → staging → main)

PR green → merge (develop)
Point important
     La mise à jour de certaines actions CI/CD (dependabot) sont succeptible d'engendrer des modifications dans les workflows, images et/ou le code,
     Le repository constitue dès lors, La source de vérité
Dans l'article suivant, nous verrons comment améliorer le Dockerfile, nous parlerons aussi du Dockerfile.debug et ce qu'il peux nous apporter.
      Enfin nous verrons comment Actuator peux nous aider encore + à diagnostiquer les problèmes (à défaut de ne pouvoir entrer dans le container)
Mise en place d'un pipeline CI/CD (4/4) - La branche main (final) Automatisation des PR (promotions de branches)
Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.