DevSecOps: principes et comparaison de SCA. Partie un

L'importance de l'analyse des composants logiciels tiers (Software Composition Analysis - SCA) dans le processus de développement augmente au fur et à mesure de la publication des rapports annuels sur les vulnérabilités des bibliothèques open source, qui sont publiés par Synopsys, Sonatype, Snyk, White Source. Selon l' état des vulnérabilités de sécurité Open Source 2020Le nombre de vulnérabilités open source identifiées en 2019 a augmenté de près de 1,5 fois par rapport à l'année précédente, tandis que les composants open source sont utilisés de 60% à 80% des projets. Si vous vous tournez vers une opinion indépendante, les processus SCA sont une pratique distincte de OWASP SAMM et BSIMM en tant qu'indicateur de maturité, et au cours du premier semestre 2020, l'OWASP a publié le nouveau standard de vérification des composants logiciels (SCVS) de l'OWASP, qui fournit les meilleures pratiques pour vérifier les composants tiers dans la chaîne d'approvisionnement. PAR.







L'un des cas les plus révélateurs s'est produit avec Equifax en mai 2017. Des attaquants inconnus ont saisi des informations sur 143 millions d'Américains, y compris les noms complets, adresses, numéros de sécurité sociale et permis de conduire. Dans 209 000 cas, les documents contenaient également des informations sur les cartes bancaires des victimes. Cette fuite était due à l'exploitation d'une vulnérabilité critique dans Apache Struts 2 (CVE-2017-5638), tandis que le correctif a été publié en mars 2017. La société avait deux mois pour installer la mise à jour, mais personne ne s'en souciait.



Cet article abordera la question du choix d'un outil de conduite de SCA en termes de qualité des résultats d'analyse. Il y aura également une comparaison fonctionnelle des outils. Le processus d'intégration dans CI / CD et les possibilités d'intégration seront laissés pour de futures publications. Une large liste d'outils a été présentée par OWASP sur son site Web , mais dans le cadre de la revue actuelle, nous n'aborderons que l'outil open source le plus populaire Dependency Check, la plate-forme open source Dependency Track un peu moins connue et la solution Sonatype Nexus IQ Enterprise. Nous allons également comprendre comment ces solutions fonctionnent et comparer les résultats obtenus pour les faux positifs.

Principe d'opération

Dependency Check est un utilitaire (CLI, maven, module jenkins, ant) ​​qui analyse les fichiers du projet, collecte des informations sur les dépendances (nom du package, groupid, titre de spécification, version ...), construit une ligne CPE - (Common Platform Enumeration), Package URL (PURL) et détecte les vulnérabilités pour CPE / PURL à partir de bases de données (NVD, Sonatype OSS Index, NPM Audit API ...), puis crée un rapport unique au format HTML, JSON, XML ...



Voyons à quoi ressemble le CPE:

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

• Partie: une indication que le composant appartient à l'application (a), au système d'exploitation (o), au matériel (h) (élément obligatoire)
• Fournisseur: Nom du fabricant du produit (obligatoire)
• Produit: nom du produit (élément obligatoire)
• Version: version du composant (article obsolète)
• Mettre à jour: mettre à jour le package
• Édition: ancienne version (obsolète)
• Langue: La langue telle que définie dans la RFC-5646
• SW Edition: version du logiciel
• Logiciel cible: environnement logiciel dans lequel le produit s'exécute
• Target HW: l'environnement matériel dans lequel le produit s'exécute
• Autre: informations sur le fournisseur ou le produit

Un exemple de CPE ressemble à ceci:

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

La ligne signifie que CPE version 2.3 décrit un composant de l'application du fabricant pivotal_software avec le nom de la spring_frameworkversion 3.0.0. Si nous ouvrons la vulnérabilité CVE-2014-0225 dans NVD , nous pouvons voir une mention de ce CPE. Le premier problème qui doit être immédiatement remarqué est que le CVE dans NVD, selon le CPE, signale qu'il y a un problème dans le framework, et non dans un composant spécifique. Autrement dit, si les développeurs sont étroitement liés au framework et que la vulnérabilité identifiée ne s'applique pas aux modules que les développeurs utilisent, le spécialiste de la sécurité devra en quelque sorte démonter ce CVE et réfléchir à la mise à jour.



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

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

