Veille sécurité CI/CD : post-quantum, signatures et correctifs critiques (janvier 2026)

Stéphane Robert DevOps Engineer

Publié le 23 janvier 2026

Glossaire : activé

15 min de lecture

Depuis l’affaire tj-actions/changed-files et les compromissions en cascade de mars 2025, j’ai fait de la sécurité de la supply chain un fil rouge permanent sur ce site. Chaque semaine, je surveille les changelogs des outils que nous utilisons tous les jours dans nos pipelines.

Cette veille n’est pas un exercice académique : c’est une hygiène de base quand on automatise des déploiements. Un outil de build non patché, un vérificateur de signatures vulnérable, ou un chiffrement obsolète peuvent transformer votre pipeline en vecteur d’attaque.

Ce billet couvre les mises à jour importantes de janvier 2026 : chiffrement post-quantum avec age, correctif de sécurité pour cosign, patches CVE pour Buildah et BuildKit, et durcissement curl.

TL;DR — Priorités lundi matin

• P0 (priorité opérationnelle) : cosign → vulnérabilité sur la vérification offline (bundles / anciens formats)
• P1 (important) : curl 8.18.0 → CVE dont fuite de token Bearer via redirections cross-protocol (durcissement recommandé)
• P1 (important) : Buildah → CVE-2025-47913 dans golang.org/x/crypto (risque principal : DoS selon exposition SSH agent)
• P2 (planifier) : age 1.3.0 → migration post-quantum pour secrets long-terme
• P3 (suivi) : BuildKit 0.27.0 → images signées, pinner au digest

Outil	Version	Sévérité (advisory)	Suis-je concerné ?	Action
cosign	3.0.4	Moderate	Vérification offline avec bundles / anciens formats	Upgrader + auditer le chemin offline
curl	8.18.0	Mix (Low→Medium)	Pipelines curl (redirections) + outils libcurl (LDAP/IMAP/SMTP/…)	Mettre à jour + durcir
Buildah	1.38+	Important	Images builder avec Buildah/Podman + usage SSH/agent	Reconstruire images
age	1.3.0	Migration	Secrets > 5 ans de durée de vie	Planifier migration PQ
BuildKit	0.27.0	Amélioration	Pinning frontend Dockerfile	Pinner au digest + vérifier signature

Glissez pour voir

Pourquoi cette veille est devenue indispensable

Les pipelines CI/CD sont devenus le système nerveux de nos infrastructures. Ils concentrent :

• Les secrets (credentials cloud, tokens API, clés SSH)
• Les droits d’écriture sur les registres et les dépôts
• Le pouvoir de déployer automatiquement en production

Un seul composant compromis dans cette chaîne peut avoir des conséquences dévastatrices. C’est pourquoi je maintiens une vigilance constante sur les outils qui touchent à la signature, au chiffrement et au build.

1. age v1.3.0 : le chiffrement entre dans l’ère post-quantum

Six ans après sa première bêta, age franchit un cap majeur : la version 1.3.0 introduit la résistance post-quantum.

Qu’est-ce que le post-quantum ?

Les ordinateurs quantiques, quand ils seront assez puissants, pourront casser les algorithmes de chiffrement asymétrique actuels (RSA, courbes elliptiques) en quelques heures. Le chiffrement post-quantum utilise des algorithmes mathématiques résistants à ces attaques.

Pourquoi c’est important maintenant ?

Même si les ordinateurs quantiques capables de casser nos chiffrements ne sont pas encore là, les attaquants peuvent capturer vos données chiffrées aujourd’hui et les déchiffrer plus tard. C’est l’attaque “harvest now, decrypt later”.

Si vous chiffrez des secrets avec une durée de vie longue (backups, archives, credentials), le post-quantum devient pertinent dès maintenant.

Migration ciblée, pas généralisée

Le chiffrement post-quantum a un coût : clés et ciphertexts plus volumineux, performances légèrement inférieures. Réservez la migration PQ aux secrets avec une durée de vie > 5 ans. Pour vos secrets éphémères (tokens de déploiement, sessions), les clés age1... classiques restent parfaitement appropriées.

Ce qui change dans age 1.3.0

# Nouveau format d'identité post-quantum
AGE-SECRET-KEY-PQ-1...

