Correspondance CVE des paquets OS (OSV.dev)

monsys récupère l’inventaire de paquets que l’agent rapporte déjà — apt, dpkg, dnf, yum, rpm, apk, zypper — et interroge OSV.dev pour les CVE connues sur les versions exactes installées. Aucun scanner distant n’est lancé, l’agent sur l’hôte ne change pas ; la correspondance s’effectue côté hub contre un jeu de données public ouvert.

Pourquoi cela existe

Le hub exploite déjà trois pipelines CVE :

1. Dépendances applicatives — OSV.dev contre package.json, requirements.txt, composer.lock, go.sum. Schéma 035.
2. Images conteneur — Trivy contre les manifests. Schéma 035.
3. Noyau — Trackers distro (USN, Debian Security Tracker, RHEL CSAF, Gentoo GLSA) contre la version de noyau en cours. Schéma 093.

Le manquant était les paquets OS sur l’hôte lui-même : une libssl3, apache2, nginx, glibc non patchée. Le schéma 100 comble ce manque en réutilisant le même backend déjà éprouvé pour les dépendances applicatives.

Couverture

OSV.dev couvre ces écosystèmes OS, mis à jour en continu :

Famille distro	Écosystème OSV
Ubuntu	Ubuntu:24.04, Ubuntu:22.04, Ubuntu:20.04, Ubuntu:18.04
Debian	Debian:12, Debian:11, Debian:10
Alpine	Alpine:v3.19, Alpine:v3.18, …
Rocky Linux	Rocky Linux:9, Rocky Linux:8
AlmaLinux	AlmaLinux:9, AlmaLinux:8
openSUSE Tumbleweed	openSUSE:Tumbleweed
Wolfi	Wolfi
Chainguard	Chainguard
SUSE SLES 15	SUSE:SLES15

Les distros sans écosystème OSV (Arch, Gentoo, FreeBSD, builds personnalisés) sont silencieusement ignorées — la sous-composante du Trust Score est neutralisée plutôt que pénalisée.

Fonctionnement

1. Toutes les 2 heures OSPackageCveWorker lit le dernier snapshot d’inventaire par agent, dérive un écosystème OSV depuis os_name + os_version, et soumet (ecosystem, package_name, version) à POST https://api.osv.dev/v1/querybatch par lots de 1000.
2. Chaque ID de vulnérabilité unique est ensuite récupéré une fois via GET https://api.osv.dev/v1/vulns/{id}, mis en cache pour le cycle.
3. Chaque correspondance (agent, package, version, vuln_id) est upsert dans os_package_cves avec sévérité, version corrective, résumé, alias.
4. La page /recommendations les remonte automatiquement, et l’onglet CVE par agent les fusionne (UNION) avec les findings app-dep et Trivy existants.

Impact sur le Trust Score

La composante patch_hygiene (poids 30 %) devient un composite à 3 voies dès que les trois sous-composantes ont des données :

• application_cves — 50 %
• kernel_currency — 25 %
• os_packages — 25 %

Quand l’hôte est trop récent pour avoir des données OS-package, la sous-composante est neutralisée (poids 0) — le score reste stable au lieu de pénaliser silencieusement.

Confidentialité

Nous envoyons uniquement des triplets (ecosystem, name, version) à OSV.dev. Pas de hostname, pas de tenant ID, pas d’agent ID. L’exposition est équivalente à un apt list --installed exécuté localement par quiconque dispose d’un shell sur la machine. OSV.dev est opéré par l’équipe Open Source Security de Google sous licence Apache 2.0 ; le lookup est non authentifié et gratuit.

Agir sur un finding

Chaque finding est observe-only — selon le principe human-in-the-loop de monsys, le hub ne lance jamais automatiquement apt upgrade ni aucune autre mutation. La page /recommendations propose une commande de prévisualisation par hôte :

Distro	Aperçu
Ubuntu / Debian	sudo apt-get update && sudo apt-get upgrade -y
RHEL / Rocky / Alma	sudo dnf upgrade --security -y
Alpine	sudo apk update && sudo apk upgrade
openSUSE / SLES	sudo zypper patch

Pour une exécution contrôlée il existe le flux EAT package_update existant sur l’agent — l’opérateur approuve la mise à jour via TOTP, le EAT autorise un apt upgrade <pkg>=<version> à usage unique avec une entrée d’audit-log signée. Cette partie n’a pas changé.

Outil MCP

Pour les utilisateurs du Claude Connector, le nouvel outil monsys_list_os_cves expose les mêmes données avec des filtres min_severity, only_with_fix, et agent_id. Comme tous les outils detection, il est en lecture seule.