Dans une approche GitOps, tout passe par le repo Git : les manifests Kubernetes, les configurations, et idéalement les secrets aussi. Mais comment gérer les secrets de manière sécurisée dans un repo Git ?

SOPS : Secrets OPerationS

Principe : chiffrement côté fichier

SOPS s’intègre aux KMS, par exemple sur GCP Cloud Key Management via le principe d’Envelope Encryption : il génère une clé symétrique éphémère (DEK) pour chiffrer les secrets, et délègue à GCP KMS le chiffrement de cette DEK.

Le KMS ne voit jamais les secrets eux-mêmes, et le fichier commité dans Git contient les valeurs chiffrées ainsi que la DEK chiffrée.

En local, un gcloud auth application-default login suffit alors qu’en production sur GKE il est plutot préférable d’utiliser le Workload Identity pour lier le ServiceAccount Kubernetes au compte de service GCP.

Chaque opération est enfin tracée dans Cloud Audit Logs.

Limitations

• Nécessite une infrastructure de gestion de clés externe (KMS ou PGP/Age). Cela introduit une dépendance sur AWS KMS, GCP KMS, etc.
• La rotation de clé implique de re-chiffrer tous les fichiers concernés (sops updatekeys).
• SOPS ne crée pas de Secret Kubernetes directement. Il faut un outil intermédiaire : Helm Secrets, ArgoCD avec plugin, Kustomize + plugin, ou un job de déchiffrement en pipeline CI/CD.
• Le déchiffrement se fait souvent dans le pipeline CI/CD ou sur le poste du développeur. La valeur en clair transite quelque part, ce qui élargit la surface d’attaque.
• Contrairement à Sealed Secrets + un opérateur GitOps, SOPS seul ne met pas à jour les secrets dans le cluster automatiquement.

C’est l’outil que j’ai le plus utilisé dans un contexte professionnel, je trouve que c’est un bon compromis pour gérer les secrets en GitOps à condition d’accepter la complexité de gestion des clés et de mettre en place les bonnes pratiques pour éviter les erreurs humaines (ex: commit de secrets en clair) qui spoiler finiront par arriver

SOPS + ArgoCD

Sops s’intègre très bien avec ArgoCD via le plugin argocd-vault-plugin.

Sinon il est aussi possible d’installer Helm Secrets comme Config Management Plugin.

Exemple d’utilisation

# Chiffrer un fichier de secrets
sops -e secrets.yaml > secrets.enc.yaml
# Déchiffrer un fichier de secrets
sops -d secrets.enc.yaml > secrets.yaml
# Mettre à jour les clés de chiffrement
sops updatekeys secrets.enc.yaml
# Editer un fichier de secrets chiffré
sops edit secrets.enc.yaml

Les alternatives et leurs limites

Sealed Secrets : côté cluster, clé non portable

Les Sealed Secrets(GitHub) de Bitnami permettent de chiffrer les secrets côté cluster.

Sealed Secrets est composé en 2 parties:

• Un controlleur côté cluster (installable via Helm)
• Une CLI côté client : kubeseal (brew install kubeseal)

kubeseal utilise une clé asymétrique pour chiffrer les secrets que seul le contrôleur peut déchiffrer. Ces secrets chiffrés sont ensuite encodés dans une ressource SealedSecret.

Limitations

Voici selon moi les principales limitations de Sealed Secrets :

• La clé de chiffrement est stockée dans le cluster, ce qui rend les secrets non portables entre clusters.
• En cas de compromission du cluster, les secrets peuvent être à risque.
• En cas de disaster recovery, la restauration du cluster doit inclure la restauration de la clé de chiffrement pour pouvoir accéder aux secrets.
• Les secrets sont uniquement utilisable dans un contexte Kubernetes, pas de possibilité de les utiliser pour d’autres usages (CI/CD, etc).

Je n’ai pas eu l’occasion d’utiliser Sealed Secrets dans un milieu professionnel, mais j’ai pu l’expérimenter dans des projets personnels.

