lundi, 6 décembre 2021

Analyse de la composition logicielle : comment elle identifie les risques liés aux logiciels open source

Crédit : Elle Aon/ Shutterstock

L’analyse de la structure du logiciel (SCA) décrit comment obtenir un aperçu quels composants et dépendances open source sont utilisés dans votre application, et comment, le tout de manière automatisée.

Ce processus sert à évaluer la sécurité de ces pièces et tout danger potentiel ou conflit de licence qu’elles pourraient engendrer.

Intégrer correctement les outils SCA dans votre flux de travail d’avancement logiciel est un action substantielle visant à améliorer la sécurité et l’intégrité de la chaîne d’approvisionnement des applications logicielles en garantissant que tout code emprunté n’introduit pas de dangers pour la sécurité ou de problèmes de conformité légale dans vos produits.

Pourquoi l’analyse de la structure logicielle est nécessaire

L’époque où les applications logicielles étaient créées à partir de zéro est révolue. L’adoption généralisée de logiciels open source a en fait changé le développement d’applications. Les concepteurs indépendants et les entreprises peuvent utiliser des parties et des bibliothèques existantes dans leur code pour mettre en œuvre des performances allant des validations de type Web simples aux opérations cryptographiques complexes.

Bien que la réutilisation du code open source ait principalement éliminé le besoin de réinventer la roue, avec quelques mises en garde : et si le code que vous empruntez comporte des bogues ou des failles de sécurité ? De plus, que se passe-t-il si les termes de la licence portée par la partie open source entrent en conflit avec la licence de votre application ? Qui doit examiner tout cela ?

Évaluer de nombreuses pièces peut être un travail de base à effectuer à la main, mais les applications logicielles modernes sont construites à l’aide de centaines de bibliothèques. Ces bibliothèques peuvent elles-mêmes avoir d’autres dépendances. Cette procédure peut exécuter de nombreuses couches en profondeur, et avant que vous ne la compreniez, votre application qui semble autrement consister simplement en une poignée de bibliothèques, peut dessiner des centaines ou d’innombrables dépendances transitives. C’est là que SCA concerne le sauvetage.

Analyse de la composition logicielle et SBOM

De nombreux outils SCA peuvent produire une nomenclature logicielle (SBOM). Un SBOM est un compte rendu détaillé de l’inventaire – toutes les dépendances et les pièces qui composent votre application. Un SBOM parfait fournit le nom de la pièce, le numéro de version, la date de publication, la somme de contrôle, les détails de la licence pour nommer quelques métadonnées pour chaque pièce présente dans votre application.

Cela peut être effectué de deux manières :

  1. Analyse des manifestes : l’outil SCA analyse les fichiers manifestes de build de votre application, tels que package.json, pour JavaScript ou pom.xml pour les tâches Apache Maven (Java) et produit une liste de dépendances dans celui-ci. Cette technique fonctionne lorsque les concepteurs numérisent des applications sans que les artefacts de construction finale ne soient inclus dans ou à partir d’un système de contrôle de variation (par exemple, GitHub, GitLab ou SVN).
  2. Analyse binaire : Le L’outil SCA analyse vos artefacts de développement et détermine les composants open source via une empreinte binaire. Ce processus reconnaît tous les plans contenus dans le dernier développement de votre application, ce qui minimise les erreurs positives et capture les applications logicielles et les bibliothèques tierces contribuées à votre application selon une méthode non standard. Tous les outils SCA ne disposent pas de capacités d’analyse binaire.
  3. Analyse des manifestes et des binaires : Certaines options SCA peuvent opter pour une approche hybride : analyser à la fois les manifestes et les binaires pour obtenir des SBOM très précis . L’élégance de votre solution SCA détermine avec quelle précision elle peut identifier toutes les pièces cachées dans votre application.

Comment les outils SCA aident-ils à trouver les vulnérabilités open source ?

Les outils SCA automatisés peuvent aider les groupes de logiciels à créer et à livrer du code premium et donner aux parties prenantes une méthode proactive de gestion des risques. En identifiant les vulnérabilités et les menaces de sécurité dès le début du processus de développement logiciel, les outils SCA peuvent permettre aux développeurs de logiciels de sélectionner des éléments plus sûrs et sécurisés dès le départ.

Cet avantage accélère le processus d’avancement en minimisant le besoin d’évaluations de sécurité répétitives, car un soin adéquat est apporté dès le début lors de l’inclusion de pièces et de bibliothèques tierces dans une application.

Si un une partie avec des menaces et des vulnérabilités reconnues est absolument nécessaire, les équipes de développement peuvent porter un jugement lorsque l’élément est présenté pour la première fois et envisager d’adopter des solutions de contournement possibles pour utiliser le composant en toute sécurité.

L’objectif de la procédure et des outils SCA ne se limite pas simplement à analyser les sources et les binaires de votre application pour produire un SBOM. La difficulté clé dépend de la mise en correspondance correcte de chaque variation de la pièce avec des vulnérabilités comprises. L’aspect conformité est encore plus important : laisser les parties prenantes examiner et résoudre parfaitement les conflits de licence posés par les composants.

Il y a quelques années, la procédure aurait pu être simple. Il aurait suffi de passer en revue les flux CVE fournis par MITRE ou NVD et de les mapper aux versions d’éléments présentes dans votre application.

Une recherche composée d’un article produit par l’Université de Floride centrale, George Mason et Georgia Tech a révélé que les avis CVE peuvent souvent ne pas être fiables et inclure des disparités. D’autres fois, les données CVE peuvent être mal interprétées en raison de la manière dont les informations d’énumération de plate-forme type (CPE) existent dans ces avis.

Par exemple, un avis CVE publié pour une vulnérabilité dans le serveur Tomcat peut utiliser uniquement un élément sélectionné sous l’espace de noms Apache Tomcat, tel que org.apache.tomcat : coyote au lieu de l’ensemble de l’espace de noms Apache Tomcat, mais cela peut ne pas être clair à partir des CPE mentionnés dans l’avis.

Lire la suite sur la page suivante…

Page

  • 1
  • 2
  • suivant

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici