Kusari : transformer les métadonnées supply chain en décisions

Vous avez investi dans votre supply chain : SBOM générés avec Syft, images signées avec Cosign, attestations SLSA produites par vos pipelines. Mais quand un développeur ouvre une pull request qui ajoute une dépendance risquée, qui décide si le merge est autorisé ? Souvent, personne — la PR est mergée avant même que la sécurité n’ait pu réagir.

C’est le problème que Kusari adresse : transformer vos métadonnées supply chain en décisions exploitables au moment où elles comptent — dans les pull requests, avant le merge.

Qu’est-ce que Kusari ?

Kusari (prononcé “kou-sa-ri”) est une plateforme de contrôle de la supply chain logicielle qui exploite les standards existants (SBOM, SLSA, attestations) pour produire des décisions go/no-go au niveau du SDLC.

Concrètement, Kusari :

• Agrège les métadonnées supply chain (SBOM, attestations, résultats de scans)
• Corrèle ces données avec des bases de vulnérabilités et des policies internes
• Bloque ou avertit au niveau des pull requests GitHub
• Documente chaque décision pour l’audit et la conformité

L'analogie du contrôleur aérien

Si GUAC est la tour de contrôle qui visualise tous les avions en vol, Kusari est le contrôleur qui décide “ce vol peut atterrir” ou “ce vol doit attendre”. Il consomme les informations du radar (SBOM, SLSA) et applique les règles (policies) pour prendre des décisions en temps réel.

Où Kusari se place dans la chaîne

Kusari n’est pas un générateur de SBOM, un signataire d’artefacts, ni un scanner de vulnérabilités. Il se situe au-dessus de ces briques fondamentales, comme orchestrateur de décision.

Outil	Rôle	Ce qu’il produit
Syft	Génère un SBOM	Liste des composants
Cosign	Signe et atteste	Preuve cryptographique
Trivy/Grype	Scanne les vulnérabilités	Liste de CVE
GUAC	Corrèle et visualise	Graphe interrogeable
Kusari	Décide et bloque	Go/no-go dans le workflow

Glissez pour voir

Projet OpenSSF

Kusari est développé par Kusari Inc., membre de l’OpenSSF (Open Source Security Foundation). L’outil Kusari Inspector est proposé gratuitement à certains projets OpenSSF pour apporter davantage de visibilité sur la supply chain et effectuer des contrôles proactifs.

Le problème que Kusari résout

Le fossé entre production de métadonnées et action

La plupart des équipes qui investissent dans la supply chain security rencontrent le même blocage :

1. ✅ Elles génèrent des SBOM à chaque build
2. ✅ Elles signent leurs images avec Cosign
3. ✅ Elles produisent des attestations SLSA
4. ✅ Elles scannent les vulnérabilités en CI
5. ❌ Mais rien n’empêche une PR dangereuse d’être mergée

Les rapports s’accumulent, les dashboards clignotent, mais le merge est déjà fait. La sécurité intervient après le problème, pas avant.

Les contrôles existants sont insuffisants

Les branch protections GitHub natives offrent des contrôles basiques :

• Tests CI passés ✓
• Review approuvée ✓
• Pas de conflits ✓

Mais elles ne savent pas répondre à :

• “Cette PR ajoute une dépendance avec une CVE critique”
• “Ce changement introduit une licence GPL incompatible”
• “Cette image de base n’a pas d’attestation SLSA”
• “Ce mainteneur upstream a un Scorecard inférieur à 5”

Kusari comble ce fossé en transformant les signaux supply chain en checks GitHub bloquants.

Kusari Inspector : contrôles dans les pull requests

Kusari Inspector est le produit principal de Kusari. Il s’intègre directement dans le workflow GitHub pour fournir des recommandations go/no-go sur chaque pull request.

Ce que Kusari Inspector vérifie

Catégorie	Contrôles effectués
Dépendances	Nouvelles deps avec CVE connues, deps obsolètes, deps abandonnées
Licences	Licences incompatibles, changements de licence, copyleft non autorisé
Provenance	Attestations SLSA manquantes, signatures invalides, images non vérifiées
Mainteneurs	Scorecard upstream faible, mainteneur unique, projet en fin de vie
Policies	Règles internes violées, seuils de risque dépassés

