Le pouvoir donné aux développeurs de déployer des applications de manière rapide sans requérir d’intermédiaire peut alors mener à un niveau de risque plus élevé que la normale. En effet, ces composants sont désormais la cible de personnes malveillantes, qui exploitent les failles connues du composant ou en y injectant du code malveillant.

C’est alors que les équipes sécurité, généralement les premiers à détecter ces risques, font la grimace. Comment peuvent-elles être impliquées et partager la responsabilité de la sécurité de l’organisation ? Cette question, ou mieux encore sa version inclusive « Comment est-il possible de tenir compte de toutes les contraintes tout en atteignant l’objectif final, à savoir fournir des solutions utiles et sécurisées utilisables pour répondre aux objectifs de l’entreprise ? » refait à nouveau surface.

Voici alors une opportunité de donner de la visibilité et du contrôle à l’ensemble des intervenants et y inclure d’autres équipes, notamment les équipes en charge des aspects conformité. L’analyse de la composition des applications répond à ces besoins.

Identifier …

Diverses techniques existent pour identifier des failles de sécurité, notamment l’utilisation d’outils de tests, que ce soit en statique ou en dynamique, comme nous avons pu le voir dans un précédent article.

Ce type de tests se limite cependant à ce qui est directement visible et ne permet pas d’identifier les risques légaux liés à l’utilisation d’une licence open-source ou de piloter les changements applicatifs, notamment liés à la découverte de failles de sécurité dans un composant après le passage au banc de tests.

L’identification de ces vulnérabilités requiert la conjonction de différentes sources, y compris les outils de suivi des non-conformités. Encore faut-il que la qualité soit là. En effet, il peut être simple d’obtenir des faux-positifs si ces sources s’avèrent peu fiables. C’est là que l’humain intervient pour combler les trous laissés par l’intelligence artificielle, même si celle-ci est en permanente évolution, et identifier les causes de ce faux-positif. Il faut également que l’information soit disponible en temps et heure. C’est dans ce contexte qu’en plus des bases de données partagées, de l’information exploitée par les fournisseurs eux-mêmes s’avère utile.

Par ailleurs, l’identification des licences associées aux composants s’avère plus critique qu’il n’y parait. Certaines licences requièrent en effet de publier le code source d’une application lorsque celle-ci inclut l’un ou l’autre composant. Ainsi, il est nécessaire de pouvoir identifier la licence associée mais aussi les changements apportés au composant, ces licences pouvant évoluer dans le temps.

Pour parvenir à un niveau de contrôle adéquat, il s’agit de faire l’inventaire des composants d’une application et des dépendances entre ces composants, quelles que soient l’application et la méthode de packaging, et ce y compris pour les containers ou encore le serverless.

La transitivité des dépendances doit d’ailleurs être prise en compte, sans quoi l’exercice s’avère totalement inefficace. Sur base de cette liste, il est alors possible de lister les vulnérabilités connues au sein de ces composants ou encore les licences associées.

… et le faire savoir …

Avoir l’information disponible est une chose. La restituer intelligemment en est une autre. En effet, de nombreux acteurs doivent pourvoir disposer de ces données : les équipes développement, les équipes opérationnelles, la sécurité, le légal et l’équipe dirigeante, ce à quoi s’ajoutent les auditeurs et gestionnaires des licences. C’est ainsi que les systèmes en charge de l’analyse de la composition logicielle se doivent de proposer différents rapports avec des groupements et des filtres adaptés aux différents lecteurs.

En complément des filtres liés aux rapports, la navigation au sein de l’information est clé dans ce contexte. La sécurité se penchera davantage sur les vulnérabilités et le temps nécessaire au comble de ces vulnérabilités. Les équipes en charge des licences se pencheront plus sur les licences, idéalement associées au nombre d’occurrences de déploiement. Les équipes légales peuvent également analyser les différentes licences et ainsi identifier les risques qui y sont liés, et qui peuvent aller jusqu’à la publication complète du code source d’une application censée être le différentiateur de l’organisation.

Il est également important de pouvoir faire des comparatifs dans le temps, que ce soit au travers de rapports fixes ou mieux encore, définis sur base de critères que chacun peut prédéfinir. Cela permet notamment d’entrevoir l’évolution dans le temps, pour un périmètre donné. Dans ce contexte, il serait fort utile de pouvoir définir des objectifs par périmètre.

