Sécurisez votre chaîne d’approvisionnement de logiciels avec Bytesafe

Assurez la sécurité de votre chaîne d’approvisionnement

Une chaîne d’approvisionnement de code sécurisée implique de savoir quel code est réellement utilisé dans vos applications.

Aujourd’hui, les applications Web reposent en grande partie sur le code produit de développeurs externes. Ainsi, vous remarquerez que les applications modernes sont principalement basées sur des logiciels open source (OSS) provenant de tiers.

La chaîne d’approvisionnement de code contient tout le code externe dont dépend une application, qu’il soit open source ou commercial. Comme pour toute chaîne d’approvisionnement, il est essentiel de s’assurer que le code fournit réponde à vos besoins et ce, de manière sécurisée et efficace.

Une application Web peut être composée de centaines, voir de milliers de dépendances de code. Synopsys affirme qu’en utilisant des dépendances externes, jusqu’à 70 % du code de vos applications est écrit par quelqu’un d’autre. Et 99% de toutes les bases de code analysées contenaient du code open source.

De plus, de nombreuses entreprises ne possèdent pas un bon inventaire ou une bonne connaissance des logiciels open source qu’elles utilisent dans leurs produits ni l’étendue de leur dépendance vis-à-vis de l’open source.

Gartner estime que le niveau des dépenses mondiales en matière de sécurité atteindra 170,4 milliards $ d’ici 2022. Le coût financier mondial pour les entreprises touchées par la cybercriminalité devrait atteindre 6 milliards $ en 2021. Par conséquent, le coût de la gestion et de la sécurisation de la chaîne d’approvisionnement de codes est souvent négligeable par rapport aux coûts financiers et la perte de réputation qui pourraient résulter d’une violation de la sécurité !

Afin d’assurer le suivi des vulnérabilités de vos dépendances open source, vous devez d’abord être au courant de leur présence dans votre base de code. Le manque de visibilité et d’informations sur les packages que vous utilisez peut avoir un impact négatif sur votre application logicielle de plusieurs façons.

De plus, la plupart des dépendances que vous utilisez ont leurs propres dépendances. Par conséquent, si vous n’analysez que votre propre code et ses dépendances, votre vulnérabilité est bien plus importante que vous pourrez penser.

Évitez de concevoir une application présentant des vulnérabilités en termes de sécurité, des problèmes de dépendance ou une violation des conditions de licence. Bytesafe peut empêcher de mettre vos applications et votre entreprise en danger en améliorant la sécurité de vos dépendances et en protégeant votre chaîne d’approvisionnement de code.

Qu’est-ce que la sécurité des dépendances ?

La sécurité des dépendances correspond au concept de gestion du risque lié à l’introduction de code externe dans votre application, sur lequel vous n’avez aucun contrôle direct.

La sécurité des dépendances repose sur la connaissance et le contrôle des dépendances que vous utilisez. Elle consiste ensuite à s’assurer que les dépendances sont sécurisées et fiables, qu’elles sont toujours disponibles, à jour, conformes aux politiques de sécurité de votre entreprise et qu’elles ont été ajoutées intentionnellement.

Le contrôle est nécessaire pour pouvoir atténuer les attaques de sécurité telles que les attaques de type Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), XML External Entity (XXE) et Business logic, pour n’en citer que quelques-unes. Des attaques potentiellement présentes dans votre chaîne d’approvisionnement par le biais du typosquattage ou de la confusion des dépendances.

L’évolution constante de l’open source rend la gestion et le suivi des dépendances de code, la sécurité open source et la conformité de licence une tâche difficile pour les entreprises qui utilisent des logiciels open source dans leur base de code.

Les organisations doivent s’assurer que :

1. Les dépendances des sources open source sont sécurisées
2. Les packages de workflows répondent aux politiques d’entreprise et de sécurité demandées.

Afin de développer des applications sécurisées, les développeurs doivent comprendre et être conscients des différents types d’attaques qui peuvent être menées. Ce n’est pas le cas de tout le monde. L’OWASP est une excellente source d’informations qui vous aidera à vous mettre à niveau : https://cheatsheetseries.owasp.org/.

Qu’est-ce qu’une dépendance ?

L’utilisation et le partage de blocs de code réutilisables sont des pratiques courantes qui accélèrent le cycle de vie du développement logiciel (SDLC). Chaque morceau de code est conçu dans un but précis, ce qui permet aux développeurs d’économiser du temps et des efforts en évitant de devoir l’écrire eux-mêmes.

Une dépendance est un morceau de code réutilisable dont une application dépend et qui est nécessaire à son bon fonctionnement. Pour les projets d’applications Web, ces dépendances sont souvent fournies par des gestionnaires de packages tels que npm. Le registre public de npm contient environ 1,5 million de packages que les développeurs peuvent télécharger à tout moment, avec en moyenne 1 milliard de téléchargements quotidiens.

Les dépendances dans l’écosystème npm sont particulièrement intéressantes du point de vue de la sécurité, pour deux raisons.

Premièrement, l’utilisation de dépendances est une pratique naturelle avec JavaScript, où il y a une éthique open source de réutilisation du code qui est largement adoptée par les développeurs.

Deuxièmement, les dépendances ont souvent leurs propres dépendances. De ce fait, lorsque vous ajoutez de nouveaux packages à votre projet, il se peut que vous incluiez plus de dépendances que vous ne le pensiez ou ne le prévoyiez à l’origine.

Il existe deux types de dépendances ;

• Dépendances directes lorsque votre application utilise directement un morceau de code et le référence directement
• Dépendances transitives qui sont des dépendances des dépendances directes de votre application (également appelée dépendance d’une dépendance).

Une bonne gestion des dépendances signifie avoir une visibilité, un aperçu et un contrôle de toutes les dépendances que vos applications utilisent. Y compris toutes les dépendances transitives !

Le risque est qu’en introduisant un logiciel tiers dans votre application, vous incorporiez également ses vulnérabilités, failles de sécurité et bugs.

Gestion de la sécurité des dépendances

Dans les grandes organisations comptant plusieurs équipes de développement et de nombreuses applications, il peut s’avérer complexe de garder la trace des dépendances utilisées dans ses applications.

Traditionnellement, les services backend utilisent l’authentification, le cryptage des données, des espaces de stockage sécurisés pour les tokens et les informations d’identification, la gestion des accès, etc. Mais la sécurité maximale que peut avoir votre front-end est toujours inférieur ou égal au maillon le plus faible ou à votre dépendance externe.

Il est essentiel de maintenir vos dépendances à jour, mais il peut être difficile d’établir des priorités entre les dépendances vulnérables aux menaces de sécurité et les mises à jour qui ne casseront pas votre code.

L’établissement d’un protocole clair pour la gestion des dépendances permettra d’éviter des désagréments plus tard dans le cycle de développement, lorsqu’il pourrait être plus coûteux de les résoudre.

Évitez les dépendances obsolètes

Dans une certaine mesure, les logiciels sont des commodités récentes pour lesquelles vous voulez vous assurer que vous utilisez des composants bien entretenus et mis à jour. Les nouvelles versions peuvent non seulement inclure de nouvelles fonctionnalités que vous souhaitez utiliser en tant qu’organisation, mais aussi des corrections critiques de vulnérabilités connues qui ferment des voies d’attaque potentielles.

En tant qu’utilisateur, vous voulez éviter la dégradation des logiciels et vous assurer que les dépendances que vous utilisez sont à jour avec les dernières versions. Les organisations doivent mettre au point une approche permettant de vérifier et de mettre à jour en permanence leurs dépendances. Elles doivent évaluer les avantages de la mise à jour des dépendances par rapport au travail nécessaire pour tester leurs applications avec les nouvelles versions des dépendances.

Le manque de protocole de prévention des dépendances périmées, associé à l’absence de mise à jour des versions, peut vous priver de certains avantages :

• Les dernières améliorations qui ont permis d’augmenter les performances ou d’ajouter de nouvelles fonctionnalités.
• Correction de bugs
• Alertes sur le code qui a été déprécié ou qui est en fin de vie
• De plus, vous exposez votre application et vos utilisateurs à des failles de sécurité connues.

Dépendance de développeurs externes

Au sein de propre organisation, vous disposez probablement de politiques et de contrôles internes pour vous assurer que le code que vous avez développé est testé de manière approfondie, avec des indicateurs clés de performance définis pour les métriques du code et ainsi de suite.

Pour ce qui est du code tiers, la plupart n’est pas développé par de grandes entreprises comme Facebook ou Google, ce qui aurait apporté une puissance de développement non négligeable. Au contraire, la plupart des packages sont publiés par des communautés de développeurs individuels qui se dévouent à maintenir le code avec leurs propres objectifs en tête.

