Le Risque Lié aux Licences Qui Se Cache Dans Vos Installations Homebrew

Presque toutes les discussions sur la sécurité de Homebrew finissent par parler de CVE et d'outils dangereux. Presque aucune n'aborde les licences — jusqu'à ce que le service juridique découvre une bibliothèque sous licence copyleft au cœur d'un produit commercial, généralement lors d'un audit, ou pire, en pleine due diligence d'acquisition.

C'est un mauvais moment pour le découvrir. C'est aussi totalement évitable.

Le risque que personne ne surveille

Quand un développeur installe un paquet, il accepte de fait la licence sous laquelle celui-ci est distribué, qu'il en ait conscience ou non. La plupart du temps, ce n'est pas un problème : MIT, Apache, BSD. Parfois, ça l'est. Une dépendance sous licence GPL ou AGPL entraîne de véritables obligations juridiques sur la façon dont vous pouvez distribuer le logiciel qui l'utilise — et ces obligations ne demandent pas la permission avant de s'attacher à votre code.

Ce qui prend la plupart des entreprises de court : ce n'est presque jamais le paquet que le développeur a lui-même installé. C'est quelque chose dont ce paquet dépend silencieusement. Personne ne l'a choisi, personne ne l'a examiné — et quand ça ressort lors d'un audit, c'est déjà intégré dans un produit livré.

Les contrôles au niveau des paquets ne détectent pas ça, car ils répondent à la mauvaise question. Bloquer nmap parce que c'est un outil de scan réseau est une décision de sécurité sur un outil précis. Rien dans ce modèle ne surveille une clause de licence enfouie trois dépendances plus loin.

Pourquoi ça coûte cher

Le risque lié aux licences ne se manifeste pas comme un incident. Il se manifeste comme une acquisition qui cale, un constat de non-conformité sans solution simple, ou un ordre donné à l'équipe d'ingénierie d'arracher et remplacer une dépendance après la mise en production. Tout cela est bien plus difficile et coûteux que d'empêcher l'installation en amont. Et ce n'est pas une décision que l'IT peut prendre seule : c'est le juridique qui définit quelles licences sont acceptables.

C'est là le véritable problème : le juridique fixe la règle, mais n'a aucun moyen de la faire appliquer au seul moment où cela compte vraiment — celui de l'installation.

Combler cette faille

EnterpriseBrew transforme une politique de licences en règle réellement appliquée, pas en simple document. Le juridique décide quelles conditions de licence sont inacceptables — GPL, AGPL, ce que dit la politique — et chaque installation, dans toute l'entreprise, est automatiquement vérifiée par rapport à cette règle, y compris tout ce que ce paquet entraîne silencieusement avec lui. Vous pouvez aussi fonctionner à l'inverse : définir les licences approuvées, tout le reste étant bloqué par défaut.

Quel que soit le modèle choisi, c'est une règle valable pour toute l'entreprise, pas un paramètre d'équipe dont on peut s'exempter. Une exception de sécurité pour un ingénieur a du sens. Une exception juridique pour un seul poste n'en a pas — l'obligation naît au moment où le code est utilisé, pas au moment où quelqu'un s'en aperçoit.

Le résultat

Plutôt que de découvrir un problème de licence après la livraison, le paquet n'est tout simplement jamais installé. Le juridique définit la politique une seule fois. L'IT n'a pas à la surveiller manuellement, et les développeurs n'ont pas besoin de devenir experts en licences pour rester conformes — la vérification se fait automatiquement, avant que quoi que ce soit n'atteigne une machine.

Le prochain audit n'est plus une course contre la montre pour savoir ce qui est installé et à quoi cela vous expose. La réponse est déjà appliquée.