D’où viennent les correctifs de sécurité ?

Les vulnérabilités connues dans les logiciels constituent un problème bien établi et ont été à l’origine de certaines des plus grandes violations de sécurité au monde, notamment la violation de données de Mossack Fonesca (Panama Papers), celle de VerticalScope, au cours de laquelle 45 millions de mots de passe et d’adresses IP ont été dérobés sur un réseau de 1 100 sites web, et celle des forums Ubuntu, qui a entraîné le vol de 2 millions de noms d’utilisateur et de mots de passe.

La meilleure solution pour remédier aux vulnérabilités connues consiste à mettre à jour vos logiciels. Cependant, ce n’est pas toujours possible. Aucune mise à jour de sécurité n’est peut-être disponible immédiatement pour les logiciels dont vous dépendez. Ou bien la mise à jour peut entraîner des changements fonctionnels majeurs, appelés « breaking changes », qui modifient la façon dont les personnes ou les systèmes intégrés y accèdent et les utilisent. Les mises à niveau deviennent alors coûteuses, voire souvent irréalisables.

La meilleure solution suivante consiste à appliquer un correctif à vos logiciels. Un correctif de sécurité est une mise à jour logicielle qui résout un problème de sécurité précis tout en modifiant le moins possible les fonctionnalités.

Pour les logiciels propriétaires, le seul moyen d’obtenir un correctif de sécurité est de le recevoir de l’éditeur du logiciel et de l’installer. Windows Update en est un exemple bien connu : le service déploie régulièrement des correctifs de sécurité sur des millions de PC Windows. La gestion des correctifs des éditeurs de logiciels commerciaux est un domaine en plein essor, et de nombreux articles ont été consacrés à la « gestion des correctifs », c’est-à-dire au processus d’obtention, de test et d’application des correctifs de sécurité pour vos applications. De nombreux outils ont été développés pour aider les équipes informatiques à repérer la publication de nouveaux correctifs et à les déployer sur leur parc informatique.

Les logiciels open source deviennent la norme de facto pour de nombreux usages organisationnels, notamment en tant qu’infrastructure pour développer de nouveaux logiciels. L’open source est tout aussi vulnérable que les logiciels propriétaires, mais il n’est pas toujours facile de savoir où trouver un correctif de sécurité pour la dernière vulnérabilité. De plus, de nombreux responsables de projets open source maintiennent leur projet sur leur temps libre. Ainsi, même après la découverte d’une vulnérabilité, le logiciel peut rester longtemps sans mise à jour ni correctif.

Quatre façons de trouver des correctifs de sécurité pour les logiciels open source

1. Mettre à jour ou corriger le logiciel avec l’aide de ses auteurs

Le premier endroit où chercher un correctif est une nouvelle version du logiciel open source vulnérable. Le plus souvent, les vulnérabilités sont corrigées par les responsables de la bibliothèque.

2. Les pull requests

Dans certains cas, des contributeurs open source créent une pull request proposant du code qui peut corriger une vulnérabilité de sécurité. Mais la pull request peut mettre du temps à être intégrée à la version principale du logiciel, quand elle l’est.

Par exemple, la bibliothèque populaire d’analyse Markdown en JavaScript, marked, a présenté une vulnérabilité XSS et a attendu une année entière avant qu’une pull request proposant un correctif soit intégrée à une nouvelle version.

Si une pull request corrige la vulnérabilité, vous pouvez télécharger le code qu’elle propose et l’utiliser comme nouvelle version corrigée. Il existe toutefois un risque que les changements de code proposés ne fonctionnent pas comme prévu ou entraînent des régressions. Il est donc conseillé de vérifier que le nouveau code a été examiné au moins par d’autres membres de la communauté et de le tester avant son déploiement.

3. Créer un fork et corriger le code

Les utilisateurs qui sont eux-mêmes développeurs peuvent créer un fork — leur propre version — du logiciel open source et corriger eux-mêmes la vulnérabilité. Cette approche présente l’avantage d’être fiable : la personne qui apporte le correctif sait qu’elle dispose d’une version stable adaptée à ses besoins et dépourvue de la vulnérabilité.

L’inconvénient, c’est qu’en créant un fork, vous vous coupez des mises à jour et des correctifs de la version principale et risquez, à terme, de vous retrouver dans une situation plus vulnérable. Après tout, de nouvelles vulnérabilités sont découvertes en permanence.

4. Flux de mises à jour

RedHat et Canonical, deux entreprises qui soutiennent l’écosystème Linux, proposent aux utilisateurs Linux un flux de mises à jour comprenant des mises à jour de sécurité.

Le service LivePatch de Canonical applique les correctifs critiques du noyau Ubuntu sans nécessiter le redémarrage du système.

RedHat fournit le gestionnaire de paquets Yum, qui vous permet de mettre à jour n’importe quel paquet Linux vers la dernière version disponible, laquelle inclut souvent des correctifs de sécurité. La commande yum check-update vérifie quels paquets installés disposent de mises à jour, et la commande yum update package les met automatiquement à jour vers leur dernière version.

Le plugin de sécurité Yum indique quelles mises à jour sont liées à la sécurité. Ce plugin est disponible à partir de RedHat Enterprise Linux 5.0 et est intégré à RedHat Enterprise Linux 7.0 et aux versions ultérieures.

Par ailleurs, les gestionnaires de paquets comme npm (Node.js) et Maven (Java) peuvent vous aider à maintenir vos paquets à jour et à installer des mises à jour de sécurité, même s’ils ne détectent pas si une mise à jour est liée à la sécurité.

5. Snyk

Un outil de gestion des vulnérabilités connues devrait faire partie de tout processus de développement open source, mais il est important de vérifier qu’il propose aussi des correctifs. C’est pourquoi nous avons intégré les correctifs à notre offre principale dès le premier jour. Nous gérons notre propre ensemble de correctifs dans notre base de données des vulnérabilités. La plupart sont des rétroportages de correctifs originaux vers des versions antérieures qui restent vulnérables. Certains sont des pull requests testées et intégrées à des correctifs prêts à être installés. D’autres sont rédigés par l’équipe de recherche en sécurité de Snyk.

Vous pouvez intégrer ces correctifs à votre processus de build automatisé à l’aide de l’interface CLI ou même les soumettre à votre projet dans une pull request automatisée. En simplifiant l’application des correctifs, vous pouvez les tester et les déployer rapidement dans le cadre de votre processus habituel.

Conclusion

La plupart des produits logiciels, voire tous, finiront par présenter des vulnérabilités et nécessiteront des mises à jour ou des correctifs. Tout dépend de la rapidité avec laquelle vous pouvez obtenir un correctif qui résout la vulnérabilité et de la facilité avec laquelle vous pouvez l’appliquer.

Pour les logiciels propriétaires, les utilisateurs dépendent des éditeurs, qui répondent progressivement plus rapidement aux problèmes de sécurité. Pour les logiciels open source, une communauté active de responsables de projets constitue la meilleure protection contre les vulnérabilités et autres défauts. Mais dans bien des cas, la communauté open source ne fournira pas le correctif dont vous avez besoin au moment où vous en avez besoin.

Vous pouvez faire l’effort de trouver ou de créer vous-même un correctif, ou faire appel à des fournisseurs comme Canonical, RedHat ou Snyk pour bénéficier d’une correction automatisée. Face à la complexité croissante de l’écosystème open source, nous prévoyons que les outils deviendront un élément essentiel de la posture de sécurité de toute organisation.