Glissez pour voir

Fonctionnement dans une PR

Quand un développeur ouvre une pull request, Kusari Inspector :

1. Analyse les changements

   Détecte les modifications de dépendances (package.json, go.mod, requirements.txt, Dockerfile, etc.)

2. Collecte les métadonnées

   Récupère les SBOM, attestations et données de vulnérabilités pour chaque nouveau composant

3. Évalue les policies

   Compare les signaux collectés aux règles définies par votre organisation

4. Publie le verdict

   Ajoute un check GitHub (✓ ou ✗) et un commentaire détaillant les risques identifiés

Exemple de commentaire Kusari

## 🔍 Kusari Inspector Report

### Summary
- **Status**: ⚠️ Warning (3 issues found)
- **New dependencies**: 2
- **License changes**: 0
- **Security concerns**: 3

### Issues

#### 1. CVE-2024-12345 in lodash@4.17.20
- **Severity**: High (CVSS 8.1)
- **Fix available**: lodash@4.17.21
- **Recommendation**: Upgrade before merge

#### 2. Low OpenSSF Scorecard for new-obscure-lib
- **Score**: 2.3/10
- **Concerns**: Single maintainer, no branch protection, no signed releases
- **Recommendation**: Review necessity, consider alternatives

#### 3. SLSA provenance missing for base image
- **Image**: custom-runtime:1.2.3
- **Expected**: SLSA Level 2+
- **Recommendation**: Use image with verifiable provenance

Pas un scanner de plus

Kusari Inspector ne rescanne pas vos dépendances. Il consomme les résultats de vos outils existants (Trivy, Snyk, Grype) et les corrèle avec d’autres signaux pour produire une décision globale. C’est un orchestrateur, pas un scanner.

Installation et configuration

Prérequis

• GitHub repository avec accès admin (pour installer l’app)
• CI pipeline produisant des SBOM (recommandé)
• Optionnel : attestations SLSA, scans de vulnérabilités

Intégration GitHub App

Kusari Inspector s’installe comme une GitHub App. L’installation se fait en quelques clics depuis le GitHub Marketplace ou via invitation OpenSSF pour les projets éligibles.

1. Installer l’application GitHub

   Rendez-vous sur le GitHub Marketplace et installez Kusari Inspector sur les repositories souhaités.

2. Configurer les permissions

   L’app demande les permissions suivantes :

   • Read : Contents, Pull requests, Metadata
   • Write : Checks, Pull request comments

3. Ajouter le fichier de configuration

   Créez .kusari/config.yaml à la racine du repository :

   .kusari/config.yaml

   version: 1
   
   # Niveau de rigueur global
   # strict: bloque les PR non conformes
   # warn: avertit mais autorise le merge
   # info: informatif uniquement
   enforcement: warn
   
   # Règles sur les dépendances
   dependencies:
     # Bloquer les nouvelles deps avec CVE critiques
     block_critical_cve: true
   
     # Seuil Scorecard minimum pour les nouvelles deps
     min_scorecard: 4.0
   
     # Bloquer les dépendances abandonnées
     block_abandoned: true
     abandoned_threshold_days: 365
   
   # Règles sur les licences
   licenses:
     # Licences autorisées
     allowed:
       - MIT
       - Apache-2.0
       - BSD-3-Clause
       - ISC
   
     # Licences interdites
     blocked:
       - GPL-3.0
       - AGPL-3.0
   
     # Avertir pour les licences inconnues
     warn_unknown: true
   
   # Règles sur la provenance
   provenance:
     # Exiger des attestations SLSA pour les images de base
     require_slsa_images: true
     min_slsa_level: 2
   
     # Vérifier les signatures Cosign
     verify_signatures: true
   
   # Exceptions
   exceptions:
     # Dépendances exemptées des contrôles
     dependencies:
       - "internal-legacy-lib"
   
     # Paths ignorés
     paths:
       - "test/**"
       - "docs/**"