Lorsque votre application utilise des dépendances externes, cela signifie qu’en tant qu’organisation, vous dépendrez de développeurs sur lesquels vous ne pouvez exercer aucun contrôle réel. Et cela donne à réfléchir. Sans contrôle, comment peut-on savoir si les composants open source de votre codebase sont maintenus ?

Lorsque vous dépendez de développeurs externes, vous n’êtes pas en mesure :

• D’influencer la façon dont le code du composant est écrit
• D’empêcher le code d’être modifié à l’avenir
• D’assurer une vérification suffisante des compétences des nouveaux développeurs qui participent au développement du code.
• De contrôler si les développeurs gèrent les tokens et les données d’identification de manière sécurisée.
• De savoir si le code restera compatible avec vos dépendances.

Aujourd’hui, npm a une politique de non-publication beaucoup plus stricte, mais dans le passé, il y a eu des incidents dus à des packages non publiés. Par exemple, il y a eu le cas d’un développeur JavaScript qui a retiré ses packages de npm. Les développeurs se sont retrouvés coincés avec des soucis de compilation et d’installation pour une fonctionnalité qui était largement utilisée dans d’autres applications. Le problème principal du manque de contrôle sur les composants clés de vos applications subsiste, et différents services peuvent avoir différentes politiques de dé-publication.

Manque de gestion sécurisée des tokens et des informations d’identification pour les gestionnaires de packages.

Les statistiques de 2020 montrent que seulement 9,27 % des gestionnaires de packages npm utilisent l’authentification à deux facteurs (2FA) pour protéger leurs comptes contre le piratage ou la prise de contrôle.

Avec un si grand nombre de gestionnaires n’utilisant pas la 2FA pour protéger leurs comptes, quand une nouvelle version du package est déployée, il y a un risque et vous ne pouvez pas vraiment vous assurer que celle-ci a bien été publiée par le gestionnaire original et non pas par un tiers avec des intentions malveillantes.

Il n’y a pas d’autre écosystème comme Javascript avec les mêmes quantités énormes d’utilisateurs, de code et de téléchargements quand il s’agit du nombre de bibliothèques open source disponibles. Un environnement idéal pour les pirates qui tentent d’attaquer votre chaîne d’approvisionnement de code.

Partez du principe que vos dépendances auront des vulnérabilités

La sécurité des dépendances concerne également la manière dont vous gérez les vulnérabilités connues dans les bibliothèques tierces et évitez les nouvelles menaces, ainsi que la manière dont vous gérez les dépendances externes de vos applications.

Au fil du temps, les dépendances des applications peuvent devenir obsolètes ou de nouvelles vulnérabilités peuvent être découvertes. Il est donc essentiel de savoir quelles dépendances votre application utilise (dépendances directes et transitives) pour pouvoir remédier aux problèmes potentiels et rester à jour.

Il est facile d’inclure de nouvelles dépendances, vous devrez donc vous assurer que les dépendances de votre application sont gérées conformément aux règles établies par votre entreprise.

Qualité des dépendances

Quand il s’agit de la qualité de l’open source, il n’y a pas de contrôles ou de vérifications nécessaires pour assurer la sécurité/qualité quand un package est publié dans un registre public.

Cela signifie que vous trouverez des packages où la sécurité a été prise au sérieux, mais aussi de nombreux packages où la sécurité n’a pas été une priorité.

Bien qu’il existe de nombreux outils et services disponibles pour simplifier la découverte des packages, il est également important de décider des critères à examiner et à évaluer avant de décider d’inclure une nouvelle dépendance dans votre application.

Par exemple, un indicateur souvent utilisé est la popularité (nombre de téléchargements, de packages dépendants, etc.), qui n’est pas un critère suffisant pour assurer la sécurité des dépendances et constitue donc un indicateur trompeur. D’autres indicateurs qui sont couramment utilisés sont la date de la dernière version, les dépendances périmées, les versions stables, la présence de fichiers clés (par exemple, README), la garantie du code par des tests et l’existence d’un site Web personnalisé.

Compte tenu du grand nombre de dépendances externes disponibles, la sécurité des dépendances devrait être l’affaire de tous les membres d’une équipe, plutôt que d’une ou deux personnes spécialisées. L’enjeu de la sécurité des dépendances implique tout le monde !

