DevSecOps : principes de fonctionnement et comparaison SCA. Partie un

L'importance de l'analyse des composants tiers logiciels (en anglais Software Composition Analysis — SCA) dans le processus de développement augmente à mesure que les rapports annuels sur les vulnérabilités des bibliothèques open source, publiés par des entreprises comme Synopsys, Sonatype, Snyk et White Source, voient le jour. Selon le rapport L'État des vulnérabilités de sécurité open source 2020 , le nombre de vulnérabilités identifiées dans l'open source en 2019 a presque doublé par rapport à l'année précédente, alors que les composants open source sont utilisés dans 60 à 80 % des projets. En se basant sur un avis indépendant, les processus SCA sont considérés comme une pratique distincte dans l'OWASP SAMM et le BSIMM comme indicateur de maturité, et au premier semestre 2020, l'OWASP a publié une nouvelle norme, la OWASP Software Component Verification Standard (SCVS), fournissant des meilleures pratiques pour la vérification des composants tiers dans la chaîne d'approvisionnement logicielle.

Un des cas les plus révélateurs s'est produit avec l'entreprise Equifax en mai 2017. Des cybercriminels inconnus ont accédé aux informations de 143 millions d'Américains, y compris des noms complets, des adresses, des numéros de sécurité sociale et de permis de conduire. Dans 209 000 cas, les documents contenaient également des informations sur les cartes bancaires des victimes. Cette fuite a eu lieu à la suite de l'exploitation d'une vulnérabilité critique dans Apache Struts 2 (CVE-2017-5638), alors qu'un correctif avait été publié en mars 2017. L'entreprise avait deux mois pour appliquer la mise à jour, mais cela n'a pas été fait.

Cet article discutera de la question du choix d'un outil pour la réalisation de SCA en termes de qualité des résultats de l'analyse. Une comparaison fonctionnelle des outils sera également présentée. Le processus d'intégration dans CI/CD et les possibilités d'intégration seront abordés dans de prochaines publications. Une large liste d'outils a été présentée par l'OWASP sur son site, mais dans le cadre de cette revue, nous aborderons uniquement l'outil open source le plus populaire, Dependency Check, la plateforme open source moins connue Dependency Track et la solution d'entreprise Sonatype Nexus IQ. Nous examinerons également le fonctionnement de ces solutions et comparerons les résultats obtenus en termes de faux positifs.

Principe de fonctionnement

Dependency Check — c'est un utilitaire (CLI, maven, module jenkins, ant) qui analyse les fichiers du projet, collecte des fragments d'informations sur les dépendances (nom du package, groupid, titre de la spécification, version…), construit une chaîne CPE — (Common Platform Enumeration), Package URL (PURL) et identifie les vulnérabilités pour CPE/PURL à partir des bases de données (NVD, Sonatype OSS Index, API NPM Audit…), puis génère un rapport unique au format HTML, JSON, XML…

Voyons à quoi ressemble un CPE :

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

• Partie : Indication que le composant se rapporte à une application (a), un système d'exploitation (o), du matériel (h) (Élément obligatoire)
• Fournisseur : Nom du fabricant du produit (Élément obligatoire)
• Produit : Nom du produit (Élément obligatoire)
• Version : Version du composant (Élément obsolète)
• Mise à jour : Mise à jour du package
• Édition : Version héritée (Élément obsolète)
• Langue : Langue définie dans RFC-5646
• Édition SW : Version du logiciel
• SW cible : Environnement logiciel dans lequel le produit fonctionne
• HW cible : Environnement matériel dans lequel le produit fonctionne
• Autre : Informations sur le fournisseur ou le produit

Un exemple de CPE est le suivant :

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

Cette chaîne signifie que le CPE version 2.3 décrit un composant d'application du fabricant pivotal_software nommé spring_framework version 3.0.0. Si nous ouvrons la vulnérabilité CVE-2014-0225 dans le NVD, nous pouvons voir cette référence CPE. Le premier problème sur lequel il faut immédiatement se concentrer — le CVE dans le NVD, selon le CPE, indique un problème dans le framework et non dans un composant spécifique. Autrement dit, si les développeurs sont fortement attachés au framework, et la vulnérabilité identifiée ne concerne pas les modules utilisés par les développeurs, l'expert en sécurité devra de toute façon examiner ce CVE et envisager une mise à jour.

L'URL est également utilisée par les outils SCA. Le format d'URL du package est le suivant :

scheme:type/namespace/name@version?qualifiers#subpath