Vault : puissant mais lourd à opérer

Hashicorp Vault est un serveur centralisé de gestion de secrets. Ils sont stockés, chiffrés et distribués dynamiquement via une API et les applications les récupèrent au runtime.

Limitations

• Complexité opérationnelle élevée : Vault est un service à part entière qu’il faut déployer, configurer, superviser et maintenir.
• Single point of failure potentiel : Si Vault est down, toutes les applications qui récupèrent leurs secrets dynamiquement peuvent être impactées.
• C’est un outil (trop) complet : Les concepts sont nombreux et nécessitent un temps de montée en compétence réel avant d’opérer Vault sereinement.

C’est un outil que j’ai eu l’occasion d’utiliser mais je n’ai jamais eu la “chance” de le déployer et l’opérer moi même de A à Z, je ne me sens pas légitime pour en parler plus en détail dans cet article.

A Retenir

SOPS est un outil de chiffrement de secrets qui peut s’intégrer dans une approche GitOps. Comme tout outil, il vient avec ses avantages et ses inconvénients, il est important de les connaître pour faire un choix éclairé en fonction de son contexte et de ses besoins.

Pour résumer très grossièrement préférez Sealed Secrets pour démarrer et les cas d’usage simples, SOPS pour les cas d’usage plus complexes et les équipes qui ont déjà une bonne maîtrise de la gestion de clés, et Vault pour les besoins les plus avancés et les équipes qui ont les ressources pour l’opérer sereinement.

Sources

• SOPS GitHub
• Blog de Stéphane Robert - Sealed Secrets
• Vault Documentation
• ArgoCD Vault Plugin

CMCTL est un outil en ligne de commande pour interagir avec Cert Manager. CMCTL permet de gérer les ressources Cert Manager, de diagnostiquer les problèmes et d’automatiser certaines tâches liées à la gestion des certificats. Puisque nous l’avons installé dans le précédent article il me parassait intéressant de partager mes commandes préférées pour interagir avec Cert Manager via cmctl.

Installation

brew install cert-manager/cert-manager/cmctl

Sinon pour Windows via scoop

scoop install main/cmctl

Utilisation

Commandes préférées

Afficher les certificats gérés par Cert Manager :

kubectl get certificates -A

Afficher les certificate requests en cours :

kubectl get certificaterequest -A

Renouveler un certificat manuellement :

cmctl renew  <nom-du-certificat>

Approuver/Désapprouver une demande de certificat manuellement :

$ cmctl approve -n istio-system mesh-ca --reason "pki-team" --message "this certificate is valid"
Approved CertificateRequest 'istio-system/mesh-ca'
$ cmctl deny -n my-app my-app --reason "example.com" --message "violates policy"
Denied CertificateRequest 'my-app/my-app'

Inspecter un certificat en détail :

cmctl inspect <nom-du-certificat>

Conclusion

C’est un article volontairement cours pour partager cet outil et les commandes que j’utilise le plus souvent pour manipuler les ressources de Cert Manager.

Sources

• https://cert-manager.io/docs/reference/cmctl/

Stack : GCP · GKE · Terraform · Helm · ArgoCD · SOPS · Kube-Prom-Stack · Nginx Gateway Fabric · cert-manager

Pourquoi ce projet ?

Je me lance en freelance DevOps / Platform Engineer / Cloud Engineer. Pour montrer ce que je sais faire (et documenter ce que j’apprends en chemin), je démarre un projet fil rouge public : construire une plateforme Kubernetes complète sur GCP, from scratch, avec les outils que j’estime indispensables en 2026.

Chaque article de la série documente une étape, les obstacles rencontrés et comment je les ai résolus. Format court, orienté pratique.

Je vais tenter de garder une approche pragmatique orientée “best practices” (mais pas dogmatique) pour que ce soit utile à d’autres personnes qui veulent se lancer dans la même aventure.