# Nouveau format de recipient post-quantum
age1pq1...

# Vérifier si un fichier utilise le chiffrement PQ
age-inspect fichier.age
# Affiche : post-quantum encryption, payload size, recipient types

Autres nouveautés :

• Support natif des plugins hardware (YubiKeys via PIV)
• Fichiers age chiffrés utilisables comme fichiers d’identité
• Proxy de déchiffrement vers des machines distantes (agent)

Action concrète

1. Mettre à jour age sur vos runners CI et postes d’administration

   brew upgrade age
   age --version

2. Tester la compatibilité avec vos workflows existants

   age -d -i key.txt secrets.age

3. Planifier la migration vers les clés post-quantum pour les secrets à longue durée de vie

Lien : age v1.3.0 release notes

SOPS et les clés post-quantum

Si vous utilisez SOPS pour chiffrer vos secrets, vérifiez le support des clés post-quantum (age1pq1...) avant migration.

En attendant, vous pouvez :

• garder SOPS sur des clés age1... (compatibles avec age 1.3.0),
• réserver les clés post-quantum aux archives/backups long-terme hors SOPS.

2. cosign v3.0.4 : correctif de vulnérabilité dans la vérification offline

Cosign est l’outil de référence pour signer et vérifier vos images conteneurs. La version 3.0.4 corrige une vulnérabilité qui concerne principalement la vérification offline.

La vulnérabilité (bundle/offline)

Un bundle Cosign pouvait être fabriqué pour valider une signature même si l’entrée Rekor embarquée ne référençait pas le bon digest. En d’autres termes : dans certains cas, un attaquant pouvait contourner la vérification d’intégrité lorsque vous faites une validation à partir d’un bundle.

Qu'est-ce qu'un bundle Cosign ?

Un bundle Cosign est un fichier JSON qui regroupe les preuves cryptographiques d’une signature : certificat Fulcio, signature, et entrée Rekor (log de transparence). Ce format permet de vérifier une signature offline, sans interroger Rekor.

Sévérité et priorité

• La sévérité de l’advisory est moderate.
• Priorité opérationnelle P0 si vous dépendez de la vérification offline (air-gapped, policies K8s basées sur bundles, vérification sans accès Rekor, anciens bundles).

Suis-je concerné ?

Vous êtes potentiellement exposé si :

• vous utilisez cosign verify avec --bundle (vérification offline),
• vous avez des bundles générés avec des versions anciennes (anciens formats),
• vous utilisez un trusted_root.json personnalisé.

Action concrète

1. Upgrader cosign sur tous les runners CI

   brew upgrade cosign
   cosign version

2. Tester la vérification de vos images signées

   cosign verify ghcr.io/mon-org/mon-app@sha256:abc123 \
     --certificate-identity-regexp="^https://github.com/mon-org/" \
     --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

3. Auditer vos workflows qui utilisent des bundles

   grep -R "cosign verify" . -n | grep bundle || true

Lien : cosign v3.0.4 release notes

Priorité P0 si offline

Si vous vérifiez des signatures en offline (bundles) dans des clusters Kubernetes (kyverno / policy controller) ou en environnement contraint réseau, cette mise à jour est prioritaire.

3. Buildah : patches CVE sur les dépendances runtime

Buildah a publié plusieurs releases qui corrigent des vulnérabilités dans ses dépendances critiques.

Ce qui est patché

• CVE-2025-47913 : vulnérabilité dans golang.org/x/crypto/ssh/agent — un pair peut provoquer une panic côté client dans certaines conditions. Risque principal : déni de service (interruption de jobs) selon exposition.
• CVE-2025-47914 : vulnérabilité complémentaire côté agent.
• Mises à jour de runc (runtime conteneur)
• Correctifs de conformité OCI

Périmètre des CVE

Ces CVE sont dans des dépendances Go embarquées par Buildah via son go.mod. L’exposition dépend de la version réellement présente dans votre installation.

Pour les images de builder custom : mettez à jour Buildah et reconstruisez les images.

Impact en CI/CD

Dans les environnements où des agents SSH opèrent via des sockets forwarded, des workspaces partagés ou des runners CI/CD, le risque se matérialise souvent en DoS (jobs qui plantent, pipelines qui s’arrêtent).