• Sheme: Il y aura toujours 'pkg' indiquant qu'il s'agit d'une URL de package (obligatoire)
• Type: Le "type" du package ou le "protocole" du package, tel que maven, npm, nuget, gem, pypi, etc. (Clause obligatoire)
• Espace de noms: un préfixe de nom, tel que l'ID de groupe Maven, le propriétaire de l'image Docker, l'utilisateur ou l'organisation GitHub. Facultatif et dépend du type.
• Nom: nom du package (obligatoire)
• Version: version du package
• Qualificateurs: qualifications supplémentaires pour le package, telles que le système d'exploitation, l'architecture, la distribution, etc. Élément facultatif et spécifique au type.
• 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 est une plate-forme Web sur site qui accepte la nomenclature (BOM) prête à l' emploi générée par CycloneDX et SPDX , c'est-à-dire des spécifications toutes faites sur les dépendances existantes. Il s'agit d'un fichier XML avec une description des dépendances - nom, hachages, URL du package, éditeur, licence. Ensuite, Dependency Track analyse la nomenclature, examine les CVE disponibles pour les dépendances identifiées à partir de la base de données de vulnérabilités (NVD, Sonatype OSS Index ...), puis construit des graphiques, calcule des métriques, met à jour régulièrement les données d'état de vulnérabilité des composants.



Un exemple de ce à quoi une nomenclature pourrait ressembler au format XML:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
  <components>
    <component type="library">
      <publisher>Apache</publisher>
      <group>org.apache.tomcat</group>
      <name>tomcat-catalina</name>
      <version>9.0.14</version>
      <hashes>
        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
      </hashes>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

La nomenclature peut être utilisée non seulement comme paramètres d'entrée pour le suivi des dépendances, mais également pour l'inventaire des composants logiciels dans la chaîne d'approvisionnement, par exemple, pour fournir un logiciel au client. En 2014, la Cyber ​​Supply Chain Management and Transparency Act de 2014 a même été proposée pour examen aux États-Unis , qui stipulaient que lors de l'achat de logiciels, n'importe quel État. l'institution doit demander une nomenclature pour empêcher l'exploitation des composants vulnérables, mais la loi n'est jamais entrée en vigueur.



Pour revenir à SCA, Dependency Track propose des intégrations prêtes à l'emploi avec des plates-formes de notification telles que Slack, des systèmes de gestion des vulnérabilités tels que Kenna Security. Il faut également dire que Dependency Track, entre autres, détecte les versions obsolètes des packages et fournit des informations sur les licences (en raison de la prise en charge de SPDX).



Si nous parlons spécifiquement de la qualité de SCA, alors il y a une différence fondamentale.



Le suivi des dépendances n'accepte pas le projet comme entrée, mais plutôt la nomenclature. Cela signifie que si nous voulons vérifier le projet, nous devons d'abord générer bom.xml, par exemple, en utilisant CycloneDX. Ainsi, Dependency Track dépend directement de CycloneDX. En même temps, cela permet une personnalisation. L'équipe OZON a donc écrit le module CycloneDX pour créer des fichiers de nomenclature pour les projets Golang pour une analyse plus approfondie via la piste de dépendance.



Nexus IQEst une solution commerciale SCA de Sonatype, qui fait partie de l'écosystème Sonatype, qui comprend également le Nexus Repository Manager. Nexus IQ peut accepter comme données d'entrée à la fois les archives de guerre (pour les projets java) via l'interface Web ou l'API et la nomenclature, si votre organisation n'a pas réussi à reconstruire de CycloneDX vers une nouvelle solution. Contrairement aux solutions open source, IQ se réfère non seulement au CPE / PURL du composant identifié et à la vulnérabilité correspondante dans la base de données, mais prend également en compte sa propre recherche, par exemple le nom de la fonction ou de la classe vulnérable. Les mécanismes du QI seront discutés plus tard dans l'analyse des résultats.



Résumons certaines des fonctionnalités fonctionnelles et considérons également les langages pris en charge pour l'analyse:





Fonctionnalité





Opportunités d'intégration

Vérification de la dépendance

Premier départ

Exécutons la vérification de dépendance sur une application DVJA délibérément vulnérable .



Pour ce faire, nous utiliserons le plugin Dependency Check Maven :

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

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







Ouvrons le fichier. Après les informations récapitulatives sur le nombre total de vulnérabilités, nous pouvons voir des informations sur les vulnérabilités avec un niveau élevé de gravité et de confiance, en indiquant le package, le CPE, le numéro CVE.



Viennent ensuite des informations plus détaillées, en particulier sur quoi reposaient les preuves, c'est-à-dire une certaine nomenclature.







Vient ensuite la description CPE, PURL et CVE. À propos, les recommandations de correction ne sont pas jointes en raison de leur absence dans la base de données NVD.







Pour examiner systématiquement les résultats de l'analyse, vous pouvez configurer Nginx avec des paramètres minimaux ou envoyer les défauts résultants à un système de gestion des défauts qui prend en charge les connecteurs de contrôle de dépendance. Par exemple, Defect Dojo.

Suivi des dépendances

Installation

Dependency Track, quant à lui, est une plate-forme Web avec des graphiques d'affichage, il n'y a donc pas de problème aigu de stockage des défauts dans une solution tierce.

Il existe les scripts suivants pris en charge pour l'installation: Docker, WAR, Executable WAR.

Premier départ

Accédez à l'URL du service en cours d'exécution. Nous entrons via admin / admin, modifions le nom d'utilisateur et le mot de passe, puis nous accédons au tableau de bord. La prochaine chose que nous allons faire est de créer un projet pour l'application de test Java dans Accueil / Projets → Créer un projet . Prenons DVJA comme exemple.







Étant donné que le suivi des dépendances ne peut accepter qu'une nomenclature comme entrée, cette nomenclature doit être récupérée. Utilisons le plugin CycloneDX Maven :

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 la nomenclature .



Allons à Administration → Analyseurs. Nous comprenons que nous n'avons que l'analyseur interne activé, y compris NVD. Nous connecterons également Sonatype OSS Index.







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







Vous pouvez également trouver dans la liste une vulnérabilité applicable à Sonatype OSS:







La principale déception était que Dependency Track n'accepte plus les rapports XML de Dependency Check. Les dernières versions prises en charge de l'intégration de Dependency Check étaient 1.0.0 - 4.0.2, tandis que j'ai testé 5.3.2.



Voici une vidéo (et maintenant ) quand c'était encore possible.

Nexus IQ

Premier départ

Le Nexus IQ est installé à partir des archives de la documentation , mais nous avons compilé une image Docker à cet effet.



Après vous être connecté à la console, vous devez créer une organisation et une application.















Comme vous pouvez le voir, la mise en place dans le cas d'IQ est un peu plus compliquée, car nous devons également créer des politiques applicables à différentes «étapes» (développement, construction, étape, publication). Cela est nécessaire pour bloquer les composants vulnérables lorsqu'ils se déplacent le long du pipeline plus près du produit, ou pour bloquer dès qu'ils entrent dans le Nexus Repo lorsqu'ils sont téléchargés par les développeurs.



Pour ressentir la différence entre l'open source et l'entreprise, effectuons le même scan via le Nexus IQ de la même manière via le plugin Maven , après avoir créé au préalable 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=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>

Suivez l'URL du rapport généré dans l'interface Web IQ:







Ici, vous pouvez voir toutes les violations de politique avec différents niveaux de signification (d'Info à Security Critical). La lettre D à côté du composant signifie que le composant est une dépendance directe et la lettre T à côté du composant signifie que le composant est une dépendance transitive, c'est-à-dire qu'il est transitif.



À propos, le rapport sur l' état de la sécurité Open Source 2020 de Snyk rapporte que plus de 70% des vulnérabilités open source trouvées dans Node.js, Java et Ruby se trouvent dans des 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 version, qui montre l'emplacement de la version actuelle sur la chronologie, ainsi que le point à quel point la vulnérabilité n'est plus vulnérable. La hauteur des chandeliers sur le graphique montre la popularité de ce composant.







Si vous accédez à la section sur la vulnérabilité et divulguez la CVE, vous pouvez lire une description de cette vulnérabilité, des recommandations pour l'élimination, ainsi que la raison pour laquelle ce composant a été violé, c'est-à-dire la présence d'une classe DiskFileitem.class.











Résumons uniquement les composants Java tiers, en supprimant les composants js. Entre parenthèses, nous indiquons le nombre de ces 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 sonatype db)

