Le nouveau logiciel développé au MIT se révèle capable de réparer de façon autonome les erreurs logicielles par des emprunts auprès d’autres programmes et à travers différents langages de programmation, sans nécessiter l’accès au code source. Cela pourrait faire économiser à des milliers de développeurs, des heures de temps de programmation et mener à un logiciel beaucoup plus stable.

Les erreurs ou les bugs sont le fléau du développeur du logiciel. Les changements qui doivent être faits pour les corriger sont souvent triviaux, impliquant généralement le changement seulement de quelques lignes de code, mais le processus d’identification pour détecter exactement quelles lignes doivent être modifiées, peut être un processus fastidieux et souvent très frustrant, en particulier dans les grands projets.

Mais aujourd’hui, un nouveau logiciel du MIT pourrait prendre soin de cela, et plus encore. Le système, baptisé CodePhage, peut corriger les bugs qui ont à voir avec des contrôles variables, et pourrait bientôt être élargi pour réparer beaucoup plus de types d’erreurs.

De manière remarquable, selon le chercheur du MIT, Stelios Sidiroglou-Douskos, le logiciel peut faire ce genre de traduction et de transplantation dynamiques (surnommé « Horizontal code transplant » ou « Transplantion de greffe horizontal, » à partir du procédé analogue en génétique) sans avoir accès au code source et à travers différents langages de programmation, en analysant directement le fichier exécutable directly.

Comment cela fonctionne ?

A titre d’exemple, disons que vous avez écrit un programme informatique simple qui demande à l’utilisateur d’entrer deux nombres et renvoie le premier nombre divisé par le second. Disons aussi que, dans votre code, vous avez oublié de vérifier que le second nombre est non nul (une division par zéro est mathématiquement indéfinie).

CodePhage commence avec une application (« buggée ») et deux entrées – une qui ne déclenche aucune erreur (« entrée sûre») et celle qui le fait (« entrée non sûre »). En utilisant une grande base de données d’applications, elle en trouve une (application) qui peut lire et traiter correctement les deux entrées. Dans notre cas, le système devait chercher dans un vaste entrepôt de données, une fonction qui peut diviser deux nombres en toute sécurité.

« Nous avons des tonnes de code source disponibles dans les entrepôts open-source, des millions de projets, et beaucoup de ces projets mettent en œuvre des spécifications similaires, » précise Stelios Sidiroglou-Douskos. « Même si cela peut n’est peut-être pas la fonctionnalité de base du programme, il y a souvent des sous-composants qui partagent cette fonctionnalité à travers un grand nombre de projets. »

Le système fait la différence entre un programme «donneur» – le logiciel à partir duquel le correctif sera emprunté – et un programme «bénéficiaire» – le code vérolé que le système du MIT va essayer de réparer.

La première étape consiste à alimenter l’entrée « sûre » au code « donneur » et de suivre dynamiquement les contraintes qui sont imposées sur les variables d’entrée. Ensuite, le logiciel fait la même chose avec la deuxième entrée «non sûre» et compare les deux ensembles de contraintes. Les points de divergence entre les deux identifient une contrainte qui a été rencontrée par l’entrée sûre, mais pas par l’entrée « non sûre », et est donc susceptible d’être un contrôle de sécurité qui manque dans le code « bénéficiaire ».

Dans notre exemple, l’entrée sûre serait le diviseur étant un nombre quelconque non nul, et l’entrée non sûre serait le diviseur étant nul. Le système MIT détectera que la condition «diviseur doit être différent de zéro » est atteinte par l’entrée sûre, mais pas par l’entrée non sûre, identifiant correctement que la vérification pour cette condition spécifique est manquante dans le code « bénéficiaire » et est la cause probable du bogue.

À ce stade, CodePhage prendra toutes les divergences dans les contrôles d’entrée dans le logiciel « donneur » et les traduira dans le langage de programmation du logiciel du destinataire. Le système va alors essayer d’ajouter les nouveaux contrôles pour le code source du programme destinataire dans différentes parties du code, jusqu’à ce que l’entrée non sûre soit traitée correctement (et que le programme se comporte toujours comme prévu lorsqu’il est vérifié par une suite de tests).

Vers des logiciels sans bug?

« La vision à long terme est que vous ne devriez jamais écrire un morceau de code que quelqu’un d’autre a écrit avant, » assure le professeur Martin Rinard du MIT, qui faisait partie de l’étude. « Le système trouve ce morceau de code et le place automatiquement en même temps avec quelque morceaux de code que vous auriez dû écrire pour que votre programme fonctionne »

Martin Rinard et son équipe disent qu’un développeur pourrait, par exemple, réduire le développement et les efforts de test en omettant les vérifications des entrées illégales, et ensuite utiliser leur outil pour transférer automatiquement des contrôles de logiciel plus robustes, y compris des applications propriétaires.

Selon les chercheurs, dans le logiciel commercial moderne, des contrôles de sécurité peuvent prendre jusqu’à 80 % du code – et donc l’impact sur les temps de programmation pourrait, au moins en théorie, être assez important. Qui plus est, alors que le système est actuellement limité à l’analyse des contrôles de variables, les chercheurs affirment que les mêmes techniques sont également conçues pour suivre, extraire et insérer tout calcul, tant que le système est capable d’identifier correctement les valeurs attribuées aux variables dans le logiciel « donneur ».

Le système du MIT pourrait également être utilisé pour transférer des contrôles entre les différentes versions de la même application, pour essayer d’empêcher que les correctifs et les mises à jour logicielles nouvellement disponibles introduisent de nouveaux bogues.

Testé sur sept programmes open-source classiques, CodePhage aurait été en mesure de rafistoler le code vulnérable à chaque fois, en prenant un maximum de 10 minutes par réparation. Dans les versions futures, les chercheurs espèrent réduire ce temps de latence autant que possible.

http://newsoffice.mit.edu/2015/automatic-code-bug-repair-0629

http://dl.acm.org/citation.cfm?id=2737988