Ce qu’on va construire

Un cluster GKE avec la stack suivante, déployée en GitOps :

Je me focalise sur ce qui me semble essentiel pour adresser la majorité des besoins. A termes j’envisage d’ajouter d’autres composants destinés à des usages plus complexes : KEDA, Karpenter, Dapr, …

Les étapes prévues

1. Création du cluster GKE via Terraform
2. Bootstrap Helm & ArgoCD via Terraform
3. Déploiement de kube-prometheus-stack via ArgoCD
4. Déploiement de Nginx Gateway Fabric / Gateway API via ArgoCD
5. Déploiement de cert-manager + Let’s Encrypt via ArgoCD
6. Mise en place de SOPS pour la gestion des secrets

J’ajouterai probablement d’autres étapes au fur et à mesure* (ex: gestion des node pools, autoscaling, etc.) selon les besoins et les obstacles rencontrés*

Principes de base

• Tout dans Git — aucune modification manuelle sur le cluster après le bootstrap
• Least privilege — les SA GCP auront le minimum requis
• Les secrets ne sont jamais en clair dans le repo
• KISS — Keep It Simple Stupid. Pas de sur-optimisation, pas de microservices inutiles, pas de complexité superflue

Prochaine étape

→ Création du cluster GKE avec Terraform (à venir)

Renovate est un outil d’automatisation des mises à jour de dépendances. Il permet de garder les dépendances à jour en créant automatiquement des pull requests pour les nouvelles versions, les correctifs de sécurité et les mises à jour majeures.

Exemple de PR avec Renovate

Comment ça fonctionne ?

Renovate fonctionne en scannant à intervalles réguliers les dépôts Git pour détecter les mises à jour de dépendances. Lorsqu’une mise à jour est disponible, il crée automatiquement une pull request avec les changements nécessaires, y compris un changelog et des notes de version.

Ensuite, la pull request peut être automatiquement fusionnée si les contrôles de CI sont verts, ou elle peut nécessiter une revue humaine avant d’être fusionnée.

Parfois une image vaut milles mots, alors voici une illustration du workflow de Renovate :

  flowchart TD
    A([Planificateur cron]) --> B[Scan du dépôt Git / Lecture des fichiers de config]
    B --> C[Détection des mises à jour]
    C --> D{Mises à jour disponibles ?}
    D -- Non --> E[Aucune PR]
    D -- Oui --> F[Création de la PR Branche + changelog]
    F --> G[CI / Tests automatiques]
    G --> H[Automerge]
    G -.ou.- I[Review humaine]

Ce schéma a été généré avec Mermaid. J’en ferai certainement un article dédié dans le futur.

Un changement de paradigme

Dans le monde du développement logiciel, la gestion des dépendances est un défi constant. Les bibliothèques et les frameworks évoluent rapidement, et il est crucial de maintenir les dépendances à jour pour bénéficier des dernières fonctionnalités, des correctifs de sécurité et des améliorations de performance.

Autrefois (et encore aujourd’hui dans de nombreux projets), la mise à jour des dépendances n’est pas maitrisée et se fait de manière manuelle, souvent de manière ad-hoc. Cela peut entraîner des retards dans l’adoption des nouvelles versions, des risques de sécurité et une dette technique croissante.

Renovate change complètement la donne en automatisant ce processus. Plutôt que de dépendre d’une intervention humaine pour surveiller les mises à jour, Renovate prend en charge cette tâche de manière proactive. Il scanne régulièrement les dépôts, détecte les mises à jour disponibles et crée automatiquement des pull requests pour les intégrer.

Supply chain attacks

Ces derniers mois, nous avons vu une augmentation significative des attaques de la chaîne d’approvisionnement (supply chain attacks). Ces attaques ciblent les dépendances utilisées par les projets, en injectant du code malveillant dans des librairies souvent méconnues mais utilisées par tous.

En voici quelques unes :

• XZ Utils
• Axios
• Github Actions