• Schème : Sera toujours ‘pkg’, indiquant qu'il s'agit d'une URL de package (Élément obligatoire)
• Type : Le « type » du package ou le « protocole » du package, par exemple maven, npm, nuget, gem, pypi, etc. (Élément obligatoire)
• Namespace : Un certain préfixe de nom, tel que l'identifiant de groupe Maven, le propriétaire de l'image Docker, l'utilisateur ou l'organisation GitHub. Non obligatoire et dépend du type.
• Nom : Nom du package (Élément obligatoire)
• Version : Version du package
• Qualificateurs : Informations supplémentaires sur les qualifications pour le package, telles que le système d'exploitation, l'architecture, la distribution, etc. Optionnel et dépendant du type d'élément.
• Sous-chemin : Chemin supplémentaire dans le package par rapport à la racine du package

Par exemple :

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Track — plateforme web sur site qui accepte les listes de matériaux (BOM) prêtes générées CycloneDX et SPDX, c'est-à-dire des spécifications prêtes concernant les dépendances existantes. Il s'agit d'un fichier XML décrivant les dépendances : nom, hachages, URL du package, éditeur, licence. Ensuite, Dependency Track analyse le BOM, examine les dépendances pour identifier les CVE de la base de données des vulnérabilités (NVD, Sonatype OSS Index…), puis construit des graphiques, calcule des métriques, mettant à jour régulièrement les données sur l'état des vulnérabilités des composants.

Exemple de ce à quoi pourrait ressembler un BOM au format XML :

Apache
      org.apache.tomcat
      tomcat-catalina
      9.0.14
      
        3942447fac867ae5cdb3229b658f4d48
        e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a
        f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b
        e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282
      
      
        
          Apache-2.0
        
      
      pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14
    
      

Le BOM peut être utilisé non seulement comme paramètres d'entrée pour Dependency Track, mais aussi pour l'inventaire des composants logiciels dans la chaîne d'approvisionnement, par exemple, pour fournir au client du logiciel. En 2014, un projet de loi a même été proposé aux États-Unis « Cyber Supply Chain Management and Transparency Act of 2014 », qui stipulait que lors de l'achat de logiciels, toute institution gouvernementale devait demander un BOM pour éviter l'utilisation de composants vulnérables, mais ce projet de loi n'a jamais été adopté.

Revenant à SCA, Dependency Track a des intégrations prêtes avec des plateformes de notification comme Slack, des systèmes de gestion des vulnérabilités comme Kenna Security. Notons également que Dependency Track identifie les versions obsolètes des packages et fournit des informations sur les licences (grâce au support de SPDX).

Lorsqu'il s'agit précisément de la qualité SCA, il y a une différence fondamentale.

Dependency Track n'accepte pas le projet comme entrée, mais prend en charge le BOM. Cela signifie que si nous voulons vérifier le projet, nous devons d'abord générer le bom.xml, par exemple, avec CycloneDX. Ainsi, Dependency Track dépend directement de CycloneDX. En même temps, cela permet une personnalisation. Ainsi, l'équipe d'OZON a écrit le module CycloneDX pour générer des fichiers BOM pour des projets en Golang dans le but de les scanner ultérieurement via Dependency Track.

Nexus IQ est une solution SCA commerciale de Sonatype, qui fait partie de l'écosystème Sonatype, qui comprend également Nexus Repository Manager. Nexus IQ peut accepter en entrée à la fois des archives war (pour des projets Java) via une interface web ou une API, ainsi que des BOM, si votre organisation n'a pas eu le temps de se réadapter de CycloneDX à cette nouvelle solution. Contrairement aux solutions open source, IQ ne se limite pas à interroger le CP/PURL de la composante identifiée et à la vulnérabilité correspondante dans la base de données, mais prend également en compte ses propres recherches, par exemple, le nom de la fonction ou de la classe vulnérable. Les mécanismes d'IQ seront examinés plus tard lors de l'analyse des résultats.

Récapitulons certaines fonctionnalités fonctionnelles et examinons les langages pris en charge pour l'analyse :

Langue
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Fonctionnalités disponibles

Fonctionnalités disponibles
Nexus IQ
Dependency Check
Dependency Track

Capacité à assurer la vérification des composants utilisés dans le code source pour leur conformité aux licences
+
—
+

Capacité à scanner et analyser les images Docker pour détecter les vulnérabilités et la conformité aux licences
+ Intégration avec Clair
—
—

Capacité à configurer une politique de sécurité pour l'utilisation de bibliothèques open source
+
—
—

Capacité à scanner les dépôts open source pour détecter les composants vulnérables
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Présence d'un groupe de recherche spécialisé
+
—
—

Travail dans un environnement fermé
+
+
+

Utilisation de bases de données tierces
+ Base de données fermée Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, support de la base de données de vulnérabilités interne

Capacité à filtrer les composants open source lors de la tentative de chargement dans l'environnement de développement selon les politiques configurées
+
—
—

Recommandations pour corriger les vulnérabilités, disponibilité de liens vers les correctifs
+
+- (dépend de la description dans les bases de données publiques)
+- (dépend de la description dans les bases de données publiques)

Classement des vulnérabilités détectées par degré de criticité
+
+
+

