• [^] # Re: Et le fuzzing alors ?

    Posté par . En réponse au journal Le gouvernement US paie l'audit de projets libres (la suite). Évalué à 7.

    Les deux approches sont intéressantes et complémentaires. Une analyse statique permet par exemple de trouver tous les cas (sans exceptions, mais peut-être avec des faux positifs si l'analyse n'est pas assez précise) où on aurait fait une erreur dans la gestion de ses pointeurs, plus généralement de montrer qu'un programme n'a jamais de 'Runtime Exception' (voir par exemple http://www.astree.ens.fr/ : analyse statique des logiciels critiques des Airbus ; bon évidemment ça ne protège pas des bugs liés au matériel). Ça peut aussi permettre de montrer qu'on n'a pas de fuite de mémoire, de dépassement de tampon, etc. etc.
    Tous ces bugs, quoique n'ayant que peu de chances d'arriver, peuvent induire des failles de sécurité importantes, il est nécessaire de les corriger.

    Alors forcément puisque l'analyse statique prend en compte toutes les possibilités d'exécution d'un programme, elle est moins précise qu'une analyse dynamique.

    L'analyse dynamique elle ne prend en compte que quelques (ça peut être beaucoup mais on ne va jamais tester toutes les valeurs possibles d'un entier aléatoire par exemple... Surtout s'il fait 64 bits ;-) ) exécutions. Elle est plus précise et très ciblée. Par exemple il peut s'agir de vérifier les types d'arguments à l'exécution. Elle fournit moins d'erreurs et permet de cibler beaucoup plus précisément quel type de comportement on veut analyser, en cela elle est tout à fait complémentaire à l'analyse statique.