Si vos builds clonent des dépôts Git privés via SSH et utilisent un agent forwardé, vous êtes plus exposés.

Où Buildah peut être présent

Buildah n’est pas toujours visible directement. Il peut être embarqué dans :

• vos images de builder sur les runners CI
• les environnements de développement avec Podman

Action concrète

1. Inventorier où Buildah est installé

   which buildah && buildah version
   
   docker run --rm mon-builder buildah version

2. Mettre à jour vers la dernière version patchée

   dnf update buildah || true
   apt update && apt install -y buildah || true

3. Reconstruire vos images de builder si Buildah y est embarqué

Lien : Buildah releases

4. BuildKit / Dockerfile frontend 1.21.0 : images signées

BuildKit est le moteur de build moderne de Docker. La release v0.27.0 (et le frontend Dockerfile 1.21.0) apporte des évolutions importantes pour la sécurité du build.

Ce qui change

• Images de release signées : les images officielles BuildKit et les frontends sont désormais signées (meilleure vérification de provenance)
• Ajustements du parsing / linting Dockerfile
• Améliorations de la gestion des secrets pendant le build

Rappel : le build est une surface d’attaque

Votre pipeline de build est un endroit privilégié pour injecter du code malveillant. Un Dockerfile compromis, une image de base vérolée, ou un frontend altéré peuvent contaminer tous vos artefacts.

Action concrète

Si vous pinnez un frontend dans vos Dockerfiles :

1.21.0

FROM alpine:3.21
...

Revalidez votre stratégie de pinning. Recommandation : pinner au digest, pas seulement au tag, et vérifier la signature dans votre CI :

crane digest docker/dockerfile:1.21.0
# sha256:abc123...

# syntax=docker/dockerfile@sha256:abc123...

cosign verify docker/dockerfile@sha256:abc123... \
  --certificate-identity-regexp=".*" \
  --certificate-oidc-issuer-regexp=".*"

Lien : BuildKit v0.27.0 release notes

5. curl 8.18.0 : CVE corrigées et risques supply chain

curl (et surtout libcurl) est omniprésent dans nos images de build et nos outils d’automatisation.

Point important : curl CLI vs libcurl

Toutes les vulnérabilités annoncées n’impactent pas nécessairement le binaire curl.

• Certaines touchent libcurl dans des contextes applicatifs (LDAP/IMAP/SMTP, multi-handle, etc.).
• D’autres concernent directement des patterns dangereux en CI (ex : redirections permissives, scripts téléchargés).

CVE-2025-14524 : la fuite silencieuse de tokens (à traiter côté CI)

Quand curl suit une redirection cross-protocol (par exemple HTTP → IMAP/LDAP/POP3/SMTP), il peut transmettre le bearer token OAuth2 au nouveau protocole.

Dans un pipeline, ça peut devenir une fuite de token si un endpoint malveillant force une redirection.

Durcir l’usage de curl en CI/CD

1. Mettre à jour curl/libcurl sur runners et images de build

   curl --version | head -1
   apt update && apt install -y curl
   apk update && apk upgrade curl

2. Restreindre les protocoles autorisés (requêtes ET redirections)

   curl --proto '=https' --proto-redir '=https' --tlsv1.2 -sSfL https://example.com/script.sh

3. Vérifier les checksums avant d’exécuter des scripts téléchargés

   curl -sSL https://example.com/install.sh -o install.sh
   echo "a1b2c3d4...expected_sha256  install.sh" | sha256sum -c -
   bash install.sh

4. Auditer les usages de curl dans vos Dockerfiles et CI

   grep -r "curl.*|.*sh" . --include="Dockerfile*" --include="*.yml"

5. Préférer des sources signées quand elles existent

Le pattern curl | bash

Le pattern curl URL | bash est intrinsèquement dangereux : pas de vérification d’intégrité, pas de signature, exécution aveugle.

Si vous devez l’utiliser : téléchargez d’abord, vérifiez (checksum/signature), puis exécutez.

Liens : curl changes | curl security advisories

Automatiser cette veille

Surveiller manuellement les changelogs de dizaines d’outils n’est pas viable. Voici quelques approches :

