Pourquoi faut-il intégrer les librairies tierces dans une analyse statique avancée ?
Pourquoi faut-il intégrer les librairies tierces dans une analyse statique avancée ?
L’analyse statique de code source permet de détecter rapidement certains types de problèmes dans le cycle de développement logiciel. Cependant, les solutions actuelles ne tiennent pas compte d’un élément fondamental : presque tous les projets embarqués utilisent au moins une librairie binaire tierce…
Comment fonctionne l’analyse statique avancée ?
Contrairement à l’analyse statique syntaxique, qui effectue une relecture linéaire d’un code source et dont le but est uniquement la vérification de règles de codage, l’analyse statique avancée crée un modèle du code contenant des informations sémantiques (chemins, valeurs possibles de variables, …). Ce modèle est ensuite reparcouru par l’analyseur dans le but de détecter des défauts potentiels ou d’autres propriétés intéressantes : l’outil identifie des « motifs » jugés semblables ou ressemblants à ceux créés par des erreurs logicielles.
Ainsi, plus le modèle créé contient l’ensemble du code source, plus il représente le logiciel complet, et donc plus les détections sont pertinentes.
Quel est le problème avec les librairies tierces ?
Les librairies tierces, c’est-à-dire ces portions de code qui ont été développées par des sociétés ou équipes extérieures, font partie intégrante d’un nouveau produit logiciel. Que ce soit un OS, un middleware, des drivers, une couche d’abstraction hardware fournie par un fabricant de microcontrôleur ou toute autre chose, une partie significative de la logique même de l’application réside à l’intérieur de ces librairies.
Lorsqu’il s’agit d’une librairie open source, ou dont on dispose du code source, cela ne constitue généralement pas un problème pour les analyseurs statiques. Mais quid des librairies dont on intègre uniquement un binaire déjà compilé, et dont le code source n’est pas disponible ? Ces éléments constituent des boites noires, dont les développeurs ne connaissent généralement pas le comportement ! Comment assurer la sûreté et/ou en cybersécurité de notre propre code source dans de telles conditions ? Même les librairies « certifiées » ne sont pas exemptes d’erreurs, voire de vulnérabilités…
Ces composants manquants réduisent drastiquement le rappel (le fait de trouver toutes les erreurs, donc d’éviter les faux négatifs) et la précision (le fait de ne trouver que des vraies erreurs, donc d’éviter les faux positifs) d’une analyse statique. Comme l’analyseur ne connait pas l’algorithme de cette librairie, il est contraint de faire des hypothèses, ce qui mène à plus de faux positifs et de faux négatifs, comme illustré dans les deux exemples ci-dessous :
Les librairies tierces, c’est-à-dire ces portions de code qui ont été développées par des sociétés ou équipes extérieures, font partie intégrante d’un nouveau produit logiciel. Que ce soit un OS, un middleware, des drivers, une couche d’abstraction hardware fournie par un fabricant de microcontrôleur ou toute autre chose, une partie significative de la logique même de l’application réside à l’intérieur de ces librairies.
Lorsqu’il s’agit d’une librairie open source, ou dont on dispose du code source, cela ne constitue généralement pas un problème pour les analyseurs statiques. Mais quid des librairies dont on intègre uniquement un binaire déjà compilé, et dont le code source n’est pas disponible ? Ces éléments constituent des boites noires, dont les développeurs ne connaissent généralement pas le comportement ! Comment assurer la sûreté et/ou en cybersécurité de notre propre code source dans de telles conditions ? Même les librairies « certifiées » ne sont pas exemptes d’erreurs, voire de vulnérabilités…
Ces composants manquants réduisent drastiquement le rappel (le fait de trouver toutes les erreurs, donc d’éviter les faux négatifs) et la précision (le fait de ne trouver que des vraies erreurs, donc d’éviter les faux positifs) d’une analyse statique. Comme l’analyseur ne connait pas l’algorithme de cette librairie, il est contraint de faire des hypothèses, ce qui mène à plus de faux positifs et de faux négatifs, comme illustré dans les deux exemples ci-dessous :
| packetT * myPacket; myPacket = malloc(sizeof(packetT)); if (handlePacket(myPacket) == -1) return -1; |
Allocation de mémoire par une librairie tierce (qui contient handlePacket): Est-ce que myPacket doit être initialisé après l'appel ? Est-ce que la librairie libèrera myPacket ou devrais-je le faire ? |
| XML_Parse(p, Buff, len, done) | Appel d’une fonction contenue dans une librairie tierce : Est-ce que la librairie va vérifier si p == NULL? Est-ce que la librairie dépassera la valeur de Buff, créant donc un buffer overrun ? Y a-t-il des chemins d'échec qui ne sont pas couverts et que je dois prévenir au sein de mon propre code source? |
Il est donc essentiel, au sein des applications modernes où la réutilisation de composants logiciels tiers est économiquement inévitable, d’analyser l’ensemble d’un code logiciel, librairies binaires comprises.
Comment intégrer les librairies tierces dans une analyse statique avancée ?
Heureusement, l’analyseur statique avancé GrammaTech CodeSonar intègre une fonctionnalité unique sur le marché d’analyse de librairies binaires x86/64 et ARM ne nécessitant aucune modification du binaire (il peut être optimisé ou sans information de debug). Ici, c’est le code assembleur qui est directement analysé, et le modèle créé est ensuite fusionné avec celui du code source applicatif, permettant à CodeSonar d’avoir une vision complète du code projet.
GrammaTech propose depuis plus de deux ans l’outil CodeSonar for Binaries, qui effectue des analyses approfondies des librairies binaires, en signalant les erreurs à l’intérieur même des librairies binaires.
Afin d’aider les équipes de développement utilisant des librairies binaires et soucieuses de maitriser l’ensemble de leur logiciel tout en limitant les coûts de mise en place d’outils, GrammaTech propose désormais l’option CodeSonar for Libraries, qui signale uniquement l’impact d’un binaire sur le code source applicatif, et donc qui augmente de façon significative la précision de l’analyse du code source.
