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.