… pour réagir au mieux

Maintenant que l’information est accessible, il s’agit de réagir. Réagir rapidement peut s’avérer nécessaire dans bien des cas. Pour réagir vite, il s’agit de comprendre la situation actuelle et les solutions futures. Pour cela, de nombreux fournisseurs de solutions partagent de la documentation indiquant la disponibilité de nouvelles versions ou encore des changements à proprement parler, tant dans le code que la configuration des systèmes.

La seconde approche est d’avoir des automatismes, directement définis dans l’application : notifier, requérir des approbations et bien d’autres choses. Selon le système en place, cette approbation peut s’avérer une étape nécessaire, là où certains systèmes différentieront les composants approuvés des autres sans être restrictifs. L’automatisation peut d’ailleurs permettre d’approuver de manière automatique des composants sur base de critères donnés tels que le niveau de vulnérabilité et les licences utilisées. L’automatisme va jusqu’à la remédiation.

Faire réagir au plus tôt

En fonction du niveau de risque, tant au niveau de la sécurité ou du type de licences ou encore de la vie, il s’agit de notifier diverses équipes de l’évènement ou encore de simplement empêcher l’utilisation d’un composant en faute, notamment en le rendant indisponible dans son repository, pour autant que celui-ci le permette.

Le niveau de réaction doit se baser sur plusieurs facteurs dont le nombre d’utilisations des composants mais pas seulement. Les utilisateurs de ces systèmes doivent pouvoir garnir l’information déjà disponible avec des informations complémentaires, notamment le niveau de criticité des applications.  Ces informations permettent alors de définir des actions en fonction de la criticité de la vulnérabilité ou le niveau d’utilisation d’un composant et surtout dans quel contexte le composant est utilisé. En effet, le risque associé à l’utilisation d’un composant est très variable d’un applicatif à l’autre. L’utilisation d’un composant dans un applicatif bancaire ou utilisant des données sensibles tels que les applicatifs médicaux rendra le niveau de criticité bien plus élevé que l’applicatif interne en charge de la réservation de matériel, bien qu’il s’agisse du même composant.

Comment choisir son outil d’analyse de la composition des logiciels ?

• Pour quoi faire ?

Tout d’abord, il est nécessaire de définir une stratégie de gestion des composants, et une série d’objectifs, qui en découle.

La stratégie doit permettre, en effet, de répondre à certaines questions pour l’opérationnalisation :

Quelle structure mettre en place ?

Faut -il mettre en place une équipe centralisée ?

Et dans ce cas, quel est son rôle ?

Quelles sont les responsabilités des uns et des autres ?

Au-delà des développeurs, quelles sont les autres équipes qui interviennent dans l’organisation ?

En effet, tous les outils ne proposent pas tous les mêmes fonctionnalités ni avec la même approche. Ainsi, certains outils s’avèrent plus adaptés à certaines audiences et cas d’utilisation. Le niveau de tolérance aux faux-positifs, liés à l’organisation, doit également être pris en compte. L’approche proposée par les fournisseurs pour réduire les faux-positifs entre également en ligne de compte.

Quoi qu’il en soit, l’outil d’analyse se doit de couvrir un maximum de cas d’utilisations et de s’intégrer avec un plus grand nombre, et ce, afin d’éviter le besoin de passer d’une application à l’autre.

• Un élément d’un écosystème complet

L’outil d’analyse, pour être efficace, se doit de s’intégrer dans un écosystème. Certains outils excellent dans ce domaine puisqu’ils s’intègrent avec tout ou presque, là où d’autres se limitent à certains systèmes tiers, langages ou frameworks.

Un tel outil permet d’être exploité totalement lorsqu’il fournit de l’information directement aux développeurs, dans leur environnement de développement mais aussi au sein de leur pipeline CI/CD. De plus, il s’agit également de s’intégrer avec les outils tiers utilisés par les développeurs eux-mêmes, tant en entrée qu’en sortie : gestionnaire d’artefacts mais aussi les suivis des problèmes et les outils de sécurité afin de notifier directement ceux-ci de tout risque au niveau sécurité.

En entrée, les issues trackers publics peuvent s’avérer très intéressants puisqu’ils servent de référence. En sortie, il s’agit potentiellement de publier en retour des informations au sein des systèmes tiers afin de notifier, à la communauté de développeurs, les vulnérabilités ou les problèmes de licence par transitivité.

• Qui sont les acteurs sur ce marché ?

Dans le domaine de l’analyse des composants logiciels, WhiteSource, JFrog, Synopsys, Sonatype, WhiteHat, Veracode et quelques autres se partagent le marché. Par simplicité, ces types d’outils avaient été classés parmi le Static Application Security Testing avec des nuances (scan de références et non de code) mais il s’agit en fait de SCA (Software Composition Analysis). Cependant le SAST vise le code là où le SCA se focalise sur les associations de composants. L’idéal est un outil commun pour les deux sujets.

WhiteSource est le plus avancé si l’on en croit Forrester. Sa force est de couvrir un ensemble de besoins très larges, là où certains se focalisent sur l’un ou l’autre aspect, notamment du fait de leur présence sur des marchés de niche. Ainsi, certains favorisent la notion de dépôt ou encore le référentiel de code source auxquels sont greffées des solutions d’analyses. WhiteSource a pris l’autre pendant : s’interconnecter avec ces outils spécialisés. Sur le terrain, WhiteSource s’avère, en effet, adapté à une utilisation globale en proposant des utilisations de niveau plutôt élevé dans tous les domaines. Il faudra pousser l’utilisation de l’outil très loin pour rencontrer des besoins suffisamment spécialisés pour ne pas être couverts.

Prenons un autre exemple : JFrog, le leader dans le domaine des référentiels d’artefacts, s’avère également efficace dans le domaine, grâce au composant Xray. Pourtant, comparé aux leaders du marché, il s’avère qu’il y a de nombreuses limites puisque XRay scanne uniquement ce qui se trouve dans son propre référentiel. Ainsi, si JFrog Artifactory est l’unique référentiel, Xray devient fortement efficace. Fort heureusement, Artifactory peut se targuer d’agir en tant qu’intermédiaire pour récupérer des artefacts d’autres sources. Ainsi, il peut s’avérer parfois un peu léger quand il s’agit d’identifier au plus tôt. La combinaison des deux pourrait alors amener des résultats très intéressants, bien que l’un ou l’autre pourrait largement convenir dans des cas spécifiques.

En plus de cela, pour réagir au plus tôt, l’intelligence artificielle et le machine learning s’avèrent plus qu’utiles. Ainsi, plus le système aura accès un maximum de sources d’informations, notamment le code source lui-même, ce qui permet d’identifier comment les composants sont utilisés, plus il pourra apprendre des risques. Si l’envie vous venait d’envisager l’utilisation de telles solutions, n’oubliez pas de vérifier que le système lui-même n’envoie pas trop d’informations vers des services tiers, ce qui pourrait compromettre l’intégrité de vos données. Un comble quand on pense que l’introduction d’un tel outil a pour but d’identifier des vulnérabilités introduites grâce aux composants open source.

Comment démarrer une fois l’outil en place ?

L’outil a été choisi, c’est déjà une bonne chose puisqu’il permettra de rendre concrètes les actions mais aussi les résultats. Il s’agit alors de promouvoir la prise de conscience et la responsabilité au plus proche des ceux qui développement les applicatifs. Mais aussi, il s’agit de mettre en avant la collaboration entre entités, qu’il y ait une équipe centrale ou non. L’ensemble des équipes doivent partager des objectifs et non découpler les objectifs pour éviter la mise en compétition voire même la mise en opposition de celles-ci. Pour y arriver, il sera certainement nécessaire de mettre en place des formations en vue d’augmenter la connaissance des différents intervenants.

En parallèle à cela, il est nécessaire de définir des règles de gestion. On pourrait être tenté de définir l’ensemble des règles et de chercher à s’y tenir absolument. L’agilité et la progressivité seront pourtant des facteurs clés pour permettre à chacun de comprendre et apprendre.

Avant de chercher à bloquer l’utilisation d’un composant, il s’avère certainement bien plus utile d’identifier les composants et de comprendre ceux-ci pour mieux identifier les sources de risques. Encore une fois, l’accompagnement de l’ensemble des intervenants est certainement une clé importante, que ce soit par l’équipe centrale ou une équipe formée temporairement pour accompagner les autres.