Vérification de la dépendance totale:

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

Suivi de dépendance totale:

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

Dans les prochaines étapes, nous analyserons les résultats et déterminerons laquelle de ces vulnérabilités est un vrai défaut et laquelle est un faux positif.

Avertissement

Cette critique n'est pas une vérité indéniable. L'auteur n'avait pas pour objectif de faire ressortir un instrument distinct des autres. Le but de la revue était de montrer comment les outils SCA fonctionnent et comment vérifier leurs résultats.

Comparaison des résultats

Conditions: Un



faux positif pour les vulnérabilités dans les composants tiers est:

• Non-correspondance CVE pour le composant identifié
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• Par exemple, CVE a été trouvé dans un composant spring-web, après quoi SCA pointe vers le même CVE dans d'autres composants de Spring Framework, tandis que CVE n'a rien à voir avec d'autres composants. Dans ce cas, ce sera un faux positif.

Le projet open source DVJA a été choisi comme objet de recherche. L'étude n'a impliqué que des composants java (pas de js).

Résumé des résultats

Passons directement au résultat d'une revue manuelle des vulnérabilités identifiées. Le rapport complet de chaque CVE se trouve en annexe.



Résumé des résultats pour toutes les vulnérabilités:



Résumé des résultats par composante:



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















En comparaison, une étude similaire a été menée par l'équipe de Sonatype pour tester un projet de 1531 composants à l'aide du contrôle de dépendance OWASP. Comme nous pouvons le voir, le rapport bruit / déclencheurs corrects est comparable à nos résultats.





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



Jetons un coup d'œil à quelques CVE à partir de nos résultats d'analyse pour comprendre la raison de ces résultats.

Plus de détails

# 1

Jetons d'abord un coup d'œil à quelques points intéressants du Sonatype Nexus IQ.



Nexus IQ signale un problème de désérialisation avec la possibilité d'exécuter RCE dans Spring Framework plusieurs fois. 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 existe une vulnérabilité en double dans plusieurs CVE. Car si vous regardez CVE-2016-1000027 et CVE-2011-2894 dans la base de données NVD, alors il semble que tout est évident





Description de CVE-2011-2894 de NVD :





Description de CVE-2016-1000027 de NVD :





CVE-2011-2894 lui-même est assez célèbre. Le rapport 2011 White Source a classé cette CVE comme l'une des plus fréquemment rencontrées. Les descriptions pour CVE-2016-100027 sont, en principe, un peu dans NVD, et cela semble être applicable uniquement pour Spring Framework 4.1.4. Jetez un œil à la référence et ici cela devient plus ou moins clair. Nous comprenons d' après l'article de Tenable qu'en plus de la vulnérabilité RemoteInvocationSerializingExporterdans CVE-2011-2894, la vulnérabilité est observée dans HttpInvokerServiceExporter. Voici ce que nous dit Nexus IQ:







Néanmoins, il n'y a rien de tel dans NVD, c'est pourquoi Dependency Check et Dependency Track reçoivent un faux négatif.



Aussi, d'après la description de CVE-2011-2894, vous pouvez comprendre que la vulnérabilité est bien présente dans spring-context: 3.0.5 et spring-core: 3.0.5. La confirmation de ceci peut être trouvée dans l'article de la personne qui a trouvé cette vulnérabilité.

# 2

Si nous étudions la vulnérabilité CVE-2016-4003, nous comprendrons qu'elle a été corrigée dans la version 2.3.28, néanmoins Nexus IQ nous en informe. Il y a une note dans la description de la vulnérabilité:







c'est-à-dire que la vulnérabilité n'existe qu'en conjonction avec une version obsolète du JRE, dont ils ont décidé de nous avertir. Néanmoins, nous considérons cela comme un faux positif, bien que ce ne soit pas le pire.

Numéro 3

Si nous regardons les descriptions pour CVE-2017-9804 et CVE-2017-7672, nous comprendrons que le problème est URLValidator class, et CVE-2017-9804 découle de CVE-2017-7672. La présence de la deuxième vulnérabilité ne porte aucune charge utile, sauf que sa gravité est passée à Élevée, ce qui peut donc être considéré comme un bruit inutile.



Dans l'ensemble, aucun autre faux positif n'a été trouvé pour le Nexus IQ.

# 4