La fin des wildcards pour les versions

L’un des avantages (ou inconvénients) majeurs de Renovate est qu’il encourage une gestion plus rigoureuse des versions. Plutôt que d’utiliser des wildcards (comme ^1.0.0 ou ~1.0.0) qui peuvent introduire des changements inattendus, Renovate propose de spécifier des versions exactes pour les dépendances.

Cela permet de mieux contrôler les mises à jour et de réduire les risques liés à l’introduction de changements non désirés.

Les concurrents

Dependabot

Dependabot est un outil similaire à Renovate qui propose également une automatisation des mises à jour de dépendances. Cependant, il est principalement intégré à GitHub et ne supporte pas autant de plateformes que Renovate. De plus, Renovate offre une plus grande flexibilité en termes de configuration et de personnalisation des règles de mise à jour.

C’est toutefois un excellent choix pour les projets hébergés sur GitHub qui souhaitent une solution simple et intégrée, sans avoir à maintenir soit même un outil supplémentaire.

Exemple d’une pull request générée par Dependabot

Vous remarquerez que le résultat est très similaire à celui de Renovate.

Le mot de la fin

Dans cet article, nous avons vu comment Renovate révolutionne la gestion des dépendances en automatisant les mises à jour et en encourageant une approche plus rigoureuse du versioning. C’est un maillon supplémentaire dans une chaîne de CI/CD qui permet à la fois de réduire les risques liés à l’introduction de changements non désirés et de réduire la friction liée à la maintenance des dépendances.

Configuration

Les éléments à déployer sont très simples :

• Un namespace pour isoler les ressources de Dependency Track
• Un HelmRepository pour indiquer à FluxCD où trouver les charts de Dependency Track
• Un HelmRelease pour déployer Dependency Track avec les valeurs de configuration souhaitées

dependency-track.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dependency-track

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: dependency-track
  namespace: dependency-track
spec:
  interval: 1h
  url: https://dependencytrack.github.io/helm-charts

---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: dependency-track
  namespace: dependency-track
spec:
  interval: 1h
  timeout: 15m
  chart:
    spec:
      chart: dependency-track
      version: "0.44.0"
      sourceRef:
        kind: HelmRepository
        name: dependency-track
        namespace: dependency-track
  values:
    frontend:
      image:
        tag: "4.14.1"
    apiServer:
      image:
        tag: "4.14.1"
      persistentVolume:
        enabled: true
        size: 20Gi
      resources:
        requests:
          cpu: "500m"
          memory: 1Gi
        limits:
          memory: 5Gi

On applique la configuration avec :

kubectl apply -f dependency-track.yaml

Verification de l’installation

On contrôle que l’installation s’est bien passée avec :

kubectl get deployment -n dependency-track
# dependency-track-frontend   1/1     1            1           47h
kubectl get statefulset -n dependency-track
# dependency-track-api-server   1/1     47h

Accès au service

Puis on lance le port forward pour accéder au service :

kubectl port-forward -n dependency-track svc/dependency-track-api-server 8080:8080

# Dans un autre terminal
kubectl port-forward -n dependency-track svc/dependency-track-frontend 8081:8080

Je vous laisse constater le résultat (login : admin / password : admin).

Problèmes rencontrés

Manque de droits pour FluxCD

Mon FluxCD n’avait pas les droits nécessaires pour créer des ressources dans le namespace dependency-track ce qui a conduit à des erreurs lors du déploiement. J’ai du spécifier les rbac suivantes :

rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: flux-pv-manager-dependency-track
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: flux-pv-manager
subjects:
  - kind: ServiceAccount
    name: flux-applier
    namespace: dependency-track
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: helm-release-manager
  namespace: dependency-track
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["services", "serviceaccounts", "pods", "persistentvolumeclaims"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets", "replicasets"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "rolebindings"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: flux-helm-release-manager
  namespace: dependency-track
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: helm-release-manager
subjects:
  - kind: ServiceAccount
    name: flux-applier
    namespace: dependency-track

Manque de ressource

J’ai toujours pour réflexe lorsque je déploie une outil de jeter un oeil aux ressources nécessaires pour le faire tourner. La chart officielle de Dependency Track réclame 2 CPU et 5Gi de RAM pour l’api server ce qui me semblait énorme pour mon petit cluster.

J’ai donc commencé par réduire les ressources demandées à 500m de CPU et 1Gi de RAM pour les tests, mais cela a conduit à des lenteurs extrêmes et des timeouts dans les logs de l’api server.

La solution, laisser la configuration RAM par défaut (5Go requested), 500m de cpu suffise par contre pour un petit cluster de test.

      resources:
        requests:
          cpu: "500m"

Le mot de la fin

Pour aller plus loin vous pouvez configurer un ingress(déprécié) ou httpRoute pour accéder à l’interface de Dependency Track sans passer par un port forward, ou encore configurer une base de données externe pour la persistance des données.

Prerequis

• Un cluster Kubernetes fonctionnel (Cloud (AWS, GCP, Azure) ou local (Kind, Minikube, K3s)
• Helm installé et configuré
• Une instance ArgoCD pour le déploiement en GitOps

Pattern App of Apps

Le pattern App of Apps consiste à créer une application principale (appelée “App of Apps”) qui référence d’autres applications (appelées “child apps”). Cela permet de regrouper plusieurs applications sous une même hiérarchie et de les gérer de manière centralisée.

Architecture d’un repo GitOps avec App of Apps

├── apps/
│   ├── monapp.yaml (Ici dependency-track dans notre cas)
├── root-app.yaml/

Dans cet exemple, root-app.yaml est l’application principale (App of Apps) qui référence monapp.yaml (child app) qui contient la configuration pour déployer Dependency Track.

Si je souhaite déployer d’autres applications je n’ai qu’à créer une nouvelle ressource Application dans le dossier apps/.

Configuration

Mon fichier root-app.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/votre-user/votre-repo
    targetRevision: main
    path: apps         
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd   
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Mon dependency-track.yaml (apps/dependency-track.yaml) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dependency-track
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/votre-user/votre-repo
    targetRevision: main
    path: dependency-track
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: dependency-track
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

On applique la configuration avec (seule étape manuelle):

kubectl apply -f root-app.yaml

A ce stade vous devriez voir la chart se déployer dans ArgoCD et après quelques minutes l’application devrait être en état “Healthy” et “Synced”.

Pour y accéder, vous pouvez faire un port forward sur le service frontend ou api server comme vu dans la section FluxCD.

kubectl port-forward -n dependency-track svc/dependency-track-api-server 8080:8080
# Dans un autre terminal
kubectl port-forward -n dependency-track svc/dependency-track-frontend 8081:8080

Et voilà le résultat (login : admin / password : admin).

Qu’est ce que c’est ?

C’est une plateforme qui permet de suivre les composants logiciels utilisés dans nos applications, d’identifier les vulnérabilités associées et de gérer les risques liés à ces dépendances.

C’est un outil particulièrement utile pour répondre aux exigences de sécurité et de conformité de nos systèmes comme le Cyber Resilience Act (CRA) en Europe ou l’IEC 81001-5-1 pour les dispositifs médicaux.

Comment ça fonctionne ?

  flowchart LR
    subgraph Sources["Sources SBOM"]
        CI[CI/CD Pipeline]
        CLI[cdxgen / syft]
    end

    subgraph DT["Dependency-Track"]
        API[API Server]
        ANA[Analyzers]
        DB[(Base de données\nH2 / PostgreSQL)]

        API -->|stocke| DB
        API -->|déclenche| ANA
    end

    subgraph Vuln["Bases de vulnérabilités"]
        NVD[NVD]
        OSV[OSV]
        GHSA[GitHub Advisory]
        OSS[OSS Index]
    end

    subgraph Alerting["Alerting"]
        NOTIF[Notifications]
        POLICY[Policy Violations]
    end

    CI -->|POST /api/v1/bom| API
    CLI -->|POST /api/v1/bom| API

    ANA <-->|sync CVEs| NVD
    ANA <-->|sync CVEs| OSV
    ANA <-->|sync CVEs| GHSA
    ANA <-->|sync CVEs| OSS

    ANA -->|vulnérabilités détectées| NOTIF
    ANA -->|violation de politique| POLICY

Dependency Track ingère des SBOM et analyse en continu les composants logiciels pour détecter les vulnérabilités connues. Il s’appuie sur des bases de données de vulnérabilités telles que le NVD (National Vulnerability Database) pour fournir des informations à jour sur les risques liés aux composants logiciels.

La SBOM

Une SBOM (Software Bill of Materials) est un fichier qui liste tous les composants logiciels utilisés dans un projet, y compris leurs versions et leurs dépendances. C’est un peu comme une liste d’ingrédients pour une recette de cuisine, mais pour les logiciels.

J’y ai dédié un article complet que vous pouvez consulter ici.

Pourquoi c’est important ?

Dans un monde où les applications sont de plus en plus complexes et dépendent de nombreux composants tiers, il est crucial de pouvoir identifier rapidement les vulnérabilités potentielles pour protéger nos systèmes et nos données. Le contexte géopolitique actuel accentue encore plus l’importance de la sécurité des logiciels, avec des attaques de plus en plus sophistiquées comme plus récemment celles sur la supply chain.

Quelques sources sur le sujet :

• Trivy supply chain attack: https://www.paloaltonetworks.com/blog/cloud-security/trivy-supply-chain-attack/
• Checkmarx security update: https://checkmarx.com/blog/checkmarx-security-update/
• Axios NPM package compromised: https://www.trendmicro.com/fr_fr/research/26/c/axios-npm-package-compromised.html

Conclusion

Maintenant que vous savez ce qu’est une SBOM, Dependency track et l’importance de ce type d’outil nous verrons dans les prochains articles comment déployer Dependency Track en mode GitOps sur Kubernetes avec ArgoCD ou FluxCD, et comment l’intégrer dans une pipeline CI/CD pour automatiser la gestion des vulnérabilités de vos applications.

Si vous ne savez pas ce qu’est une SBOM (Software Bill of Materials), je vous invite à lire mon article sur SBOM.

Grype - Qu’est-ce que c’est ?

Dans l’article précédant je vous ai présenté Syft pour générer ces fameuses SBOM, Grype est un outil complémentaire et développé par la même équipe, qui permet de scanner ces SBOM à la recherche de vulnérabilités connues. Il est notamment utile dans une chaine de CI/CD pour automatiser la détection de vulnérabilités dans les dépendances utilisées par votre projet.

En Local

Installation

Là encore les étapes ressemblent beaucoup à l’installation de Syft.

Sur Linux ou macOS, vous pouvez installer Syft en utilisant Homebrew :

brew tap anchore/grype
brew install grype

ou via curl :

curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin

Sur Windows j’aime utiliser Scoop :

scoop bucket add main
scoop install grype

Un petit coup de grype version pour vérifier que tout est bien installé et c’est parti !

Application:         grype
Version:             0.111.1
BuildDate:           2026-04-22T17:16:07Z
GitCommit:           89819276e8ebf63b4f607ca3a1b0faa3fc75f28d
GitDescription:      v0.111.1
Platform:            windows/amd64
GoVersion:           go1.26.2
Compiler:            gc
Syft Version:        v1.43.0
Supported DB Schema: 6

Utilisation

Le cas simple à partir d’une image docker :

Le résultat :

grype alpine:latest

 ✔ Vulnerability DB                [updated]  
 ✔ Parsed image                                                                                                                                         sha256:3cb067eab609612d81b4d82ff8ad71d73482bb3059a87b642d7e14f0ed659cde 
 ✔ Cataloged contents                                                                                                                                          4d889c14e7d5a73929ab00be2ef8ff22437e7cbc545931e52554a7b00e123d8b 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ File metadata                   [79 locations]  
   ├── ✔ Executables                     [17 executables]  
   └── ✔ File digests                    [79 files]  
 ✔ Scanned for vulnerabilities     [3 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 3 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 3 not-fixed, 0 ignored 
NAME           INSTALLED   TYPE  VULNERABILITY   SEVERITY  EPSS           RISK   
busybox        1.37.0-r30  apk   CVE-2025-60876  Medium    < 0.1% (15th)  < 0.1  
busybox-binsh  1.37.0-r30  apk   CVE-2025-60876  Medium    < 0.1% (15th)  < 0.1  
ssl_client     1.37.0-r30  apk   CVE-2025-60876  Medium    < 0.1% (15th)  < 0.1

Et pour une analyse encore plus rapide, vous pouvez directement scanner une SBOM générée par Syft :

syft alpine:latest -o cyclonedx-json > sbom.json # génère une SBOM pour l'image alpine:latest
grype sbom:./sbom.json # scanne la SBOM à la recherche de vulnérabilités²

En CI (GitHub Actions)

Savoir détecté les vulnérabilités en local c’est bien mais automatiser leurs détection dans une pipeline CI/CD c’est encore mieux ! On applique ainsi les bonnes pratiques DevOps : détecter tôt les problèmes lors du cycle de développement, corriger vite et avant déploiement en production.

Voici un exemple de workflow GitHub Actions qui utilise Grype pour scanner une image Docker à la recherche de vulnérabilités et échoue si une vulnérabilité critique est détectée.

name: Build, SBOM and Grype scan

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

jobs:
  build-scan:
    name: Build image, generate SBOM and scan with Grype
    runs-on: ubuntu-latest

    permissions:
      contents: read

    env:
      IMAGE_NAME: demo-node-app
      IMAGE_TAG: ${{ github.sha }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v4

      - name: Build Node.js Docker image (load locally)
        uses: docker/build-push-action@v7
        with:
          context: .
          file: ./Dockerfile
          push: false
          load: true
          tags: ${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}

      - name: Generate SBOM with Syft (SPDX JSON)
        uses: anchore/sbom-action@v0
        with:
          image: ${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}
          format: spdx-json
          output-file: sbom.spdx.json
          upload-artifact: false

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json
          if-no-files-found: error

      - name: Scan SBOM with Grype (fail on critical)
        id: grype
        uses: anchore/scan-action@v7
        with:
          sbom: sbom.spdx.json
          fail-build: true
          severity-cutoff: critical
          output-format: sarif
          output-file: grype-report.sarif

      - name: Upload Grype report artifact
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: grype-report
          path: grype-report.sarif
          if-no-files-found: error

Vous pouvez retrouver un exemple fonctionnel sur mon GitHub.

Il est également possible d’arriver au même résultat en jouant les commandes présentées ci dessous mais Anchore propose des actions GitHub pré-construites pour faciliter l’intégration de Syft et Grype dans vos workflows CI/CD. Encore une fois autant privilégier la facilité et éviter de réinventer la roue.

Conclusion

Grype est un outil à la fois simple et puissant pour analyser vos SBOM à la recherche de vulnérabilités. Il s’intègre facilement en CI et peut même être configuré en tant que commit hook pour scanner vos images ou votre code avant même de pousser vos changements, réduisant ainsi la boucle de feedback.

Sources

• Grype GitHub Repository
• Grype Documentation
• Anchore GitHub Actions

Une SBOM (Software Bill of Materials) est un fichier qui liste tous les composants logiciels utilisés dans un projet, y compris leurs versions et leurs dépendances. C’est un peu comme une liste d’ingrédients pour une recette de cuisine, mais pour les logiciels.

Elles peuvent exister sous plusieurs formats notamment pour les plus connus : CycloneDX, SPDX.

Les différents formats

CycloneDX

CycloneDX est un format de SBOM conçu pour être facile à lire et à analyser. Il utilise une structure hiérarchique pour représenter les composants logiciels et leurs dépendances, ce qui facilite la compréhension des relations entre les différents éléments d’un projet. Il est notamment développé par la fondation OWASP et est largement utilisé dans l’industrie pour la gestion des vulnérabilités et la conformité.

SPDX

SPDX (Software Package Data Exchange) quant à lui est un format développé par la Linux Foundation. Il est conçu pour être un standard ouvert et largement adopté pour la représentation des informations sur les composants logiciels, y compris les licences, les vulnérabilités et les dépendances.

Exemple d’une SBOM au format SPDX :

Lequel choisir ?

Le choix entre SPDX et CycloneDX dépend de vos besoins spécifiques en matière de gestion des composants logiciels. Si vous recherchez un format facile à lire et à analyser, CycloneDX peut être un bon choix. Si vous avez besoin d’un format plus complet qui inclut des informations sur les licences et les vulnérabilités, SPDX pourrait être plus adapté.

Voici un tableau récapitulatif pour vous aider à choisir :

Comment la générer ?

Un de mes outils préférés pour générer des SBOM est Syft, développé par Anchore. Syft est un outil en ligne de commande qui peut analyser les images de conteneurs, les systèmes de fichiers et les projets de code source pour générer des SBOM au format CycloneDX ou SPDX.

Il supporte une multitude de langages et de gestionnaires de paquets.

Les autres standards du marché sont cdxgen et trivy, ce dernier ayant été impacté par une faille de sécurité récemment, je préfère ne pas l’utiliser pour le moment (cf. l’excellent article de Stéphane Robert à ce sujet).

Installation

Sur Linux ou macOS, vous pouvez installer Syft en utilisant Homebrew :

brew install anchore/syft/syft

ou via curl :

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Sur Windows j’aime utiliser Scoop :

scoop bucket add main
scoop install syft

Un petit coup de syft version pour vérifier que tout est bien installé et c’est parti !

syft version
Application:   syft
Version:       1.38.0
BuildDate:     2025-11-17T17:42:49Z
GitCommit:     a033ae525f6c7ef937c6f49513e3403f07a1d6c0
GitDescription: v1.38.0
Platform:      windows/amd64
GoVersion:     go1.25.4
Compiler:      gc
SchemaVersion: 16.1.0

Utilisation

Voici comment générer une SBOM pour une image Docker

Le plus simple pour commencer est de s'appuyer sur une image docker standard comme alpine.

```bash
syft alpine:latest -o cyclonedx-json > sbom.json

Ici la commande pull alpine:latest et génère une SBOM au format CycloneDX en JSON, qui est ensuite redirigée vers un fichier sbom.json.

Voici comment générer une SBOM pour un projet de code source

syft dir:/path/to/your/project -o cyclonedx-json > sbom.json

ou pour cibler sur un fichier en particulier :

syft file:/path/to/your/project/package.json -o cyclonedx-json > sbom.json # pour un projet Node.js
syft file:/path/to/your/project/pyproject.toml -o cyclonedx-json > sbom.json # pour un projet Python

Conclusion

La SBOM est un outil essentiel pour la gestion des composants logiciels et la sécurité des applications. En fournissant une vue d’ensemble claire de tous les composants utilisés dans un projet, elle permet aux équipes de développement et de sécurité de mieux comprendre les risques associés à leurs logiciels et de prendre des mesures proactives pour les atténuer.

Cette SBOM peut ensuite être intégrée dans votre pipeline CI/CD et analysée avec des outils comme Dependency Track pour détecter les vulnérabilités connues et assurer la conformité de vos logiciels.

Sources

• SBOM - OWASP
• SBOM - NIST
• SBOM - SPDX
• Syft - Anchore