Scan de dépendances

L’agent parcourt toutes les 6h plusieurs emplacements projet standard et parse les lockfiles par gestionnaire. Seuls les tuples (name, version, ecosystem, is_direct) + le project_path partent vers la hub — jamais de contenu de fichier, jamais de variables d’env, jamais de secrets.

Chemins scannés

/var/www
/opt
/srv
/home/<user>
/root
/var/lib/jenkins/workspace
C:\inetpub\wwwroot           (Windows)
C:\Program Files\nodejs      (Windows)

Profondeur : 6 niveaux max. Skippe node_modules, vendor, .git, .svn, .idea, .vscode, target, build, dist, __pycache__, et tout ce qui commence par ..

Lockfiles reconnus

Fichier	Ecosystem
`package-lock.json` (npm v1/v2/v3)	npm
`yarn.lock`	npm
`pnpm-lock.yaml`	npm
`requirements.txt`	PyPI
`Pipfile.lock`	PyPI
`composer.lock`	Packagist
`Gemfile.lock`	RubyGems
`go.sum`	Go

Pas (encore) supportés : Cargo.lock, pubspec.lock, mix.lock, Maven pom.xml. PR bienvenues.

Caps pour borner le payload

100 projets max par hôte
20 000 packages totaux max par hôte
Les transitives node_modules-style sont incluses mais marquées is_direct=false

Ce que fait la hub

Le DependencyScanWorker prend toutes les 30s (cold-start) ou 6h (steady) chaque tuple unique (ecosystem, package_name, version) d’inventory_dependencies et batch-query https://api.osv.dev/v1/querybatch (1000 tuples par call). Pour chaque match il fetche le détail vuln depuis /v1/vulns/<id>, normalise la sévérité, et écrit dans inventory_dependency_cves.

Endpoint : GET /api/v1/agents/:id/inventory/dependencies → retourne :

{
  "projects": [
    { "project_path": "/var/www/api", "manifest": "package-lock.json",
      "ecosystem": "npm", "dep_count": 1248, "direct_count": 47,
      "cve_count": 89, "critical_count": 3 }
  ],
  "cves": [
    { "vulnerability_id": "GHSA-9jj7-4m8r-rfcm",
      "severity": "CRITICAL", "package_name": "jackc/pgx/v5",
      "installed_version": "5.7.0", "fixed_version": "5.9.0", ... }
  ]
}

Confidentialité

Ce qui part vers la hub :

Project path (ex. /var/www/api)
Nom + version du package
Label ecosystem
Flag direct/transitive

Ce qui NE part PAS :

Contenu du lockfile
Autres fichiers du projet (pas de .env, pas de code source)
Sha256 du lockfile lui-même
Variables d’environnement du projet

La sortie npm ls sur l’hôte expose exactement la même information à quiconque a un shell. Nous n’envoyons pas plus.

Que faire des findings

Les lignes inventory_dependency_cves sont des données idle sans action opérateur. Vous pouvez :

Les visualiser dans /agents/<id> → onglet Dependencies (par agent, par projet)
Recherche fleet-wide dans /inventory (filtre CVE-id, package, sévérité)
Créer une alert rule : trigger si un agent avec tag production a ≥1 dependency-CVE CRITICAL (combinable avec threshold + duration)
Export CSV pour votre équipe sécurité

Limites à connaître :

Pas de détection de typosquatting (react-dom vs react.dom). OSV.dev matche uniquement sur (package, version) exact.
Pas de détection de scripts d’install malicieux (post-install hooks qui posent des backdoors).
Pas de détection de comptes mainteneur compromis où des versions légitimes deviennent soudain malicieuses.

Pour ces trois, il faut ajouter des outils comme Socket.dev ou npm audit signatures (sigstore) — sur la roadmap.