Est-ce que le code open source est sécurisée ?

Non, pas par défaut.

En théorie, le fait que “l’open source permet d’avoir plus d’yeux sur le code” signifie que plus de personnes “regardent” le code, ce qui implique un meilleur niveau de sécurité par rapport à, par exemple, un code propriétaire, qui limite l’accès et la visibilité.

Même s’il est vrai qu’un plus grand nombre de personnes regardent le code, il est faux de croire qu’elles examinent toutes les lignes de code, en cherchant minutieusement à éliminer les failles. Avec de nombreux projets open source comptant des millions de lignes de code, il n’y a pas assez de personnes qualifiées en sécurité capables de vérifier et d’examiner le code de manière exhaustive.

Pire encore, dans les situations où les logiciels sont rarement, voire jamais, examinés ou mis à jour, les vulnérabilités du code peuvent être exploitées pour des activités malveillantes.

L’utilisation des packages du registre public npm est devenue un processus si facile qu’il a contribué à l’augmentation des téléchargements et de la productivité des logiciels. Mais, avec le rythme effréné auquel les développeurs doivent produire des applications, beaucoup n’ont jamais vraiment regardé leur code et les dépendances des tiers.

Se cacher à la vue de tous

Les problèmes de gestion des dépendances et de sécurité ne sont pas propres à l’écosystème JavaScript. La bibliothèque open source OpenSSL, extrêmement populaire, n’était maintenue que par deux développeurs. De nombreux sites dans le monde ont été touchés par sa vulnérabilité Heartbleed. Le bug a été découvert deux ans avant d’être corrigé, bien que la bibliothèque soit open source.

Attaques contre les chaînes d’approvisionnement de code

Les attaques contre les chaînes d’approvisionnement sont en augmentation, et ce depuis quelques années. Au lieu d’essayer de pirater et d’exploiter les vulnérabilités existantes dans le code, les pirates tentent de plus en plus d’inclure leur code malveillant dans vos applications pendant le processus de développement.

Les attaques de chaîne d’approvisionnement à connaître et à surveiller :

• Prise de contrôle de packages et de comptes (avec intention malveillante)
• Typosquattage et combosquattage
• Confusion des dépendances

L’attaque récente de la chaîne d’approvisionnement de SolarWinds est peut-être l’exemple le plus connu d’une attaque de chaîne d’approvisionnement, où un code malveillant a été inséré dans l’un des produits SolarWinds et distribué sous forme de mise à jour à de nombreux clients. Mais il existe également de nombreux autres exemples récents de packages malveillants d’attaques similaires dans lel’écosystème npm.

Avec l’augmentation de ce type d’attaques et du nombre de tentatives, aujourd’hui, il est plus important que jamais de protéger votre chaîne d’approvisionnement de code !

Attaques de prise de contrôle de comptes et de packages

L’une des façons pour les pirates de pénétrer dans votre application est de passer par la chaîne d’approvisionnement, en exploitant un package npm légitime qui se trouve dans la liste très longue des dépendances que vous utilisez déjà.

En accédant au token du gestionnaire d’un package, il est facile de publier une nouvelle version comprenant une faille précise prête à être exploitée. Ces attaques conservent souvent toutes les fonctionnalités originales du package d’origine car cela le rend rétrocompatible et plus difficile à détecter. Compte tenu de la généralisation de la réutilisation des packages npm, un Un compte compromis peut avoir un impact sur de nombreux utilisateurs dans le monde entier.

Une façon d’accéder à un package légitime est d’exploiter le fait que de nombreux responsables de packages ne sécurisent pas leurs informations d’identification, en créant des mots de passe forts ou en utilisant une authentification à deux facteurs avec npmjs.

L’ingénierie sociale traditionnelle est également utilisée, lorsque des développeurs malveillants contribuent initialement à la base de code, mais, une fois qu’ils sont ajoutés en tant que gestionnaires, ajoutent du code malveillant et publient de nouvelles versions, voir suppriment le gestionnaire initial (ce que l’on appelle la prise de contrôle du compte).

Attaques de typosquattage et de combosquattage

Les attaques de typosquattage incitent les développeurs à installer des packages malveillants ayant des noms similaires à ceux des packages officiels. Le combosquattage est similaire au typosquattage, mais, contrairement aux fausses fautes de frappe, il utilise des noms similaires à des noms réels.

