Sécurité supply-chain

monsys.ai couvre trois catégories de risques supply-chain :

Paquets OS — apt/rpm/winget/wmic → NVD + EPSS
Images conteneurs — Docker images → Trivy (côté hub)
Dépendances applicatives — npm/pip/composer/go/gem → OSV.dev

Aucune des trois ne nécessite de logiciel supplémentaire sur l’hôte client. L’agent remonte noms + versions ; la hub fait le travail CVE.

Paquets OS

L’agent lit l’état du gestionnaire de paquets :

OS	Source
Debian/Ubuntu	`dpkg-query -W`
RHEL/Alma/Rocky	`rpm -qa`
Alpine	`apk info -vv`
Windows	`winget list` avec fallback `wmic product get`

Résultat par agent : ligne inventory_packages avec (name, version, manager). La hub matche contre le feed NVD courant + probabilité d’exploit EPSS, avec parsing des plages de versions pour les expressions exactes, geq/leq et multi-range.

Par match un risk_score est calculé :

base   = cvss × max(epss, 0.05)
× 1.5 si CVE > 30 jours sans patch                   (age factor)
× 2.0 si exploit public connu                        (exploit factor)
× 1.5 si le paquet écoute sur un port internet-facing
capped at 10.0

L’internet-exposure est déduit de inventory_ports où address NOT IN ('127.0.0.1', '::1'), matché sur le nom de processus.

Endpoint : GET /api/v1/inventory/cves (fleet-wide) ou ?agent=<uuid> (par hôte). Filtres : cve, pkg, min_cvss, tag. Export CSV : &format=csv.

Images conteneurs

Pour les clients qui font tourner Docker, l’agent remonte les lignes inventory_containers — nom + tag d’image, image-digest, run-state, port mappings, run-as user, cap_add, privileged flag.

La hub fait tourner trivy image --severity=HIGH,CRITICAL --scanners=vuln contre chaque (image, tag) unique toutes les 6h. Trivy utilise la base officielle (miroir de GitHub Advisory + NVD) ; nous synchronisons cette DB une seule fois sur la hub.

Important : Trivy n’est pas sur l’hôte client. Nous avons brièvement considéré cette approche, mais elle exige root et installation de logiciel chez chaque client. L’approche hub-side fonctionne pour :

Registries publics (Docker Hub, GHCR, Quay) — immédiat
Registries privés — un seul trivy registry login sur le hub host

Les findings vont dans inventory_container_cves et sont visibles dans l’onglet Containers de chaque agent.

Limites :

Pas de scan pour les images uniquement disponibles via un registry privé derrière un VPN auquel la hub n’a pas d’accès réseau. Pour ce scénario voir RFC-0001 Tailscale integration.
Pas de scan du contenu d’exécution (process tree, secrets montés) — uniquement ce qui est dans les manifests d’image.

Dépendances applicatives (npm/pip/composer/go/gem)

L’agent parcourt /var/www, /opt, /srv, /home/*, /root (profondeur max 6) et parse les lockfiles :

Manifest	Ecosystem
`package-lock.json` (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

Seuls les tuples (name, version, ecosystem, is_direct) sont envoyés à la hub — pas de contenu de fichier. Caps par hôte : 100 projets max, 20 000 packages max, 6 niveaux de profondeur max. node_modules, vendor, .git sont skipped.

Le DependencyScanWorker de la hub batch-query https://api.osv.dev/v1/querybatch (1000 tuples/requête, gratuit, public). Pour chaque match il récupère le détail vuln depuis /v1/vulns/<id>, normalise la sévérité, et écrit dans inventory_dependency_cves.

Cadence cold-start : toutes les 30s pendant les 15 premières minutes après hub-start (capture les nouveaux deps), ensuite 6h steady.

Ce qu’OSV.dev couvre

CVE connues avec aliases (CVE-, GHSA-, PYSEC-, RUSTSEC-, …)
Plages de versions affectées avec fix-versions
Sévérité depuis GitHub Advisory DB (normalisée par nous vers CRITICAL/HIGH/MODERATE/LOW)
Aliases cross-ecosystem — un GHSA peut couvrir à la fois npm et Python

Ce qu’OSV.dev NE couvre PAS

Typosquatting — react-dom vs react.dom. Pas de détection de patterns.
Scripts d’install malicieux — npm install d’un paquet d’apparence légitime qui pose des backdoors. Demande analyse de tarball.
Comptes mainteneur compromis où un paquet normal contient soudain du code malicieux (style event-stream).

Pour ces catégories, vous avez besoin d’analyse comportementale comme Socket.dev ou npm audit signatures (signature sigstore). Les deux pourront être intégrés plus tard.

Bonnes pratiques pour vos clients

npm ci --ignore-scripts en CI et production — npm install uniquement en dev où vous savez ce que vous lancez.
Pinnez les dépendances de production (package-lock.json committé, pas de ranges ^X.Y.Z).
Mettez une alert rule : nouvelle CVE CRITICAL dans inventory_dependency_cves pour un agent avec tag production → notify dans la minute.
Maintenance windows pendant les deploys — sinon votre rolling-update déclenche une tempête d’alertes.
Audit log review hebdo pour les actions playbook_run ou branding-PUT anormales.