Correction des vulnérabilités : un guide pratique
trait de séparation
Temps de lecture : 6 minutes
Qu'est-ce que la correction des vulnérabilités ?
Pour garder une longueur d'avance sur les attaques malveillantes, les développeurs et les équipes de sécurité doivent avoir un moyen d'identifier, de hiérarchiser, de corriger et de surveiller les vulnérabilités, un processus connu sous le nom de correction des vulnérabilités.
En matière de détection, les organisations peuvent utiliser une variété d'outils de test de sécurité des applications (AST) pour identifier les vulnérabilités dans les applications logicielles et d'autres systèmes. Par exemple, les outils d'analyse de la composition logicielle (SCA) vérifient l'intégrité des composants logiciels open source en les comparant aux bases de données de vulnérabilités, aux avis de sécurité ou aux outils de suivi des problèmes dans l'environnement de développement logiciel pour s'assurer qu'ils ne contiennent pas de vulnérabilités.
Lorsqu'un outil AST découvre un problème, l'équipe bloque ou neutralise la vulnérabilité, une étape connue sous le nom de remédiation. La correction peut être aussi simple que l'application d'un correctif logiciel ou aussi difficile que le remplacement d'un groupe de serveurs physiques ou d'appliances matérielles.
L'objectif de la remédiation est de corriger ou de corriger la vulnérabilité avant qu'elle ne devienne une menace pour la sécurité, ce qui peut être complexe à réaliser à grande échelle et de manière continue. Dans une organisation DevSecOps, les équipes de développement, les propriétaires de système, les équipes de sécurité et le personnel d'exploitation doivent travailler ensemble pour construire un processus efficace de remédiation des vulnérabilités.
En matière de détection, les organisations peuvent utiliser une variété d'outils de test de sécurité des applications (AST) pour identifier les vulnérabilités dans les applications logicielles et d'autres systèmes. Par exemple, les outils d'analyse de la composition logicielle (SCA) vérifient l'intégrité des composants logiciels open source en les comparant aux bases de données de vulnérabilités, aux avis de sécurité ou aux outils de suivi des problèmes dans l'environnement de développement logiciel pour s'assurer qu'ils ne contiennent pas de vulnérabilités.
Lorsqu'un outil AST découvre un problème, l'équipe bloque ou neutralise la vulnérabilité, une étape connue sous le nom de remédiation. La correction peut être aussi simple que l'application d'un correctif logiciel ou aussi difficile que le remplacement d'un groupe de serveurs physiques ou d'appliances matérielles.
L'objectif de la remédiation est de corriger ou de corriger la vulnérabilité avant qu'elle ne devienne une menace pour la sécurité, ce qui peut être complexe à réaliser à grande échelle et de manière continue. Dans une organisation DevSecOps, les équipes de développement, les propriétaires de système, les équipes de sécurité et le personnel d'exploitation doivent travailler ensemble pour construire un processus efficace de remédiation des vulnérabilités.
Au sommaire de cet article :
1. Détection de vulnérabilité
2. Priorisation
3. Remédiation
4. Surveillance continue
- Analyse de la composition logicielle (SCA)
- Test de sécurité des applications statiques (SAST)
- Tests dynamiques de sécurité des applications (DAST)
La principale différence entre la correction et l'atténuation est que la correction corrige les vulnérabilités, tandis que l'atténuation s'attaque aux menaces de sécurité résultantes que posent les vulnérabilités, sans nécessairement corriger la vulnérabilité sous-jacente.
Bien que la remédiation soit la solution la plus approfondie et la plus complète, il existe certains cas dans lesquels elle peut ne pas être nécessaire ni possible :
- Parfois, les organisations ne peuvent pas remédier à une vulnérabilité pour des raisons techniques. Par exemple, certaines appliances matérielles peuvent ne pas prendre en charge les mises à niveau logicielles ou les correctifs. Ceci est courant pour les dispositifs médicaux connectés.
- Dans d'autres cas, il peut y avoir une résistance organisationnelle à l'assainissement. Les organisations qui ne pratiquent pas un modèle DevSecOps peuvent être confrontées à des désaccords lorsqu'elles tentent de remédier à des vulnérabilités. Les équipes de développement peuvent prétendre qu'elles n'ont pas le temps de mettre en œuvre la correction, tandis que les équipes en contact avec les clients peuvent être préoccupées par les temps d'arrêt impliqués ou la perturbation de l'activité des clients.
- Lorsque les organisations appliquent une notation prioritaire à la gestion des vulnérabilités , elles peuvent choisir d'atténuer plutôt que de corriger les vulnérabilités à faible risque qui représentent moins de menace. Cela leur permet de donner la priorité à la correction des menaces plus graves ou de libérer du temps pour les développeurs afin qu'ils se concentrent sur leur objectif principal de création d'applications.
Lorsque vous choisissez de corriger ou d'atténuer, il est important de se rappeler que l'atténuation réduira la menace posée par les vulnérabilités, mais ne l'éradiquera pas complètement tant que la vulnérabilité persiste. La remédiation va plus loin et, dans la mesure du possible, devrait être la solution privilégiée. C'est parce qu'en fin de compte, traiter la cause première en remédiant à un problème de sécurité vaut mieux que d'atténuer la menace qui en résulte.
Le processus de correction des vulnérabilités
Des outils de détection, de hiérarchisation et de correction des vulnérabilités sont utilisés pour rechercher, analyser et corriger les vulnérabilités et éradiquer les menaces pesant sur votre code source. Ensemble, ils exécutent un processus de correction des vulnérabilités qui comprend les quatre étapes suivantes :
1. Détection de vulnérabilités
Cela implique d'identifier toutes les failles connues dans le codage ou les configurations système, qu'un attaquant peut exploiter. Vous pouvez détecter les vulnérabilités grâce à des tests et des analyses. Il est crucial de comprendre quels actifs ou systèmes sont exposés.
Un exemple de vulnérabilité logicielle connue est une configuration de contrôle d'accès insuffisante, telle qu'une authentification à facteur unique. Une authentification moins stricte permet à un utilisateur non autorisé d'accéder plus facilement et de lancer, par exemple, une attaque de type "man-in-the-middle".
Idéalement, vous devriez utiliser une approche DevSecOps pour vous assurer que les analyses de vulnérabilité sont effectuées tout au long du cycle de vie du développement logiciel ( SDLC ). À ce stade, vous pouvez également tirer parti d'outils tels que l'analyse de la composition logicielle ( SCA ), les tests de sécurité des applications statiques ( SAST ) ou les tests de sécurité des applications dynamiques ( DAST ).
Toutes les vulnérabilités ne nécessitent pas de correction. Par exemple, si vous découvrez une vulnérabilité dans une fonction qui n'est pas réellement invoquée par le code de votre produit, elle ne peut pas être exploitée et aucune correction n'est nécessaire. Un autre exemple est une vulnérabilité qui n'est pas grave et l'impact de l'exploitation est faible.
2. Priorisation
Cela implique d'identifier les risques posés par les vulnérabilités et de déterminer quels problèmes sont les plus urgents ou nécessitent plus d'attention. Les organisations sont généralement confrontées à trop de vulnérabilités pour être gérées rapidement, et les équipes de sécurité sont limitées en personnel. C'est pourquoi la priorisation est importante.
Les risques peuvent être classés par ordre de priorité en fonction des configurations système, de la probabilité d'un exploit potentiel, de l'impact commercial d'un incident réel et de tout contrôle de sécurité existant. Vous devez isoler vos actifs les plus critiques.
Si l'équipe DevSecOps identifie qu'un système crucial est à risque, vous pouvez donner la priorité à la correction de la vulnérabilité pertinente et répartir la charge de travail au sein de l'équipe. Cela vous aide à éviter de perturber le cycle de vie du développement.
Pour gérer les vulnérabilités open-source , il est recommandé d'utiliser un outil qui agrège les informations des différents référentiels qui listent les vulnérabilités connues. Cela vous aidera à filtrer les alertes de sécurité et à gagner du temps.
Vous pouvez également utiliser des outils SCA avancés pour déterminer si votre code est affecté par un composant vulnérable. Rappelez-vous que la présence d'une vulnérabilité n'entraîne pas toujours un risque significatif. Le moyen avancé d'identifier les vulnérabilités susceptibles d'affecter votre code, Les outils les plus avancés offrent une analyse d'utilisation efficace, consiste à utiliser des solutions qui donnent un aperçu des fonctionnalités spécifiques des composants open source qui affectent réellement votre code.
3. Remédiation
La remédiation corrige les vulnérabilités aussi rapidement que possible. Cela peut impliquer l'application de correctifs, la suppression ou la désactivation de composants vulnérables, la mise à jour de votre système ou de sa configuration, ou le blocage de certaines actions.
Pour le code propriétaire, vous devez identifier la cause première d'une vulnérabilité afin de la corriger. Vous pouvez le faire avec SAST. Vous devrez peut-être combiner des processus de correction automatisés et manuels, et vous pouvez ajouter des mesures de sécurité supplémentaires pour renforcer votre périmètre. Vous devez tester les efforts de correction dans un environnement sécurisé et isolé, tel qu'un bac à sable, plutôt que de travailler entièrement dans l'environnement de production.
Pour les vulnérabilités open source, vous devez tenir compte de la décentralisation et de la nature collaborative de la communauté open source, qui publie souvent des correctifs sur plusieurs plates-formes, il peut donc être difficile de trouver tout le support pertinent en un seul endroit.
L'une des stratégies d'atténuation des risques les plus fiables consiste à maintenir vos composants open source constamment corrigés pour éviter d'être exposés à des vulnérabilités connues. La meilleure façon de maintenir cette stratégie consiste à utiliser des outils de correction automatisés, qui trouveront des correctifs et vous alerteront lorsque de nouveaux correctifs seront publiés. Les outils SCA avancés peuvent recommander le meilleur correctif s'il y en a plusieurs.
La mise à jour d'un seul fichier source n'est pas une solution adéquate pour les menaces plus sophistiquées, vous devrez donc peut-être mettre à jour l'ensemble du composant. Dans certains cas, les nouvelles versions peuvent ne pas être compatibles avec vos autres composants, vous devrez donc compter sur la modification de vos configurations système et le blocage de l'exécution d'actions vulnérables dans vos composants.
4. Surveillance continue
Vous devez surveiller en permanence votre code (et votre inventaire open source) pour détecter les vulnérabilités récemment découvertes. Vous pouvez utiliser des outils automatisés pour fournir des alertes en temps réel et vous permettre de maintenir un processus continu de correction des vulnérabilités.
Des outils de surveillance efficaces doivent hiérarchiser les vulnérabilités en fonction du contexte, ce qui est important pour éviter d'inonder l'équipe DevSecOps d'alertes de faible priorité. Dans une boucle de remédiation continue, cette quatrième étape peut également être considérée comme la première étape du cycle suivant.
1. Détection de vulnérabilités
Cela implique d'identifier toutes les failles connues dans le codage ou les configurations système, qu'un attaquant peut exploiter. Vous pouvez détecter les vulnérabilités grâce à des tests et des analyses. Il est crucial de comprendre quels actifs ou systèmes sont exposés.
Un exemple de vulnérabilité logicielle connue est une configuration de contrôle d'accès insuffisante, telle qu'une authentification à facteur unique. Une authentification moins stricte permet à un utilisateur non autorisé d'accéder plus facilement et de lancer, par exemple, une attaque de type "man-in-the-middle".
Idéalement, vous devriez utiliser une approche DevSecOps pour vous assurer que les analyses de vulnérabilité sont effectuées tout au long du cycle de vie du développement logiciel ( SDLC ). À ce stade, vous pouvez également tirer parti d'outils tels que l'analyse de la composition logicielle ( SCA ), les tests de sécurité des applications statiques ( SAST ) ou les tests de sécurité des applications dynamiques ( DAST ).
Toutes les vulnérabilités ne nécessitent pas de correction. Par exemple, si vous découvrez une vulnérabilité dans une fonction qui n'est pas réellement invoquée par le code de votre produit, elle ne peut pas être exploitée et aucune correction n'est nécessaire. Un autre exemple est une vulnérabilité qui n'est pas grave et l'impact de l'exploitation est faible.
2. Priorisation
Cela implique d'identifier les risques posés par les vulnérabilités et de déterminer quels problèmes sont les plus urgents ou nécessitent plus d'attention. Les organisations sont généralement confrontées à trop de vulnérabilités pour être gérées rapidement, et les équipes de sécurité sont limitées en personnel. C'est pourquoi la priorisation est importante.
Les risques peuvent être classés par ordre de priorité en fonction des configurations système, de la probabilité d'un exploit potentiel, de l'impact commercial d'un incident réel et de tout contrôle de sécurité existant. Vous devez isoler vos actifs les plus critiques.
Si l'équipe DevSecOps identifie qu'un système crucial est à risque, vous pouvez donner la priorité à la correction de la vulnérabilité pertinente et répartir la charge de travail au sein de l'équipe. Cela vous aide à éviter de perturber le cycle de vie du développement.
Pour gérer les vulnérabilités open-source , il est recommandé d'utiliser un outil qui agrège les informations des différents référentiels qui listent les vulnérabilités connues. Cela vous aidera à filtrer les alertes de sécurité et à gagner du temps.
Vous pouvez également utiliser des outils SCA avancés pour déterminer si votre code est affecté par un composant vulnérable. Rappelez-vous que la présence d'une vulnérabilité n'entraîne pas toujours un risque significatif. Le moyen avancé d'identifier les vulnérabilités susceptibles d'affecter votre code, Les outils les plus avancés offrent une analyse d'utilisation efficace, consiste à utiliser des solutions qui donnent un aperçu des fonctionnalités spécifiques des composants open source qui affectent réellement votre code.
3. Remédiation
La remédiation corrige les vulnérabilités aussi rapidement que possible. Cela peut impliquer l'application de correctifs, la suppression ou la désactivation de composants vulnérables, la mise à jour de votre système ou de sa configuration, ou le blocage de certaines actions.
Pour le code propriétaire, vous devez identifier la cause première d'une vulnérabilité afin de la corriger. Vous pouvez le faire avec SAST. Vous devrez peut-être combiner des processus de correction automatisés et manuels, et vous pouvez ajouter des mesures de sécurité supplémentaires pour renforcer votre périmètre. Vous devez tester les efforts de correction dans un environnement sécurisé et isolé, tel qu'un bac à sable, plutôt que de travailler entièrement dans l'environnement de production.
Pour les vulnérabilités open source, vous devez tenir compte de la décentralisation et de la nature collaborative de la communauté open source, qui publie souvent des correctifs sur plusieurs plates-formes, il peut donc être difficile de trouver tout le support pertinent en un seul endroit.
L'une des stratégies d'atténuation des risques les plus fiables consiste à maintenir vos composants open source constamment corrigés pour éviter d'être exposés à des vulnérabilités connues. La meilleure façon de maintenir cette stratégie consiste à utiliser des outils de correction automatisés, qui trouveront des correctifs et vous alerteront lorsque de nouveaux correctifs seront publiés. Les outils SCA avancés peuvent recommander le meilleur correctif s'il y en a plusieurs.
La mise à jour d'un seul fichier source n'est pas une solution adéquate pour les menaces plus sophistiquées, vous devrez donc peut-être mettre à jour l'ensemble du composant. Dans certains cas, les nouvelles versions peuvent ne pas être compatibles avec vos autres composants, vous devrez donc compter sur la modification de vos configurations système et le blocage de l'exécution d'actions vulnérables dans vos composants.
4. Surveillance continue
Vous devez surveiller en permanence votre code (et votre inventaire open source) pour détecter les vulnérabilités récemment découvertes. Vous pouvez utiliser des outils automatisés pour fournir des alertes en temps réel et vous permettre de maintenir un processus continu de correction des vulnérabilités.
Des outils de surveillance efficaces doivent hiérarchiser les vulnérabilités en fonction du contexte, ce qui est important pour éviter d'inonder l'équipe DevSecOps d'alertes de faible priorité. Dans une boucle de remédiation continue, cette quatrième étape peut également être considérée comme la première étape du cycle suivant.
Quels outils peuvent aider à la correction des vulnérabilités ?
Il existe une variété d'outils que vous pouvez utiliser pour trouver et corriger les vulnérabilités. Les scanners de vulnérabilité vous permettent de trouver des vulnérabilités, tandis que les tests de sécurité vous permettent de les analyser et de les hiérarchiser. Ainsi, le déploiement d'une combinaison de ces outils vous protège complètement.
Un scanner de vulnérabilité peut fonctionner à plusieurs niveaux. Il peut scanner :
Examinons ces outils plus en détail.
Un scanner de vulnérabilité peut fonctionner à plusieurs niveaux. Il peut scanner :
- Un hôte complet pour découvrir le système d'exploitation, les logiciels installés sur l'hôte, sa configuration actuelle, les comptes utilisateurs et les ports ouverts. Cela peut révéler des failles de sécurité et fournir des suggestions pour renforcer l'hôte.
- Un conteneur ou une application entière pour identifier les vulnérabilités de n'importe quel composant de l'application.
- Bibliothèques spécifiques pour identifier les vulnérabilités connues ou autres failles de sécurité.
Examinons ces outils plus en détail.
Analyse de la composition logicielle SCA
SCA est un outil d'analyse de code qui aide à identifier les problèmes dans les composants open source et tiers au sein de vos applications.
SCA fonctionne en analysant le code source et en détectant les risques du code tiers et des sources. Il contribue également à la construction d'un package ou d'une nomenclature logicielle (SBOM). La SBOM répertorie les packages utilisés pour développer vos applications. SCA découvre ensuite toutes les vulnérabilités de sécurité qui ont été introduites via ces packages.
Les outils SCA les plus avancés peuvent également aider à établir des priorités . Par exemple, ils peuvent fournir des informations indiquant si une vulnérabilité est réellement exploitable par des attaquants et constitue donc un correctif prioritaire.
La SCA est mieux exploitée dès les premières étapes du développement, à l'extrême gauche du cycle de vie du développement logiciel (SDLC). Cela permet de découvrir les vulnérabilités open source et de les corriger au début du développement, ce qui est beaucoup plus facile et moins coûteux que si elles sont découvertes plus tard.
SCA fonctionne en analysant le code source et en détectant les risques du code tiers et des sources. Il contribue également à la construction d'un package ou d'une nomenclature logicielle (SBOM). La SBOM répertorie les packages utilisés pour développer vos applications. SCA découvre ensuite toutes les vulnérabilités de sécurité qui ont été introduites via ces packages.
Les outils SCA les plus avancés peuvent également aider à établir des priorités . Par exemple, ils peuvent fournir des informations indiquant si une vulnérabilité est réellement exploitable par des attaquants et constitue donc un correctif prioritaire.
La SCA est mieux exploitée dès les premières étapes du développement, à l'extrême gauche du cycle de vie du développement logiciel (SDLC). Cela permet de découvrir les vulnérabilités open source et de les corriger au début du développement, ce qui est beaucoup plus facile et moins coûteux que si elles sont découvertes plus tard.
Test de sécurité des applications statiques SAST
L'analyse statique est une technique mature pour identifier les problèmes de sécurité et de qualité dans le code source personnalisé. L'intégration de l'analyse statique dans le pipeline d'intégration continue/de développement continu peut aider à identifier les vulnérabilités dans les premières étapes du processus de développement logiciel, en utilisant une approche de test en boîte blanche .
SAST recherche automatiquement les vulnérabilités dans le code binaire de l'application, le code source ou les fichiers binaires, ligne par ligne. Cela garantit que les vulnérabilités de sécurité, comme celles présentées dans le Top 25 CWE et le Top 10 OWASP , ne sont pas présentes dans le code source.
SAST avancée peut s'exécuter dans un environnement de développement intégré, fournissant des commentaires aux développeurs pendant qu'ils codent. Les outils SAST peuvent également fonctionner après que les développeurs ont vérifié le code dans un référentiel ou pendant le processus de construction.
L' avantage de l'approche SAST est qu'elle n'a pas besoin d'un système en cours d'exécution lors de l'analyse de la sécurité du code.
SAST recherche automatiquement les vulnérabilités dans le code binaire de l'application, le code source ou les fichiers binaires, ligne par ligne. Cela garantit que les vulnérabilités de sécurité, comme celles présentées dans le Top 25 CWE et le Top 10 OWASP , ne sont pas présentes dans le code source.
SAST avancée peut s'exécuter dans un environnement de développement intégré, fournissant des commentaires aux développeurs pendant qu'ils codent. Les outils SAST peuvent également fonctionner après que les développeurs ont vérifié le code dans un référentiel ou pendant le processus de construction.
L' avantage de l'approche SAST est qu'elle n'a pas besoin d'un système en cours d'exécution lors de l'analyse de la sécurité du code.
Tests dynamiques de sécurité des applications DAST
Les outils DAST interagissent avec les applications pendant leur exécution, essayant de découvrir les vulnérabilités. Les applications doivent s'exécuter sur une machine virtuelle, un conteneur ou un serveur Web, dans un environnement de test ou de production.
Les outils DAST proxysent les communications d'une application web, s'insérant entre le serveur (back-end) et le navigateur (front-end). Ils examinent les demandes et les réponses pour comprendre votre application et son utilisation.
Les outils DAST effectuent une exploration pour identifier toutes les pages d'un site Web ou d'une application Web, y compris les étapes d'authentification et d'autorisation. Ils effectuent ensuite une analyse fuzzing et dynamique pour découvrir les failles de sécurité.
Les outils DAST peuvent fournir des informations précieuses aux développeurs et démontrer que les problèmes de sécurité sont réellement exploitables. Cependant, comme ils sont utilisés plus tard dans le SDLC, lors des phases de test ou de production, le coût de la correction des vulnérabilités découvertes via DAST sera plus élevé.
Les outils DAST proxysent les communications d'une application web, s'insérant entre le serveur (back-end) et le navigateur (front-end). Ils examinent les demandes et les réponses pour comprendre votre application et son utilisation.
Les outils DAST effectuent une exploration pour identifier toutes les pages d'un site Web ou d'une application Web, y compris les étapes d'authentification et d'autorisation. Ils effectuent ensuite une analyse fuzzing et dynamique pour découvrir les failles de sécurité.
Les outils DAST peuvent fournir des informations précieuses aux développeurs et démontrer que les problèmes de sécurité sont réellement exploitables. Cependant, comme ils sont utilisés plus tard dans le SDLC, lors des phases de test ou de production, le coût de la correction des vulnérabilités découvertes via DAST sera plus élevé.
Correction des vulnérabilités avec Mend.io
Avec Mend.io, vous pouvez sécuriser votre organisation en allant au-delà de la simple détection, pour identifier et corriger automatiquement vos vulnérabilités de sécurité open source à chaque étape du cycle de vie du développement logiciel. Et vous pouvez y parvenir en donnant aux développeurs et aux professionnels de la sécurité ce dont ils ont besoin pour gérer la sécurité open source à partir de leurs environnements de développement natifs. Grâce à nos outils et à notre technologie , ils peuvent :
En plus de fournir une sécurité open source de pointe avec notre technologie SCA, Mend propose une solution de sécurité SAST pour votre code personnalisé qui s'intègre à votre environnement DevOps existant et à votre pipeline CI/CD. Son moteur d'analyse produit des résultats jusqu'à 10 fois plus rapides que les solutions SAST traditionnelles. Et il prend en charge 27 langages de programmation différents et divers cadres de programmation différents.
- Détectez tous les composants open source vulnérables, y compris dans vos dépendances transitives, dans plus de 200 langages de programmation
- Donnez la priorité aux vulnérabilités de sécurité open source les plus critiques afin de pouvoir corriger ce qui compte le plus en premier
- Corrigez les vulnérabilités de sécurité en un clic à l'aide de demandes d'extraction générées automatiquement qui identifient la dernière version des composants open source.Mend SCA , qui prend en charge les référentiels GitHub (serveur et cloud), GitLab et Bitbucket (serveur), corrige automatiquement les vulnérabilités open source, tandis queMend SAST est la toute première application de correction automatique conçue pour le code personnalisé.
En plus de fournir une sécurité open source de pointe avec notre technologie SCA, Mend propose une solution de sécurité SAST pour votre code personnalisé qui s'intègre à votre environnement DevOps existant et à votre pipeline CI/CD. Son moteur d'analyse produit des résultats jusqu'à 10 fois plus rapides que les solutions SAST traditionnelles. Et il prend en charge 27 langages de programmation différents et divers cadres de programmation différents.
Ces articles peuvent vous intéresser
SAST vs SCA
7 différences clés pour choisir la solution qui répondra à votre besoin !
Le guide complet de la sécurité Open Source
Demandez l'aperçu complet de toutes les mesures de sécurité à prendre pour l'open source.
Vulnérabilités Open Source - Juillet 2020
Rapport de Juillet : connaitre les ventilations par niveau de criticité, langage ou type de faille des vulnérabilités Open Source
Sécurité des Librairies et Logiciels Open Source
Cet article vous aidera à répondre à la problématique : comment s’assurer de la qualité de ces librairies ?