Contexte et limites du SBOM

Le processus classique repose sur la création d’un SBOM avec syft puis son analyse via grype. Dans l’exemple du Dockerfile Debian, la commande 

syft scan docker:opensshpam -o cyclonedx-json > sbom.cdx
produit un fichier contenant 284 correspondances de vulnérabilités, dont 3 critiques, 65 élevées, 80 moyennes, 39 faibles et 97 négligeables. Parmi les paquets listés, openssh-server 1:10.0p1-7+deb13u4 apparaît avec la CVE‑2007‑2768, classée « Negligible » mais non corrigée depuis 2007. Cette approche montre que chaque modification de configuration nécessite de répéter l’ensemble du scan, ce qui devient rapidement impraticable.

Analyse statique avec govulncheck

Pour le code Go, la chaîne govulncheck exploite la base de données de vulnérabilités du projet Go et le champ ecosystem_specific qui indique les chemins d’importation affectés. Sur le petit programme affichant width.Widen.String("hello, world"), la version golang.org/x/text v0.38.0 déclenche deux alertes (GO‑2026‑5970 et GO‑2026‑6629). L’analyse statique révèle que ces vulnérabilités résident respectivement dans golang.org/x/text/unicode/norm et golang.org/x/text/secure/precis, qui ne sont pas utilisés. Le résultat affiché est :

=== Symbol Results ===
No vulnerabilities found.
Your code is affected by 0 vulnerabilities.
This scan also found 1 vulnerability in packages you import and 14 vulnerabilities in modules you require, but your code doesn’t appear to call these vulnerabilities.

Ce filtrage montre qu’une analyse basée sur le code source peut éliminer la plupart des faux positifs, mais il faut que chaque projet maintienne à jour les métadonnées d’impact.

Déploiement VEX sous NixOS

NixOS offre une alternative grâce à sa configuration déclarative. Le module suivant, issu d’un flake, décrit un système avec system.stateVersion = "26.11", le service OpenSSH activé et KbdInteractiveAuthentication = false :

{
  fileSystems."/" = { device = "/dev/sda1"; fsType = "ext4"; };
  boot.loader.grub.device = "nodev";
  services.openssh.enable = true;
  services.openssh.settings.KbdInteractiveAuthentication = false;
}

Parce que chaque paquet et chaque option sont explicitement listés, Nix peut générer automatiquement un document VEX en croisant le catalogue Nixpkgs avec la base de données de vulnérabilités. Ainsi, dès qu’une mise à jour de openssh corrige une CVE, le VEX correspondant est mis à jour sans intervention manuelle, ce qui supprime la nécessité de dépendre de Dependabot pour chaque dépendance.

Implications et limites

Le principal avantage réside dans la reproductibilité : le même flake produit toujours le même SBOM, ce qui rend le calcul de VEX fiable. Cependant, la précision dépend de la disponibilité d’identifiants de vulnérabilité pour chaque paquet Nix. Si la base de données ne décrit pas un paquet ou un sous‑module, le VEX restera incomplet. De plus, la génération automatisée ne résout pas les vulnérabilités qui requièrent une configuration dynamique, comme les modules PAM non‑détectés dans l’exemple OpenSSH. En résumé, NixOS rend la production de VEX scalable pour les systèmes d’exploitation, mais la couverture reste conditionnée par la qualité des métadonnées upstream.