Il y a plusieurs choses qui distinguent IQ des autres décisions.





Le CVE dans NVD dit qu'il n'est applicable que pour les versions 5.2.x jusqu'à 5.2.3, 5.1.x jusqu'à 5.1.13 et les versions 5.0.x jusqu'à 5.0.16, cependant, si nous regardons la description CVE dans le Nexus IQ, nous verrons ce qui suit:

Avis de dérogation: l'équipe de recherche sur la sécurité de Sonatype a découvert que cette vulnérabilité a été introduite dans la version 3.0.2.RELEASE et non dans la version 5.0.x comme indiqué dans l'avis.



Ceci est suivi d'un PoC pour cette vulnérabilité, qui signale qu'elle est présente dans la version 3.0.5.



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

# 5

Examinons les faux positifs pour la vérification des dépendances et le suivi des dépendances.



Dependency Check se distingue en ce qu'il reflète les CVE qui s'appliquent à l'ensemble du framework dans NVD aux composants auxquels ces CVE ne sont pas applicables. Cela s'applique à CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, sur lequel le contrôle de dépendance «vissé» vers struts-taglib: 1.3.8 et struts-tiles-1.3.8. Ces composants n'ont rien à voir avec ce qui est décrit dans CVE - traitement des demandes, validation de page, etc. Cela est dû au fait que le point commun entre ces CVE et les composants n'est que le framework, c'est pourquoi Dependency Check l'a considéré comme une vulnérabilité.



La même situation 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 sont en fait applicables à struts2-core, qui est essentiellement un framework distinct. Dans ce cas, Nexus IQ a bien compris l'image et dans les CVE qu'il a émis, a indiqué que struts-core arrivait en fin de vie et qu'il était nécessaire de passer à struts2-core.

# 6

Dans certaines situations, il est injuste d'interpréter une erreur explicite de vérification de dépendance et de suivi de dépendance. En particulier CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, qui sont Dependency Check et Dependency Track renvoyé à spring-core: 3.0.5 fait référence à spring-web: 3.0.5. Dans le même temps, certains de ces CVE ont été trouvés et le Nexus IQ, néanmoins, l'IQ les a correctement identifiés pour un autre composant. Puisque ces vulnérabilités n'ont pas été trouvées dans spring-core, on ne peut pas soutenir qu'elles ne sont pas dans le cadre, en principe, et les outils open source ont à juste titre pointé ces vulnérabilités (ils ont juste raté un peu).

conclusions

Comme on peut le voir, déterminer la fiabilité des vulnérabilités identifiées par un examen manuel ne donne pas de résultats sans ambiguïté, ce qui conduit à des questions controversées. Les résultats sont tels 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 Sonatype a élargi la description de chaque vulnérabilité CVE de NVD dans leurs bases de données, en spécifiant, avec précision à la classe ou à la fonction de la vulnérabilité pour une version particulière du composant, en menant des recherches supplémentaires (par exemple, vérifier les vulnérabilités sur des versions logicielles).



Les vulnérabilités qui n'étaient pas incluses dans NVD, mais qui sont néanmoins présentes dans la base de données Sonatype avec la marque SONATYPE, ont une influence importante sur les résultats. Selon l' état des vulnérabilités de sécurité Open Source 202045% des vulnérabilités open source découvertes ne sont pas signalées à NVD. Selon la base de données WhiteSource, seulement 29% de toutes les vulnérabilités open source signalées en dehors de NVD finissent par y être publiées, c'est pourquoi il est également important de chercher ailleurs les vulnérabilités.



En conséquence, Dependency Check génère beaucoup de bruit, manquant certains composants vulnérables. Dependency Track produit moins de bruit et révèle un grand nombre de composants, ce qui ne fait pas mal aux yeux visuellement dans l'interface Web.



Néanmoins, la pratique montre que c'est l'open source qui devrait être la première étape vers la maturation de DevSecOps. La première chose à laquelle il faut penser pour intégrer SCA dans le développement est les processus, c'est-à-dire réfléchir avec la direction et les services associés sur la façon dont les processus idéaux devraient ressembler dans leur organisation. Il se peut que, dans un premier temps, pour votre organisation, Dependency Check ou Dependency Track couvre tous les besoins de l'entreprise, et les solutions d'entreprise seront une suite logique en raison de la complexité croissante des applications développées.