TuxCare et JFrog s'associent pour la correction des failles dans les logiciels libres

Principaux enseignements

Les correctifs SecureChain seront disponibles dans JFrog Zero-Touch Remediation et seront appliqués sans changement de version.
La détection n'a jamais été le plus difficile ; ce qui l'a toujours été, c'est de mettre au point et de déployer un correctif qui ne provoque pas de dysfonctionnements.
La prise en charge se poursuit même après que les responsables en amont ont cessé de publier des correctifs de sécurité pour un paquet.
Chaque correctif appliqué est certifié par JFrog AppTrust, ce qui permet d'obtenir des preuves d'audit directement issues du pipeline.

Une vulnérabilité CVE critique est détectée dans un paquet situé à trois niveaux de profondeur dans l'arborescence des dépendances. Le scanner la détecte le jour même, ce qui est la partie la plus facile. Or, il s'avère que le correctif n'est disponible que dans une version majeure ; cette version modifie une API appelée par deux de vos services, et le paquet qui l'a intégrée est verrouillé par un SDK fournisseur sur lequel personne dans l'équipe n'a de contrôle. Deux semaines plus tard, le ticket est toujours ouvert et la vulnérabilité figure toujours dans le rapport.

Identifier un paquet open source vulnérable est rarement la partie la plus difficile. C'est lorsque l'on doit intégrer le correctif adéquat dans la bonne version, sans créer de nouveau problème au passage, que la correction devient compliquée.

C'est précisément cette lacune que ce nouveau partenariat vise à combler. TuxCare a rejoint l'écosystème « Self-Healing » de JFrog dédié à la sécurité de la chaîne logistique logicielle en tant que partenaire fondateur, et SecureChain s'intégrera à la solution « Zero-Touch Remediation » de JFrog afin de fournir des correctifs pour les paquets open source vulnérables.

Les cas où la correction open source se heurte à un blocage

La couverture des scanners est désormais suffisante pour que la plupart des équipes aient connaissance de leurs dépendances vulnérables bien avant que quiconque n'ait élaboré de plan à leur sujet. Elles se retrouvent alors face à une file d'attente.

Un paquet tiers vulnérable laisse trois options concrètes : passer à la version corrigée, rétroporter soi-même le correctif, ou accepter le risque et le noter. La première est celle que tous les outils recommandent, mais c’est souvent la moins pratique, car les mises à jour de version dans les dépendances transitives se répercutent de manière imprévisible à partir du manifeste. Parfois, la version concernée est déjà en fin de vie, il n’y a donc plus de mise à jour possible. La deuxième option implique de maintenir un fork d'un code que vous n'avez pas écrit, sur une base de code que vous ne pouvez pas tester correctement. La troisième est celle qui se produit généralement.

Imaginez une équipe de 30 personnes chargée de la plateforme, qui gère une douzaine de services Java, dont la moitié est liée à une ancienne version de Jackson via un SDK dont elle dispose sous licence et non en propriété. La mise à niveau est un projet s'étalant sur plusieurs sprints, sans aucune nouvelle fonctionnalité associée. Les développeurs passent des journées entières à comparer les options de correction avant d'en trouver une qui puisse être déployée en toute sécurité. Quoi qu'il arrive, les mêmes conclusions apparaissent dans le rapport hebdomadaire, et la date d'audit ne change pas.

L'apport de SecureChain

Les paquets SecureChain sont recompilés à partir du code source, soumis à un contrôle antivirus avant leur publication et corrigés pour remédier aux vulnérabilités connues, sans modifier la version indiquée dans le manifeste.

Deux aspects sont importants pour cette intégration. Le correctif conserve le même numéro de version ; ainsi, aucun élément du graphe de dépendances n’a besoin d’être déplacé. De plus, la couverture ne prend pas fin lorsque la maintenance en amont cesse, car le service « Endless Lifecycle Support » continue de publier des correctifs pour cette branche de version même après que les responsables de la maintenance ont cessé leurs activités.

C'est dans cette deuxième catégorie que se trouvent bon nombre de découvertes à long terme. Un paquet qui n'a pas fait l'objet d'un commit depuis trois ans ne bénéficiera pas d'un correctif CVE de la part de son responsable, quel que soit le nombre de tickets qui y font référence.

À l'heure actuelle, SecureChain couvre npm, PyPI et Maven, tandis que Go, Rust et PHP figurent dans la feuille de route.

Que se passe-t-il à l'intérieur du pipeline ?

Artifactory est la source à partir de laquelle les builds sont générés, ce qui en fait le seul endroit où une correction peut être intégrée sans que les développeurs aient à modifier quoi que ce soit.

La correction « Zero-Touch » associe un composant vulnérable au meilleur correctif partenaire disponible conformément à votre politique, l'applique via le pipeline que vous utilisez déjà et enregistre une attestation signée de cette action via JFrog AppTrust. Lorsque votre politique privilégie un paquet reconstruit à partir du code source et mis à jour en continu, c'est la version SecureChain qui est fournie. La compilation demande le même paquet que celui demandé la veille et reçoit un paquet corrigé.

Pas de ticket. Pas besoin de chercher une version compatible. Pas de négociation avec l'équipe responsable du service.

La partie « attestation » a plus de valeur qu'il n'y paraît. La plupart des équipes parviennent finalement à prouver qu'un paquet a été corrigé. Mais elles sont bien moins nombreuses à pouvoir prouver quand il a été corrigé, pour quel CVE et selon quelle procédure, sous une forme que l'auditeur accepte sans demander de précisions supplémentaires.

Où cela porte ses fruits en premier lieu

Les cas les plus évidents sont les paquets dont le support en amont a pris fin, les dépendances transitives que votre équipe n'a jamais choisies et qu'elle ne peut pas remplacer facilement, ainsi que tout environnement dans lequel les SLA de correction sont contractuels plutôt que simplement indicatifs.

Si vous utilisez déjà Artifactory avec Xray ou Advanced Security, l'ajout de SecureChain en tant que source de correctifs relève davantage d'un choix stratégique que d'une migration. Si vos builds proviennent d'une source autre que JFrog, SecureChain fonctionne toujours comme un registre filtré autonome, et l'intégration est disponible lorsque vous en avez besoin.

Quoi qu'il en soit, ce qui mérite notre attention, ce n'est pas tant l'existence de correctifs. Il y en avait déjà auparavant. C'est le fait qu'un correctif puisse être intégré à une version en cours d'exécution sans qu'une personne ait à l'y ajouter manuellement, ce qui fait passer la correction d'un simple projet à une étape courante du processus de livraison des logiciels.

Pour en savoir plus sur la correction « zéro intervention » de JFrog : jfrog.com/zero-touch-remediation

Pour en savoir plus sur TuxCare SecureChain : tuxcare.com/securechain-for-oss

Résumé