Modèle de rôle d'accès
+
—
+

Support de l'interface en ligne de commande (CLI)
+
+
+- (uniquement pour CycloneDX)

Filtrage / tri des vulnérabilités selon des critères définis
+
—
+

Dashboard sur l'état des applications
+
—
+

Génération de rapports au format PDF
+
—
—

Génération de rapports au format JSONCSV
+
+
—

Support de la langue russe
—
—
—

Capacités d'intégration

Intégration
Nexus IQ
Dependency Check
Dependency Track

Intégration avec LDAP/Active Directory
+
—
+

Intégration avec le système d'intégration continue (continous integration) Bamboo
+
—
—

Intégration avec le système d'intégration continue (continous integration) TeamCity
+
—
—

Intégration avec le système d'intégration continue (continous integration) GitLab
+
+- (sous forme de plugin pour GitLab)
+

Intégration avec le système d'intégration continue (continous integration) Jenkins
+
+
+

Disponibilité de plugins pour IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Support d'intégration personnalisée via des services web (API) de l'outil
+
—
+

Dependency Check

Premier lancement

Lançons une vérification des dépendances sur une application intentionnellement vulnérable DVJA.

Pour cela, utilisons Plugin Maven pour la vérification des dépendances:

mvn org.owasp:dependency-check-maven:check

En conséquence, un fichier dependency-check-report.html apparaîtra dans le répertoire target.

Ouvrons le fichier. Après un aperçu des vulnérabilités, nous pouvons voir des informations sur les vulnérabilités avec un niveau élevé de gravité et de confiance, indiquant le paquet, CPE, et le nombre de CVE.

Ensuite, nous obtenons des informations plus détaillées, notamment la base sur laquelle la décision a été prise (preuve), c'est-à-dire un certain BOM.

Nous avons ensuite le CPE, le PURL et la description CVE. Les recommandations de correction ne sont d'ailleurs pas fournies en raison de leur absence dans la base NVD.

Pour un examen systématique des résultats du scan, vous pouvez configurer Nginx avec des réglages minimaux, ou envoyer les défauts obtenus vers un système de gestion des défauts qui prend en charge les connecteurs avec Dependency Check. Par exemple, Defect Dojo.

Dependency Track

Installation

Dependency Track, quant à lui, est une plateforme web avec des graphiques affichants, donc la question aiguë de stockage des défauts dans une solution tierce ne se pose pas ici.
Pour l'installation, les scénarios supportés sont les suivants : Docker, WAR, Exécutable WAR.

Premier lancement

Accédez à l'URL du service en cours d'exécution. Connectez-vous avec admin/admin, changez le nom d'utilisateur et le mot de passe, après quoi vous accédez au Dashboard. La prochaine chose que nous allons faire est de créer un projet pour une application Java de test dans Home/Projects → Créer un projet . Prenons DVJA comme exemple.

Puisque Dependency Track peut n'accepter que des BOM en entrée, il est nécessaire d'obtenir ce BOM. Utilisons CycloneDX Maven Plugin:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Nous obtenons bom.xml et téléchargeons le fichier dans le projet créé DVJA → Dépendances → Télécharger BOM.

Accédons à Administration → Analyseurs. Nous constatons que seul l'Analyseur Interne, qui inclut le NVD, est activé. Connectons également Sonatype OSS Index.

Ainsi, nous obtenons l'image suivante pour notre projet :

On peut également trouver une vulnérabilité applicable à Sonatype OSS dans la liste :

La principale déception était que Dependency Track n'accepte plus les rapports xml de Dependency Check. Les dernières versions prises en charge pour l'intégration avec Dependency Check étaient 1.0.0 - 4.0.2, tandis que je testais la version 5.3.2.

Voici vidéo (et voici), quand cela était encore possible.

Nexus IQ

Premier lancement

L'installation de Nexus IQ se fait à partir d'archives via documentation, mais pour ces objectifs, nous avons créé une image Docker.

Après s'être connecté à la console, il est nécessaire de créer une Organisation et une Application.

Comme on peut le voir, la configuration dans le cas d'IQ est un peu plus complexe, car nous devons également créer des politiques applicables à différentes "étapes" (dev, build, stage, release). Cela est nécessaire pour bloquer les composants vulnérables au fur et à mesure qu'ils avancent dans le pipeline vers la production, ou les bloquer dès qu'ils entrent dans le Nexus Repo lors du téléchargement par les développeurs.

Pour ressentir la différence entre open source et entreprise, faisons une analyse identique via Nexus IQ de la même manière que plugin Maven, après avoir d'abord créé une application de test dans l'interface NexusIQ dvja-test-and-compare:

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl= -Dclm.username= -Dclm.password=

Accédez à l'URL du rapport généré dans l'interface web d'IQ :

