Dans son dernier rapport, « State of Software Security v11: Open Source Edition », Veracode, spécialiste des tests d'applications, constate que 80 % des bibliothèques tierces incluses dans les logiciels open source ne sont jamais mises à jour, mais également que presque tous les référentiels de code analysés incluaient des bibliothèques avec au moins une vulnérabilité, rapporte The Register.
Or, 92 % de ces problèmes pourraient être corrigés en mettant à jour les bibliothèques tierces vers la dernière version, les deux tiers des correctifs étant « mineurs et non perturbateurs », même pour les applications logicielles les plus complexes.
52 % des développeurs interrogés ont déclaré disposer d'un processus formel pour la sélection de bibliothèques tierces, un quart qu'ils n'étaient pas sûrs ou ignoraient l'existence d'un tel processus, et que la sécurité était la troisième plus grande préoccupation lors de la sélection d'une bibliothèque, après la fonctionnalité et la licence, en tête du classement.
Pour parvenir à ces constats, la société a utilisé les données de 13 millions de scans couvrant 86 000 référentiels, contenant à leur tour plus de 301 000 bibliothèques uniques. Le rapport cite également les réponses de près de 2 000 développeurs.
Commentaires (27)
#1
Mais l’inclusion de bibliothèques tierces, on sait que c’est mal. Ce qu’il faut, c’est une dépendance, et c’est d’autant plus facile quand le code est distribué via une distribution Linux.
#2
Enfin, j’aimerai voir la comparaison avec le logiciel propriétaire ou professionnel (vs savez le truc qu’on a demandé au stagiaire il y a 10 ans et qu’on a jamais retouché, car dans l’ensemble ça marche et qui n’est pas a proprement parlé open source)
#3
On n’est plus dans ce cas depuis longtemps. Maintenant, on te livre des container ou pire, des VM, dont le noyau linux date de 2017 parfois … Et que tu ne peux pas mettre à jour, car on ne te filera pas le mot de passe root et cela casserait le contrat de support…
Mais on te dit que l’outil est opensource (juste que ça compile pas depuis la source présente sur internet - ou que ça se base effectivement sur une version d’une bibliothèque qui n’est pas maintenue/disponible)
#3.1
C’est bien pour ça que moi-même, je ne fais pas de containers. La notion de mise à jour a juste été “oubliée” dans le processus, ce qui est d’une connerie abyssale.
#3.3
Oui j’espère que cette mode va passer, ce système est un non-sens total, ça n’a que des défauts (lourd, opaque, pas sécurisé, pas performant…)
Non pas du tout ! le système de version indique la compatibilité dans sa numérotation “a.b.c” :
Donc le versionning des dépendances c’est >=2.4 par ex : 2.4.12, 2.5.0 ou 2.18 fonctionneront sans ajustement, mais 3.0.1 nécessiterait au moins des tests et peut-être quelques ajustements. (en pratique une version majeure ne signifie pas que tu es nécessairement impacté par les modifications de l’API).
Donc concrètement tu ne dépends que d’une version mineure minimale d’une version majeure donnée, sachant qu’il est souvent possible d’indiquer les dépendances à 2 versions majeures en même temps : On a eu le cas un moment avec python où les dev se sont arrangés pour avoir du code fonctionnant à la fois avec python 2.7 et 3.x
#3.4
Je parlais des dépendances telles que décrites dans les projets les utilisant : dans Qt, Eclipse, avec cocoapods, … le numéro de version est écrit en clair dans un fichier, le compilateur charge la librairie à la première compilation, et par la suite si ce fichier a été modifié (si la version en cours est différente de celle demandée)
#3.5
Bah je pense que c’est la version minimale, si ton projet réfère 1.7.14 et que ta version installée est la 1.9.18 ça va compiler avec ta version sans recharger la vielle 1.7.14. Part contre si t’as 1.7.13 ou 2.0.1 installées ça ne va pas commencer compiler.
C’est ce que fait rust avec cargo : https://doc.rust-lang.org/cargo/guide/dependencies.html
Tu indiques une référence à une version exacte de crate qui est interprété par cargo selon la logique majeur / mineur / correctif : https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
Pour moi, c’est le comportement standard (du moins sous Linux) de la plupart des systèmes de dépendances. C’est ce qui permet d’avoir des distributions compilées en rolling release type Gentoo ou Arch sans devoir éditer chaque projet à chaque mise à jour de librairie.
#3.2
Clair, je ne compte plus, lorsqu’on fait des comparatifs de solutions, les entreprises qui nous proposent des OVA pour tester. Tu l’installes, tu vois une vieille Centos 6, et surtout, ne fais pas d’update, ça pourrait tout casser…
Pour Docker, certains mettent bien à jour les containers etc… Par exemple Bitwarden gère très bien les maj via Docker.
#4
Les dépendance c’est pareil, on doit toujours préciser la version (et en principe la modifier régulièrement). Quand j’interviens sur du Dev c’est parfois un cauchemar car le module A a une dépendance sur B version x, et une dépendance sur C, lequel a une dépendance sur B mais en version y. Là c’est aberrant…
#5
Vérifier que les mises à jour dé sécu (qui arrivent constamment) ne cassent rien est assez consommateur de temps, même si on a des tests automatisés.
Sans compter les erreurs d’identification des systèmes d’inventaire automatisé à corriger à la main.
Faites plaisir aux générations futures de mainteneurs de votre soft: n’utiliser que ce que dont vous avez vraiment besoin.
(Veracode c’est pas donné, également)
#6
Normalement pas, si c’est bien fait au niveau du paquet et du gestionnaire de paquets, ou seulement la version majeure, qui change peu souvent.
En cas de dépendances envers 2 versions majeures, ce qui arrive souvent en période de transition de la précédente vers la nouvelle, il est normalement possible d’installer les deux, mais encore une fois ça va dépendre du gestionnaire de paquets.
Et pour les vieux trucs jamais mis à jour avec des vieilles dépendances, les conteneurs restent la meilleure solution, mais temporaire, il faut songer à trouver un équivalent plus récent.
#7
C’est encore une illustration du de la bibliothèque municipale libre d’accès pour tous mais ou personne ne vient lire.
#8
Autant de temps gagné quand il t’arrive une grosse couille …
#9
#10
En fait, ça existe visiblement (je n’ai jamais fait de docker, je ne fais que du lxc): https://phoenixnap.com/kb/update-docker-image-container
Mais les containers, c’est surtout une parade pour les éditeurs pour ne pas avoir à se soucier des procédures d’installation, de la mise à jour ou même de faire “proprement” les choses…
#11
Lu sur cette page :
“The best way to update an existing container with the newest image is to download the latest image and launch a new container with the same configuration.”
bref, tu télécharges un nouveau container, et tu le mets à la place. Ça ne marchera qui si le container n’a pas d’état interne, sinon tu te démerdes pour migrer les données.
#11.1
Les volumes répondent précisément à cette problématique.
#12
Merci Alex, je me sent moins seul du coup :)
#13
Dans la même catégorie : les images de base des containers qui ne sont jamais mises à jour.
Raison pour laquelle on a arrêté de prendre ce que les dev nous filent et qu’on construit depuis les sources.
C’est aussi l’un des soucis quand la démarche DevOps est mal appliquée en entreprise avec le travers du “dev tout puissant” qui livre un package prêt à l’emploi (bon pour le TTM) mais troué jusqu’à la moelle (pas bon pour la sécu) parce qu’il n’est pas forcément le plus compétent dans le domaine de la sécurisation du déploiement.
Même si aujourd’hui on parle de DevSecOps, la sécurité ça reste un vrai métier et elle travaille conjointement avec toutes les parties. Le hic est quand on a des responsables sécurité qui réfléchissent “bloquer” et non “accompagner pour faire mieux”, ce qui engendre des comportements antagonistes contre productifs… (et provoque du bypass, ce qui fait pire que mieux)
#14
C’est un poil plus compliqué que ça. Il ne t’aura pas échappé que, souvent, un processus d’upgrade fait un peu plus que changer l’image des binaires (et conserver les données). Il faut souvent appeler des scripts de post-install qui vont convertir les schémas de données, upgrader les format de base de données, changer le layout des fichiers le cas échéant (ça arrive…), etc.
#14.1
Ce problème n’est pas lié aux containers et dans le pire des cas, il n’y a ni problème ni difficulté à appeler manuellement un script qui se situe à l’intérieur du container.
Quelques logiciels gèrent d’ailleurs eux même les migrations lorsqu’un container est déployé, comme Nextcloud par exemple.
#15
Bien sûr, la mise à jour n’est pas impossible : elle est juste équivalente à une réinstallation, avec intervention manuelle pour savoir ce qu’il faut mettre à jour, pour déployer le binaire, et pour faire la post-install.
C’est dommage parce que c’est quelque chose qui est géré automatiquement par tous les systèmes de packaging. Avec les containers, on n’est pas très loin de la situation des années 90 où on te fournissais un tar.gz que tu déballais manuellement, en te démerdant pour les dépendances, les notifications de mise à jour, et la migration effective. Bon, ok, le container règle le problème des dépendances (de façon sale, en dupliquant tout), mais pour le reste, quel retour en arrière !
#15.1
Effectivement, dit comme ça, je comprend mieux ce qui te pose problème.
Je nuancerai juste ton propos en rappelant que les systèmes de packaging ne font pas de magie : il exécutent des scripts qui ont été écrits spécifiquement pour eux et pour chaque package.
Si le logiciel X fait une migration de données automatiquement, c’est bien qu’un script a été écrit spécifiquement pour ce logiciel et qu’il est exécuté (par le système de packaging ou pas).
La difficulté actuelle, c’est qu’il faut re-écrire les scripts pour les adaptés au système de containers.
Et je nuancerai aussi la question de la duplication de dépendance. Si plusieurs containers se basent sur la même image de base, cette image de base n’est pas dupliquée sur le disque (ni les couches intermédiaires en fait). Si tu lances 90 containers MySQL sur la même machines, tu n’as pas 90 fois l’image dupliquée.
Et pour rebondir sur la niouse, ce système permet du coup de très facilement mettre à jour les dépendances car on n’a pas à se soucier de savoir si ce qu’on va modifier va être compatible ou pas avec ce qui est déjà déployé. (Oh non, je peux pas mettre javaX IBM car JavaX Oracle est déjà présent, oh non, c’est openSSL N qui est installé et on a besoin de openSSL N+1, etc)
#16
Oui, c’est clair. Mais parfois on est sur une pyramide de dépendances, et une branche peut être mise à jour, pas l’autre…
#17
Et si tu as 10 images qui dépendent de Java, tu auras 10 copies de JDK. Ça va quand tu ne paies pas le disque, mais sinon…
#17.1
Si tu as 10 images qui se basent sur la même image de java, tu as une seule copie.
Si tu as 10 images qui se basent sur 10 images de java différentes , tu as 10 copies du JRE.
Les containers marchent par couche. Les couches ne sont jamais dupliquées.
En clair, si tu as 50 images qui commencent par exemple par :
FROM openjdk
alors tu as une seule fois openjdk
sur ton disque, y compris au runtime.
#17.2
N’importe quoi