4. Activer les branch protections

   Pour rendre les checks bloquants, activez-les dans les branch protection rules de GitHub :

   Settings → Branches → Branch protection rules → Require status checks

Utilisation en CLI

Kusari propose également un CLI pour les vérifications locales et l’intégration dans des pipelines non-GitHub.

# Installation
curl -sSfL https://get.kusari.dev | sh

# Vérifier un projet local
kusari inspect .

# Vérifier un SBOM spécifique
kusari inspect --sbom sbom.json

# Format de sortie
kusari inspect --format json > report.json
kusari inspect --format sarif > report.sarif

# Mode strict (exit code non-zero si problèmes)
kusari inspect --strict

Sortie typique :

$ kusari inspect .

🔍 Kusari Inspector v1.2.0

Analyzing: myapp (Node.js project)
Dependencies: 847 (including transitive)
SBOM source: package-lock.json

Results:
┌─────────────────────────────────────────────────────────────────┐
│ Category        │ Issues │ Warnings │ Info                      │
├─────────────────────────────────────────────────────────────────┤
│ Vulnerabilities │ 2      │ 5        │ 12                        │
│ Licenses        │ 0      │ 3        │ 0                         │
│ Provenance      │ 1      │ 0        │ 0                         │
│ Maintenance     │ 0      │ 4        │ 8                         │
└─────────────────────────────────────────────────────────────────┘

Critical:
  - CVE-2024-12345 in lodash@4.17.20 (upgrade to 4.17.21)
  - Missing SLSA provenance for base image node:18-alpine

Exit code: 1 (issues found)

Intégration avec vos outils existants

Avec Syft et les SBOM

Kusari consomme les SBOM aux formats standards (SPDX, CycloneDX). Si vous générez déjà des SBOM avec Syft, Kusari peut les utiliser directement.

.github/workflows/ci.yml

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Run Kusari Inspector
        uses: kusari/inspector-action@v1
        with:
          sbom: sbom.spdx.json
          config: .kusari/config.yaml

Avec GUAC

Kusari peut interroger une instance GUAC pour enrichir ses décisions avec des données historiques et des corrélations complexes.

.kusari/config.yaml

integrations:
  guac:
    enabled: true
    endpoint: https://guac.internal.company.com/graphql
    # Utiliser GUAC pour vérifier l'historique d'une dépendance
    queries:
      - transitive_dependencies
      - vulnerability_history
      - sbom_drift

Avec Kyverno (Kubernetes)

Si vous utilisez Kyverno pour l’admission control Kubernetes, Kusari peut partager ses policies pour une cohérence CI/CD → Runtime.

.kusari/config.yaml

export:
  kyverno:
    enabled: true
    output_dir: .kyverno/generated/

Les policies Kusari sont converties en ClusterPolicy Kyverno, assurant que les mêmes règles s’appliquent en CI et à l’admission.

Comparaison avec les alternatives

Critère	Kusari	GUAC	Dependabot	Snyk
Focus principal	Décision go/no-go	Visualisation graphe	Updates deps	Scan vulnérabilités
Intégration PR	✅ Native	⚠️ Via intégration	✅ Native	✅ Native
Consomme SBOM	✅	✅	❌	⚠️ Partiel
Consomme SLSA	✅	✅	❌	❌
Policies personnalisées	✅	⚠️ Via queries	❌	✅ Payant
Analyse licences	✅	❌	❌	✅
Scorecard upstream	✅	✅	❌	❌
Open source	⚠️ Inspector gratuit OSS	✅	✅	❌

Glissez pour voir

Complémentarité, pas remplacement

Kusari n’est pas concurrent de Trivy, Snyk ou GUAC. Il orchestre ces outils. La stack idéale combine :

• Syft → génère les SBOM
• Trivy/Grype → scanne les vulnérabilités
• GUAC → corrèle et visualise
• Kusari → décide et bloque dans le workflow

Cas d’usage concrets

1. Bloquer les dépendances à risque avant merge

Problème : Un développeur ajoute une dépendance npm populaire mais maintenue par une seule personne sans 2FA.

Configuration Kusari :