Vous pouvez voir ici toutes les violations de politique avec des niveaux de gravité différents (de Info à Critique de Sécurité). La lettre D à côté d'un composant indique que le composant est une Dépendance Directe, tandis que la lettre T indique qu'il s'agit d'une Dépendance Transitive.

Au fait, le rapport State of Open Source Security Report 2020 de Snyk rapporte que plus de 70 % des vulnérabilités open source détectées dans Node.js, Java et Ruby se trouvent dans les dépendances transitives.

Si nous ouvrons l'une des violations de la politique Nexus IQ, nous pouvons voir la description du composant, ainsi que le Graphique de Versions qui montre la position de la version actuelle sur la chronologie, ainsi que le moment où la vulnérabilité cesse d'être critiquable. La hauteur des bougies sur le graphique indique la popularité d'utilisation de ce composant.

Si nous allons dans la section des vulnérabilités et développons le CVE, nous pouvons lire la description de cette vulnérabilité, les recommandations pour la corriger, ainsi que la raison pour laquelle ce composant a été signalé pour violation, c'est-à-dire la présence de la classe DiskFileitem.class.

Faisons le point uniquement sur les composants Java tiers, en excluant les composants js. Nous indiquerons entre parenthèses le nombre de vulnérabilités trouvées en dehors du NVD.

Total Nexus IQ :

• Dépendances analysées : 62
• Dépendances vulnérables : 16
• Vulnérabilités trouvées : 42 (8 base de données sonatype)

Total Vérification des Dépendances :

• Dépendances analysées : 47
• Dépendances vulnérables : 13
• Vulnérabilités trouvées : 91 (14 sonatype oss)

Total Suivi des Dépendances :

• Dépendances analysées : 59
• Dépendances vulnérables : 10
• Vulnérabilités trouvées : 51 (1 sonatype oss)

La prochaine étape consistera à analyser les résultats obtenus et à déterminer lesquelles de ces vulnérabilités représentent un véritable défaut et lesquelles sont de faux positifs.

Avertissement

Cette revue n'est pas une vérité incontestable. L'objectif de l'auteur n'était pas de mettre en avant un outil par rapport aux autres. Le sens de cette revue était de montrer les mécanismes de fonctionnement des outils SCA et les moyens de vérifier leurs résultats.

Comparaison des résultats

Conditions :

Un faux positif par rapport aux vulnérabilités des composants tiers est :

• Non-conformité du CVE au composant identifié
• Par exemple, si une vulnérabilité est trouvée dans le framework struts2, mais que l'outil pointe vers le composant du framework struts-tiles, qui n'est pas concerné par cette vulnérabilité, alors c'est un faux positif.
• Non-conformité du CVE à la version du composant identifiée
• Par exemple, si la vulnérabilité est liée à la version python > 3.5 et que l'outil signale la version 2.7 comme vulnérable — c'est un faux positif, car en réalité, la vulnérabilité ne concerne que la branche de produit 3.x.
• Duplication de CVE
• Par exemple, si le SCA a désigné un CVE permettant de réaliser un RCE, puis que le SCA indique pour ce même composant un CVE applicable aux produits Cisco, vulnérables à ce RCE. Dans ce cas, il s'agira d'un faux positif.
• Par exemple, une CVE a été trouvée dans le composant spring-web, après quoi la SCA indique cette même CVE dans d'autres composants du framework Spring, tandis que la CVE n'a rien à voir avec d'autres composants. Dans ce cas, cela sera un faux positif.

Le projet Open Source DVJA a été choisi comme objet de l'étude. Seuls les composants Java ont été inclus dans l'étude (sans js).

Résultats récapitulatifs

Passons directement aux résultats de la révision manuelle des vulnérabilités identifiées. Le rapport complet pour chaque CVE est disponible en annexe.

Résultats récapitulatifs pour toutes les vulnérabilités :

Paramètre
Nexus IQ
Dependency Check
Dependency Track

Vulnérabilités identifiées au total
42
91
51

Vulnérabilités identifiées à tort (faux positifs)
2(4.76%)
62(68,13%)
29(56.86%)

Aucune vulnérabilité pertinente détectée (faux négatifs)
10
20
27

Résultats récapitulatifs par composants :

Paramètre
Nexus IQ
Dependency Check
Dependency Track

Total des composants identifiés
62
47
59

Total des composants vulnérables
16
13
10

Composants vulnérables identifiés à tort (faux positifs)
1
5
0

Composants vulnérables identifiés à tort (faux positifs)
0
6
6

Construisons des graphiques visuels pour évaluer le rapport entre faux positifs et faux négatifs par rapport au nombre total de vulnérabilités. Les composants sont marqués horizontalement, tandis que les vulnérabilités identifiées sont marquées verticalement.

Pour comparer, une étude similaire a été réalisée par l'équipe de Sonatype testant un projet comportant 1531 composants à l'aide d'OWASP Dependency Check. Comme nous pouvons le voir, le rapport de bruit par rapport aux déclenchements corrects est comparable à nos résultats.