En se basant sur des erreurs humaines par le biais de fautes de frappe ou en espérant que les développeurs ne feront pas l’effort d’examiner les dépendances, les pirates veulent introduire leurs packages dans vos projets et votre chaîne d’approvisionnement.

Lorsque vous téléchargez et utilisez des packages open source, vous faites essentiellement confiance à leur éditeur, bien qu’aucun des services d’hébergement de packages puisse garantir que tout le code téléchargé est exempt de malware.

La plupart des développeurs et organisations croient aveuglément que les dépendances utilisées ne contiennent pas de contenu malveillant (intentionnellement ou non). Et lorsqu’ils installent des packages à partir de npm ou depuis un autre repository, les utilisateurs téléchargent et installent automatiquement un package avec toutes les dépendances associées.

Par mesure de sécurité, vous devez vous assurer que vous téléchargez les packages que vous avez l’intention de télécharger.

Dependency confusion attacks

Dependency confusion (sometimes known as substitution attacks) confuses package managers on what package version to pull into their project. The attacks target vulnerabilities or design flaws in automated build or installation tools that enable public dependencies to be mistaken for internal dependencies with the exact same name.

The attack comprises uploading malware to open source repositories and packages automatically being distributed downstream into a company’s internal applications - with the public package getting priority and being pulled without needing any action from the developer.

If the attack is successful, a package from an unintended source will be included in your applications, with the possibility of running scripts and executing arbitrary code on the server.

Sécurisez votre chaîne d’approvisionnement de code

Sécuriser votre chaîne d’approvisionnement implique que vous avez mis en place les processus pour vous assurer que les nouvelles dépendances ou versions sont ajoutées de manière intentionnelle. Cela suppose également d’avoir accès aux bons outils qui vous permettent d’avoir une bonne visibilité et vue d’ensemble ainsi que la protection de votre organisation contre les codes malveillants.

Comme dans le cas de l’assurance qualité (AQ), où il vaut mieux trouver les bugs avant qu’ils ne soient déployés, il est préférable de bloquer et de détecter les lacunes en matière de sécurité et de licence avant qu’elles ne deviennent des problèmes.

Sécurisez votre chaîne d’approvisionnement en:

• Analysant continuellement les dépendances pour trouver des vulnérabilités
• Utilisant les politiques de sécurité de Bytesafe pour gérer vos dépendances en fonction de vos règles de gestion.
• Créant un pare-feu de dépendances
• Ayant le même niveau de sécurité pour tous les packages

Analyser continuellement les dépendances pour trouver des vulnérabilités

Il se peut que vos dépendances soient sécurisées lorsque vous les ajoutez à vos applications, mais de nouvelles vulnérabilités sont découvertes en permanence. Analysez continuellement vos dépendances, au lieu de vous fier uniquement à des analyses ponctuelles, et assurez-vous que les failles de sécurité critiques ne se retrouvent pas dans vos applications.

Le scanner de vulnérabilités de Bytesafe détecte les vulnérabilités de sécurité connues dans vos dépendances. Lorsque le scanner identifie des vulnérabilités, des notifications seront envoyées aux utilisateurs et des badges de sécurité seront ajoutés pour signaler les dépendances concernées.

Les badges de sécurité indiquent la gravité de la vulnérabilité et vous renvoient vers un rapport qui contient des informations supplémentaires, comme notamment, une recommandation sur la manière de corriger le problème de sécurité.

Le scanner de vulnérabilité vous aide à rester à jour en matière de sécurité de vos dépendances en trouvant et en mettant en évidence les vulnérabilités. Pour restreindre les packages, lisez comment utiliser les politiques de sécurité de Bytesafe.

Utiliser les politiques de sécurité de Bytesafe pour gérer vos dépendances en fonction des règles d’entreprise prescrites

Les politiques de sécurité de Bytesafe vous permettent de gérer vos dépendances de manière homogène dans tout votre environnement en fonction de vos règles de gestion d’entreprise existantes. Les politiques de sécurité de Bytesafe sont des règles qui sont exécutées avant toute action sur le registre, empêchant ainsi que des versions non désirées de packages soient incluses dans vos registres.

