Security on Valérian Pyckaert

Dependency Track - Déploiement en GitOps avec FluxCD

Thu, 07 May 2026 08:00:00 +0200

Si vous ne savez pas ce qu’est Dependency Track, je vous invite à lire mon article d’introduction à Dependency Track ici.

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.

Dependency Track - Déploiement en GitOps avec ArgoCD

Wed, 06 May 2026 08:00:00 +0200

Si vous ne savez pas ce qu’est Dependency Track, je vous invite à lire mon article d’introduction à Dependency Track ici.

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).

Dependency Track - Monitorer les vulnérabilités de vos applications

Tue, 05 May 2026 08:00:00 +0200

Voici la première partie d’une série d’articles dédiés à Dependency Track et à son déploiement en mode GitOps avec ArgoCD ou FluxCD sur un cluster Kubernetes.

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.

Grype

Fri, 01 May 2026 08:00:00 +0200

Préambule

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

SBOM (Software Bill of Materials)

Thu, 30 Apr 2026 10:29:03 +0200

Qu’est-ce que c’est ?

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 :

Caractéristique	SPDX	CycloneDX
Facilité de lecture	Moins lisible pour les humains ❌	Plus lisible ✅
Analyse automatisée	Plus adapté pour l’analyse	Adapté pour l’analyse
Adoption	Large adoption dans l’industrie	Adoption croissante
Support des licences	Oui ✅	Non ❌
Support des vulnérabilités	Oui ✅	Non ❌

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