Source : www.sonatype.com/why-precision-matters-ebook

Examinons certaines CVE des résultats de notre scan pour comprendre la raison de tels résultats.

En savoir plus

№1

Commençons par certains points intéressants sur Sonatype Nexus IQ.

Nexus IQ signale un problème de désérialisation avec la possibilité d'exécuter du RCE dans le Spring Framework à plusieurs reprises. CVE-2016-1000027 dans spring-web:3.0.5 pour la première fois, et CVE-2011-2894 dans spring-context:3.0.5 et spring-core:3.0.5. Au début, il semble qu'il y ait un doublon de vulnérabilité lié à plusieurs CVE. En effet, si nous consultons la CVE-2016-1000027 et la CVE-2011-2894 dans la base de données NVD, il semble que tout soit évident.

Composant
Vulnérabilité

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Description CVE-2011-2894 du NVD :


Description CVE-2016-1000027 du NVD :


La CVE-2011-2894 est déjà bien connue. Dans le rapport White Source de 2011 cette CVE a été considérée comme l'une des plus fréquentes. Les descriptions pour la CVE-2016-100027 sont en fait limitées dans le NVD, et elle semble ne s'appliquer qu'au Spring Framework 4.1.4. Regardons donc reference et cela devient plus ou moins clair. Dans l'article de Tenable nous comprenons qu'en plus de la vulnérabilité dans RemoteInvocationSerializingExporter dans la CVE-2011-2894, la vulnérabilité est également observée dans HttpInvokerServiceExporter. C'est ce que Nexus IQ nous indique :

Cependant, rien de tel ne figure dans la NVD, ce qui conduit Dependency Check et Dependency Track à obtenir de faux négatifs.

De plus, la description de CVE-2011-2894 montre que la vulnérabilité est effectivement présente dans spring-context:3.0.5 et spring-core:3.0.5. Une confirmation se trouve dans l'article de la personne qui a découvert cette vulnérabilité.

№2

Composant
Vulnérabilité
Résultat

struts2-core:2.3.30
CVE-2016-4003
FAUX

Si nous étudions la vulnérabilité CVE-2016-4003, nous comprendrons qu'elle a été corrigée dans la version 2.3.28, cependant Nexus IQ nous informe à son sujet. La description de la vulnérabilité contient la note :

Cela signifie que la vulnérabilité existe uniquement en combinaison avec une version obsolète de JRE, ce dont nous avons été avertis. Néanmoins, nous considérons cela comme un faux positif, même si ce n'est pas le plus grave.

№ 3

Composant
Vulnérabilité
Résultat

xwork-core:2.3.30
CVE-2017-9804
VRAI

xwork-core:2.3.30
CVE-2017-7672
FAUX

Si nous regardons la description de CVE-2017-9804 et CVE-2017-7672, nous comprendrons que le problème réside dans la classe URLValidator, et que CVE-2017-9804 découle de CVE-2017-7672. La présence de la seconde vulnérabilité n'apporte aucune valeur ajoutée si ce n'est que sa sévérité a été augmentée à élevée, donc cela peut être considéré comme un bruit supplémentaire.

En général, aucun autre faux positif n'a été trouvé pour Nexus IQ.

№4

Il y a plusieurs points qui distinguent IQ des autres solutions.

Composant
Vulnérabilité
Résultat

spring-web:3.0.5
CVE-2020-5398
VRAI

Le CVE dans la NVD indique qu'il s'applique uniquement aux versions 5.2.x jusqu'à 5.2.3, 5.1.x jusqu'à 5.1.13, et aux versions 5.0.x jusqu'à 5.0.16, cependant, si nous regardons la description du CVE dans Nexus IQ, nous voyons ce qui suit :
Avis de déviation : L'équipe de recherche en sécurité de Sonatype a découvert que cette vulnérabilité a été introduite dans la version 3.0.2.RELEASE et non 5.0.x comme indiqué dans l'avis.

Après cela, il y a un PoC pour cette vulnérabilité, indiquant qu'elle est présente dans la version 3.0.5.

Le faux négatif est envoyé à Dependency Check et Dependency Track.

№5

Examinons le faux positif pour Dependency Check et Dependency Track.

Dependency Check se distingue par le fait qu'il reflète les CVE qui correspondent à l'ensemble du framework dans la NVD, dans les composants auxquels ces CVE ne s'appliquent pas. Cela concerne CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, que Dependency Check a « attaché » à struts-taglib:1.3.8 et struts-tiles-1.3.8. Ces composants n'ont rien à voir avec ce qui est décrit dans le CVE — traitement des requêtes, validation des pages, etc. Cela est dû au fait que la seule chose en commun entre ces CVE et les composants est le framework, c'est pourquoi Dependency Check a considéré cela comme une vulnérabilité.

