Sécurité supply-chain

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

1. Paquets OS — apt/rpm/winget/wmic → NVD + EPSS
2. Images conteneurs — Docker images → Trivy (côté hub)
3. 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

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