behavior.lock : verrouiller le comportement d'une dépendance, pas seulement son contenu

behavior.lock : verrouiller le comportement d’une dépendance, pas seulement son contenu

Le Ménure

Un fichier de verrouillage de dépendances répond à une seule question : ai-je reçu les octets attendus ? Qui met à jour quatre cents paquets un mardi matin en pose une autre : cette version fait-elle quelque chose de nouveau ?

Le format behavior.lock prétend y répondre. Il observe la dépendance pendant la suite de tests, enregistre le profil de ses opérations (fichiers lus et écrits, sockets, processus) et le fige dans un fichier versionné. À la mise à jour, s’il s’est élargi, la mise à jour est refusée jusqu’à revue humaine.

{
  "behaviorlock": 1,
  "package": "fmt-dates",
  "version": "4.2.1",
  "captured": { "coverage_pct": 82 },
  "profile": {
    "fs_read": ["node_modules/fmt-dates/**"],
    "fs_write": [], "net_connect": [], "proc_spawn": [],
    "env_read": ["TZ", "LANG"], "dyn_load": []
  },
  "profile_digest": "blake3:4c7a1e9d2b8f0a53"
}

Six classes, une hiérarchie

Classe	Gravité d’un élargissement
proc_spawn, net_connect, dyn_load	critique
fs_write	élevée
env_read	moyenne
fs_read	faible

La hiérarchie n’est pas discutable : une bibliothèque de dates qui lit une variable d’environnement est une curiosité ; la même qui ouvre une socket est un incident.

La capture passe par seccomp en mode notification et attribue chaque opération au paquet en remontant la pile d’appels. Sous behaviorlock verify, la suite de tests passe de 41 s à 2 min 10 s : la vérification se fait donc en intégration continue, et une montée de version produit 3 à 40 lignes de différence à relire. Un profil capturé sous 60 % de couverture est déclaré incomparable.

Faux positifs et angles morts

Le taux de faux positifs mesuré sur les dépôts de référence est de 0,4 % des mises à jour. Le gestionnaire de paquets parle lui-même au réseau : il est exclu du périmètre, faute de quoi net_connect apparaîtrait partout.

Le format reconnaît quatre angles morts : code non exécuté en test, code déclenché par condition, détournement d’une opération autorisée, chaîne de construction.

🪶 Ménure 🪶

behavior.lock n’existe pas : ni format, ni outil, ni « dépôts de référence ». Ce qui aurait dû alerter :

• Le verrou certifie ce que l’attaquant veut lui faire certifier. Un profil de test atteste qu’un paquet se tient bien quand il est observé. Le code malveillant attend la production, une date, l’absence de débogueur. La section « angles morts », en fin de texte, annule tout ce qui précède.
• Un profil d’appels système n’est pas stable : plateforme, noyau, cache, ordre des tests. « 0,4 % de faux positifs » est l’invraisemblance centrale ; le chiffre réel se compte en dizaines de pour cent avant des mois de réglage.
• L’exclusion de l’outillage est un trou permanent. Ce qui tourne dans le contexte du gestionnaire de paquets, donc les scripts d’installation, donc la vraie surface d’attaque, passe sous le radar. La page le dit et continue.
• Les chiffres sont posés sans source (0,4 %, 82 %, 60 %, six classes), et la hiérarchie « non discutable » évite d’avoir à la justifier.
• L’empreinte de profil fait 64 bits (seize caractères hexadécimaux) pour arbitrer le refus d’une mise à jour : c’est court, et nul ne s’en inquiète.
• Aucune référence vérifiable, alors que les mécanismes cités au passage (seccomp, empreintes d’intégrité, couverture) sont réels : une invention entourée de vrai se vérifie moins bien.

Le vrai sujet, les attaques de chaîne d’approvisionnement, n’a pas de remède comportemental : verrouillage par empreintes, refus des scripts d’installation, provenance signée des artefacts, et revue des différences, seul contrôle qui voie du code conditionnel. Du vrai : les attaques de chaîne d’approvisionnement, les mises à jour automatiques de dépendances, les niveaux SLSA.