La même situation se présente avec spring-tx:3.0.5, et une situation similaire avec struts-core:1.3.8. Pour struts-core, Dependency Check et Dependency Track ont trouvé de nombreuses vulnérabilités qui s'appliquent en réalité à struts2-core, qui est en fait un framework distinct. Dans ce cas, Nexus IQ a correctement compris la situation et dans les CVE qu'il a émis, il a indiqué que struts-core était en fin de vie et qu'il fallait passer à struts2-core.

Numéro 6

Dans certaines situations, il est injuste d'interpréter une erreur explicite de Dependency Check et Dependency Track. En particulier, CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, qui ont été attribués à spring-core:3.0.5 par Dependency Check et Dependency Track, se rapportent en réalité à spring-web:3.0.5. De plus, certaines de ces CVE ont également été trouvées par Nexus IQ, qui les a correctement associées à un autre composant. Le fait que ces vulnérabilités n'aient pas été détectées dans spring-core ne signifie pas qu'elles n'existent pas dans le framework en général et les outils open source ont justement signalé ces vulnérabilités (ils ont simplement légèrement manqué leur cible).

Conclusions

Comme nous pouvons le voir, la détermination de la véracité des vulnérabilités identifiées par une révision manuelle ne produit pas de résultats clairs, ce qui entraîne des points de débat. Les résultats montrent que la solution Nexus IQ a le taux de faux positifs le plus bas et la plus grande précision.

Tout d'abord, cela est dû au fait que l'équipe de Sonatype a élargi la description de chaque vulnérabilité CVE du NVD dans ses bases de données, en précisant au niveau de la classe ou de la fonction de la vulnérabilité pour chaque version du composant, après avoir mené des recherches supplémentaires (par exemple, en testant des vulnérabilités sur des versions plus anciennes des logiciels).

Les vulnérabilités qui ne figurent pas dans le NVD, mais qui sont toutefois présentes dans la base Sonatype avec l'étiquette SONATYPE, ont également une influence non négligeable sur les résultats. Selon le rapport L'État des vulnérabilités de sécurité open source 2020 45% des vulnérabilités open source découvertes ne sont pas signalées dans le NVD. Selon la base de données WhiteSource, seulement 29% de toutes les vulnérabilités open source, enregistrées en dehors du NVD, finissent par être publiées, c'est pourquoi il est si important de rechercher les vulnérabilités aussi dans d'autres sources.

En conclusion, Dependency Check génère un grand bruit, tout en négligeant certaines parties vulnérables des composants. Dependency Track génère moins de bruit et identifie un grand nombre de composants, ce qui ne choque pas visuellement dans l'interface web.

Cependant, la pratique montre que l'open source devrait être le premier pas vers une maturité DevSecOps. La première chose à considérer pour intégrer le SCA dans le développement est les processus, à savoir réfléchir en collaboration avec la direction et les départements concernés sur la manière dont les processus idéaux devraient se présenter dans votre organisation. Il se peut que pour votre organisation, au départ, Dependency Check ou Dependency Track répondent à tous les besoins commerciaux, tandis que les solutions Enterprise seraient une suite logique en raison de la complexité croissante des applications développées.

Annexe A. Résultats concernant les composants
Légende :

• High — vulnérabilités de niveau élevé et critique dans le composant
• Medium — vulnérabilités de niveau moyen dans le composant
• TRUE — vulnérabilité correctement identifiée (True positive issue)
• FALSE — faux positif (False positive issue)

Composant
Nexus IQ
Dependency Check
Dependency Track
Résultat

dom4j: 1.6.1
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

log4j-core: 2.3
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

log4j: 1.2.14
Couverture d'ombre du soleil
Couverture d'ombre du soleil
—
VRAI

commons-collections:3.1
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

commons-fileupload:1.3.2
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

commons-beanutils:1.7.0
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

commons-codec:1:10
Élevé
—
—
VRAI

mysql-connector-java:5.1.42
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

spring-expression:3.0.5
Couverture d'ombre du soleil
composant non trouvé

VRAI

spring-web:3.0.5
Couverture d'ombre du soleil
composant non trouvé
Couverture d'ombre du soleil
VRAI

spring-context:3.0.5
Élevé
composant non trouvé
—
VRAI

spring-core:3.0.5
Élevé
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

struts2-config-browser-plugin:2.3.30
Élevé
—
—
VRAI

spring-tx:3.0.5
—
Couverture d'ombre du soleil
—
FAUX

struts-core:1.3.8
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

xwork-core: 2.3.30
Couverture d'ombre du soleil
—
—
VRAI

struts2-core: 2.3.30
Couverture d'ombre du soleil
Couverture d'ombre du soleil
Couverture d'ombre du soleil
VRAI

struts-taglib:1.3.8
—
Couverture d'ombre du soleil
—
FAUX

struts-tiles-1.3.8
—
Couverture d'ombre du soleil
—
FAUX

Annexe B. Résultats concernant les vulnérabilités
Légende :

• High — vulnérabilités de niveau élevé et critique dans le composant
• Medium — vulnérabilités de niveau moyen dans le composant
• TRUE — vulnérabilité correctement identifiée (True positive issue)
• FALSE — faux positif (False positive issue)

Composant
Nexus IQ
Dependency Check
Dependency Track
Sévérité
Résultat
Commentaire

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Couverture d'ombre du soleil
VRAI

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Couverture d'ombre du soleil
VRAI

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Couverture d'ombre du soleil
VRAI

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Faible
VRAI

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Couverture d'ombre du soleil
VRAI

—
CVE-2020-9488
—
Faible
VRAI

SONATYPE-2010-0053
—
—
Couverture d'ombre du soleil
VRAI

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Couverture d'ombre du soleil
FAUX
Duplique RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Couverture d'ombre du soleil
FAUX
Duplique RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Couverture d'ombre du soleil
VRAI

commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Couverture d'ombre du soleil
VRAI

SONATYPE-2014-0173
—
—
Élevé
VRAI

commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Couverture d'ombre du soleil
VRAI

—
CVE-2019-10086
CVE-2019-10086
Couverture d'ombre du soleil
FAUX
La vulnérabilité est applicable uniquement aux versions 1.9.2+

commons-codec:1:10
SONATYPE-2012-0050
—
—
Élevé
VRAI

mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Couverture d'ombre du soleil
VRAI

CVE-2019-2692
CVE-2019-2692
—
Élevé
VRAI

—
CVE-2020-2875
—
Élevé
FAUX
La même vulnérabilité que CVE-2019-2692, mais avec la mention « les attaques peuvent avoir un impact significatif sur d'autres produits »

—
CVE-2017-15945
—
Couverture d'ombre du soleil
FAUX
Non applicable à mysql-connector-java

—
CVE-2020-2933
—
Faible
FAUX
Duplique de CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
—
Élevé
VRAI

spring-expression:3.0.5
CVE-2018-1270
composant non trouvé
—
Couverture d'ombre du soleil
VRAI

CVE-2018-1257
—
—
Élevé
VRAI

spring-web:3.0.5
CVE-2016-1000027
composant non trouvé
—
Couverture d'ombre du soleil
VRAI

CVE-2014-0225
—
CVE-2014-0225
Couverture d'ombre du soleil
VRAI

CVE-2011-2730
—
—
Couverture d'ombre du soleil
VRAI

—
—
CVE-2013-4152
Élevé
VRAI

CVE-2018-1272
—
—
Couverture d'ombre du soleil
VRAI

CVE-2020-5398
—
—
Couverture d'ombre du soleil
VRAI
Exemple illustratif en faveur de IQ : « L'équipe de recherche en sécurité de Sonatype a découvert que cette vulnérabilité a été introduite dans la version 3.0.2.RELEASE et non 5.0.x comme indiqué dans l'avis. »

CVE-2013-6429
—
—
Élevé
VRAI

CVE-2014-0054
—
CVE-2014-0054
Élevé
VRAI

CVE-2013-6430
—
—
Élevé
VRAI

spring-context:3.0.5
CVE-2011-2894
composant non trouvé
—
Élevé
VRAI

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Couverture d'ombre du soleil
VRAI

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Élevé
VRAI

—
—
CVE-2013-4152
Élevé
FAUX
Duplique de cette même vulnérabilité dans spring-web

—
CVE-2013-4152
—
Élevé
FAUX
La vulnérabilité concerne le composant spring-web

—
CVE-2013-6429
CVE-2013-6429
Élevé
FAUX
La vulnérabilité concerne le composant spring-web

—
CVE-2013-6430
—
Élevé
FAUX
La vulnérabilité concerne le composant spring-web

—
CVE-2013-7315
CVE-2013-7315
Élevé
FAUX
SPLIT de CVE-2013-4152. + La vulnérabilité concerne le composant spring-web

—
CVE-2014-0054
CVE-2014-0054
Élevé
FAUX
La vulnérabilité concerne le composant spring-web

—
CVE-2014-0225
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité concerne le composant spring-web

—
—
CVE-2014-0225
Couverture d'ombre du soleil
FAUX
Duplique de cette même vulnérabilité dans spring-web

—
CVE-2014-1904
CVE-2014-1904
Élevé
FAUX
La vulnérabilité concerne le composant spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Élevé
FAUX
La vulnérabilité concerne le composant spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Couverture d'ombre du soleil
FAUX
La vulnérabilité concerne le composant spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Couverture d'ombre du soleil
FAUX
Pour spring-expression/spring-messages

—
CVE-2018-1271
CVE-2018-1271
Élevé
FAUX
La vulnérabilité concerne le composant spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Couverture d'ombre du soleil
VRAI

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Élevé
VRAI

SONATYPE-2015-0327
—
—
Faible
VRAI

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Élevé
VRAI

spring-tx:3.0.5
—
CVE-2011-2730
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2011-2894
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2013-4152
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2013-6429
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2013-6430
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2013-7315
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2014-0054
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2014-0225
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2014-1904
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2014-3625
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2016-9878
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2018-1270
—
Couverture d'ombre du soleil
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2018-1271
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

—
CVE-2018-1272
—
Élevé
FAUX
La vulnérabilité ne concerne pas spring-tx

struts-core:1.3.8
—
CVE-2011-5057 (OSSINDEX)

Élevé
FASLE
Vulnérabilité à Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Élevé
FAUX
Vulnérabilité à Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

CVE-2016-1182
3VE-2016-1182
—
Couverture d'ombre du soleil
VRAI

—
—
CVE-2011-5057
Élevé
FAUX
Vulnérabilité à Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Élevé
FAUX
Vulnérabilité à Struts 2

CVE-2015-0899
CVE-2015-0899
—
Couverture d'ombre du soleil
VRAI

—
CVE-2012-0394
CVE-2012-0394
Élevé
FAUX
Vulnérabilité à Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Couverture d'ombre du soleil
FASLE
Vulnérabilité à Struts 2

—
CVE-2013-2115
CVE-2013-2115
Couverture d'ombre du soleil
FASLE
Vulnérabilité à Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Couverture d'ombre du soleil
FASLE
Vulnérabilité à Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Couverture d'ombre du soleil
FASLE
Vulnérabilité à Struts 2

CVE-2014-0114
CVE-2014-0114
—
Couverture d'ombre du soleil
VRAI

—
CVE-2015-2992
CVE-2015-2992
Élevé
FAUX
Vulnérabilité à Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

CVE-2016-1181
CVE-2016-1181
—
Couverture d'ombre du soleil
VRAI

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Couverture d'ombre du soleil
FAUX
Vulnérabilité à Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Couverture d'ombre du soleil
VRAI

SONATYPE-2017-0173
—
—
Couverture d'ombre du soleil
VRAI

CVE-2017-7672
—
—
Couverture d'ombre du soleil
FAUX
Doublon à CVE-2017-9804

SONATYPE-2016-0127
—
—
Couverture d'ombre du soleil
VRAI

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Couverture d'ombre du soleil
VRAI

—
CVE-2017-9787
CVE-2017-9787
Couverture d'ombre du soleil
VRAI

—
CVE-2017-9791
CVE-2017-9791
Couverture d'ombre du soleil
VRAI

—
CVE-2017-9793
—
Couverture d'ombre du soleil
FAUX
Doublon à CVE-2018-1327

—
CVE-2017-9804
—
Couverture d'ombre du soleil
VRAI

—
CVE-2017-9805
CVE-2017-9805
Couverture d'ombre du soleil
VRAI

CVE-2016-4003
—
—
Élevé
FAUX
Applicable à Apache Struts 2.x jusqu'à 2.3.28, alors que la version est 2.3.30. Cependant, d'après la description, le CVE s'applique à toutes les versions de Struts 2, si JRE 1.7 ou moins est utilisé. Il semble qu'on ait voulu s'assurer ici, mais cela ressemble plus à un FAUX.

—
CVE-2018-1327
CVE-2018-1327
Couverture d'ombre du soleil
VRAI

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Couverture d'ombre du soleil
VRAI
C'est la vulnérabilité exploitée par des attaquants chez Equifax en 2017

CVE-2017-12611
CVE-2017-12611
—
Couverture d'ombre du soleil
VRAI

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Couverture d'ombre du soleil
VRAI

struts-taglib:1.3.8
—
CVE-2012-0394
—
Élevé
FAUX
Pour struts2-core

—
CVE-2013-2115
—
Couverture d'ombre du soleil
FAUX
Pour struts2-core

—
CVE-2014-0114
—
Couverture d'ombre du soleil
FAUX
Pour commons-beanutils

—
CVE-2015-0899
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à taglib

—
CVE-2015-2992
—
Élevé
FAUX
S'applique à struts2-core

—
CVE-2016-1181
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à taglib

—
CVE-2016-1182
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Élevé
FAUX
Pour struts2-core

—
CVE-2013-2115
—
Couverture d'ombre du soleil
FAUX
Pour struts2-core

—
CVE-2014-0114
—
Couverture d'ombre du soleil
FAUX
Sous commons-beanutils

—
CVE-2015-0899
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à tiles

—
CVE-2015-2992
—
Élevé
FAUX
Pour struts2-core

—
CVE-2016-1181
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à taglib

—
CVE-2016-1182
—
Couverture d'ombre du soleil
FAUX
Ne s'applique pas à taglib

Source : habr.com