1. Dependabot / Renovate : pour les dépendances déclarées (package.json, requirements.txt)
2. Scripts de veille : comparer les versions installées avec les releases GitHub
3. Alertes RSS : s’abonner aux feeds de releases des projets critiques
4. Outils de conformité : auditer vos pipelines à l’échelle

Ce qu’il faut retenir

1. Le post-quantum arrive : age 1.3.0 marque le début d’une transition importante (secrets long-terme uniquement)
2. La signature n’est pas infaillible : même cosign peut avoir des failles, d’où l’importance des mises à jour — priorité P0 si usage offline
3. Le build est une surface d’attaque : Buildah, BuildKit et leurs dépendances doivent être patchés régulièrement
4. curl/libcurl est un vecteur d’attaque : omniprésent, utilisé dans les patterns dangereux (curl | bash) — patchez et durcissez
5. Pinnez au digest, pas au tag : pour BuildKit et les frontends Dockerfile
6. La veille est un investissement : 30 minutes par semaine pour éviter des heures de remediation

Checklist lundi 9h

1. Inventaire versions

Lister les versions de cosign, curl/libcurl, Buildah, BuildKit sur vos runners CI

2. Upgrade cosign

Priorité opérationnelle : upgrade vers v3.0.4 et audit des chemins offline/bundles

3. Patch curl/libcurl

Mettre à jour sur runners et images builder, puis durcir les redirections/protocoles

4. Rebuild images

Reconstruire les images de build contenant Buildah/Podman (et valider les versions)

5. Audit curl | bash

grep -r "curl.*|.*sh" . --include="Dockerfile*" --include="*.yml"

6. Pin digests

Vérifier le pinning digest des frontends BuildKit et images critiques

7. Policies Kubernetes

Tester la vérification cosign dans kyverno/Policy Controller (cas offline inclus)

8. Planifier PQ

Identifier les secrets > 5 ans et définir une stratégie de migration post-quantum

Appliquer les patchs sans casser le delivery (analyse + mitigations)

Avant de patcher, classez chaque mise à jour selon l’exposition réelle, pas seulement le CVSS.

1) Analyse d’exposition (30 minutes)

• Runners partagés vs dédiés : priorité aux partagés (multi-tenant)

• Jobs déclenchés par PR/forks : surface d’attaque maximale (code non fiable)

• Présence de secrets : tokens registry, cloud creds, OIDC, SSH agent

• Usage réel du composant :

  • cosign : vérification offline/bundle ? anciens bundles ? trusted_root custom ?
  • curl/libcurl : redirections ? protocoles permissifs ? usages LDAP/IMAP/SMTP ?
  • Buildah : clone Git via SSH + agent forwardé ? images builder réutilisées ?

2) Déploiement par anneaux + rollback prêt

• Anneau 0 (canary) : 1 runner, 1 projet non critique, 24h
• Anneau 1 : 10–20% des runners, projets internes
• Anneau 2 : généralisation
• Plan N-1 : image builder précédente + variable de bascule

3) Mesures compensatoires si vous ne pouvez pas patcher immédiatement

• Réduire l’exposition des runners :

  • désactiver exécution sur forks / PR non approuvées
  • isoler réseau (egress minimal), limiter accès registry/SCM
  • limiter privilèges (rootless, cap drop, seccomp), runners dédiés

• Durcir les patterns à risque :

  • interdire curl | bash (ou imposer checksum/signature)
  • borner les protocoles : curl --proto '=https' --proto-redir '=https'
  • pinning au digest (images, frontends, actions)

4) Prouver la conformité (et gagner du temps à la prochaine alerte)

• Job CI “toolchain baseline” : versions cosign/curl/libcurl/buildkit/buildah imprimées et archivées
• Job “policy” : vérification signatures/provenance/digests (échec si non conforme)
• Ticket de changement : version avant/après + périmètre + résultat canary

Rappel

Si vous ne pouvez pas patcher immédiatement, documentez une mesure compensatoire (réduction des droits runner, segmentation, blocage forks, restriction réseau/protocoles) et planifiez un retour à l’état nominal.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui — ☕ offrir un café fait vraiment la différence.

☕Offrir un café

×

📖 Voir la documentation →