Pour éviter qu’une personne ou qu’un petit groupe de quelques personnes ne soit responsable de la sécurité des dépendances, transférez la responsabilité vers l’ensemble des développeurs de vos équipes en utilisant des outils efficaces comme Bytesafe.

Utilisez la gamme de politiques de sécurité de Bytesafe pour établir le contrôle des dépendances. Par exemple, la Freeze policy peut être utilisée pour rendre les registres accessibles en lecture seule (temporairement ou définitivement). Ou encore la Politique de sécurité qui empêche les versions de packages présentant des vulnérabilités connues d’être incluses dans vos registres.

La Politique de blocage peut être utilisée afin de bloquer des packages entiers ou des gammes de versions afin qu’ils ne soient pas introduits dans un registre.

En bloquant les noms de packages internes dans un registre de pare-feu, les packages externes qui remplacent des packages internes ne sont plus une option.

Créer un pare-feu de dépendances

L’idée est simple, créer un lien vers le registre npm public qui fonctionne comme un point de contact unique avec le monde extérieur.

Tous les autres registres internes utiliseront ce registre unique de pare-feu comme source de packages. Cela permet d’avoir un point central où les équipes de sécurité peuvent surveiller et s’assurer que seuls les packages approuvés sont inclus.

En utilisant un pare-feu de dépendance de cette manière, les nouveaux packages et les nouvelles versions ne sont pas automatiquement transmis à tous les autres utilisateurs et applications d’une organisation.

Avoir le même niveau de sécurité pour tous les packages

Utilisez Bytesafe pour rassembler vos différentes équipes (Dev / DevOps / DevSecOps) afin de collaborer sur la sécurité de vos dépendances.

À moins que vous n’ayez explicitement configuré l’utilisation d’un registre privé, le choix par défaut est d’utiliser directement le registre public. Le client npm permet en réalité d’installer des packages à partir d’un registre npm ou directement à partir d’un dépôt git.

Afin d’ajouter une couche de sécurité, vous devez vous assurer que l’ensemble de l’organisation utilise des registres privés pour vos propres packages qui obtiennent par proxy les packages du registre public npm.

De cette façon, vous pouvez savoir quels packages sont utilisés dans une application et vous avez la possibilité de décider et de contrôler le niveau de sécurité.

En mettant en place une hiérarchie de registres avec différents niveaux de sécurité (curation et séparation des registres), vous pouvez imposer les politiques et plugins de Bytesafe sur tous vos packages, qu’ils proviennent d’un registre npm ou d’un repo git.

Par conséquent, tous les développeurs et les systèmes utilisant des packages npm devraient être configurés pour utiliser des registres privés de Bytesafe offrant une sécurité et un contrôle plus élevés.

Quelle niveau de sécurité apporte Bytesafe ?

Le fait que tous vos packages et dépendances de code externe soient centralisés dans Bytesafe permet de surveiller, d’analyser et de contrôler en permanence le code que vous utilisez.

Savoir quel code vous utilisez (et le développeur du code) est essentiel pour sécuriser votre chaîne d’approvisionnement de code. Faites du shift-left testing et identifiez les éventuels problèmes dès le début du SDLC !

L’utilisation de Bytesafe donne accès :

• Au registres privés. Partagez vos packages au sein des équipes dans des registres d’archives entièrement gérés. Mettez en cache les dépendances externes pour vous assurer qu’elles sont toujours disponibles.
• A l’identification de toutes les dépendances. Identifiez les dépendances que vous utilisez. Détectez immédiatement si des dépendances directes et transitives sont marquées comme obsolètes.
• Au Pare-feu de dépendances. Limitez les packages autorisés dans vos registres avec des politiques et des plugins.
• A l’analyse de sécurité. Faites du shift-left testing et détectez les vulnérabilités rapidement en analysant continuellement tous les packages.
• A la conformité des licences. Analysez les licences que vous incluez dans vos applications et déterminez si vous avez des problèmes de licence.
• Aux résultats déterministes. Assurez-vous d’utiliser Bytesafe dans votre pipeline CI/CD à travers différents environnements. Les testeurs pourront tester exactement les mêmes versions que celles prévues par les développeurs. Fini les erreurs de configuration
• Au regroupement de votre équipe. Permettez aux développeurs, au service d’assurance qualité, aux experts en sécurité et aux équipes commerciales d’utiliser les mêmes outils pour éviter une coupure interne entre les différents rôles. La sécurité est un travail d’équipe!