dependencies:
  min_scorecard: 5.0
  require_branch_protection: true
  min_maintainers: 2

Résultat : La PR est bloquée avec un message expliquant les risques et suggérant des alternatives plus sûres.

2. Imposer la conformité license avant production

Problème : Une dépendance transitive introduit une licence GPL, incompatible avec votre modèle commercial.

Configuration Kusari :

licenses:
  blocked:
    - GPL-2.0
    - GPL-3.0
    - LGPL-2.1
    - LGPL-3.0
  enforcement: strict

Résultat : Check GitHub en échec tant que la dépendance n’est pas remplacée ou qu’une exception n’est pas ajoutée.

3. Exiger SLSA Level 2 pour les images de base

Problème : L’équipe utilise des images Docker communautaires sans garantie de provenance.

Configuration Kusari :

provenance:
  require_slsa_images: true
  min_slsa_level: 2
  trusted_builders:
    - "https://github.com/slsa-framework/slsa-github-generator"
    - "https://cloudbuild.googleapis.com"

Résultat : Seules les images avec attestation SLSA Level 2+ sont autorisées dans les Dockerfile.

Bonnes pratiques

Déploiement progressif

1. Commencer en mode info

   Observez les alertes sans bloquer pendant 2-4 semaines pour calibrer les seuils.

2. Passer en mode warn

   Avertissez les développeurs dans les PR. Ils s’habituent aux contrôles sans frustration.

3. Activer strict graduellement

   Commencez par les règles critiques (CVE high/critical), puis élargissez.

Exceptions maîtrisées

exceptions:
  # Documenter POURQUOI chaque exception existe
  dependencies:
    - name: "legacy-internal-lib"
      reason: "Migration planifiée Q3 2026"
      expires: "2026-09-30"
      approved_by: "security-team"

Intégration avec la gouvernance

• Exportez les rapports vers votre SIEM ou outil GRC
• Alignez les policies avec vos exigences CRA/NIS2
• Auditez les exceptions régulièrement

Dépannage

Problèmes courants

Symptôme	Cause probable	Solution
Check toujours en pending	Permissions GitHub insuffisantes	Vérifier les permissions de l’app
Faux positifs sur licences	License mal détectée dans SBOM	Améliorer le SBOM source ou ajouter override
SLSA check échoue	Attestation au mauvais format	Vérifier format in-toto/slsa-provenance
Performances lentes	Trop de dépendances transitives	Activer le cache Kusari

Glissez pour voir

Logs et debugging

# Mode verbose
kusari inspect --verbose

# Exporter le rapport complet
kusari inspect --format json --output full-report.json

# Vérifier la configuration
kusari config validate .kusari/config.yaml

À retenir

1. Kusari n’est pas un scanner — c’est un orchestrateur de décision qui consomme les résultats de vos outils existants

2. Le timing est crucial — bloquer une PR risquée avant le merge change tout par rapport à un rapport post-facto

3. Les standards sont la clé — Kusari exploite SBOM, SLSA, Scorecard parce qu’ils fournissent des signaux structurés

4. Progressivité — commencez en mode informatif, calibrez les seuils, puis rendez les contrôles bloquants

5. Complémentarité — Kusari se combine avec GUAC (visualisation), Kyverno (admission) et vos scanners pour une couverture complète

6. Governance-aware — les exceptions sont documentées, les décisions auditables, compatible avec les exigences CRA/NIS2

Prochaines étapes

GUAC : visualiser la supply chain Corrélation et requêtes sur vos métadonnées supply chain

Framework SLSA Comprendre les niveaux de maturité SLSA exploités par Kusari

SBOM avec Syft Générer les SBOM que Kusari consomme

Vérifier les attestations en CI Implémenter la vérification SLSA dans vos pipelines

Kyverno : admission policies Étendre les contrôles Kusari au runtime Kubernetes

Scorecard OpenSSF Évaluer les projets upstream avant adoption

Ressources externes

• Site officiel Kusari
• Annonce OpenSSF — Kusari Inspector
• Blog Kusari — Supply Chain Security Overview
• GitHub Kusari

×

📖 Voir la documentation →