Análisis de código estático

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 13 de agosto de 2021; las comprobaciones requieren 6 ediciones .

El análisis de código estático es un  análisis de software realizado (a diferencia del análisis dinámico ) sin ejecutar realmente los programas bajo estudio. En la mayoría de los casos, el análisis se realiza en alguna versión del código fuente , aunque a veces se analiza algún tipo de código objeto, como el código P o el código MSIL . El término generalmente se aplica al análisis realizado por un software especial (software), mientras que el análisis manual se denomina "comprensión del programa", "comprensión del programa" ( comprensión o comprensión de un programa).

Dependiendo de la herramienta utilizada, la profundidad del análisis puede variar desde determinar el comportamiento de declaraciones individuales hasta un análisis que incluye todo el código fuente disponible. Las formas de usar la información obtenida durante el análisis también son diferentes: desde identificar lugares que pueden contener errores (utilidades como Lint ), hasta métodos formales que le permiten probar matemáticamente cualquier propiedad del programa (por ejemplo, el cumplimiento del comportamiento con la especificación).

Algunas personas consideran que las métricas de software y la ingeniería inversa son formas de análisis estático. La obtención de métricas ( objetivos de calidad del software en inglés  ) y el análisis estático suelen combinarse, sobre todo a la hora de crear sistemas embebidos. [una]


Principios del análisis estático

La mayoría de los compiladores (por ejemplo, GNU C Compiler ) muestran " advertencias " ( advertencias en inglés  ), mensajes de que el código, siendo sintácticamente correcto, muy probablemente contiene un error. Por ejemplo:

intx ; _ int y = x + 2 ; // ¡La variable x no está inicializada!

Este es el análisis estático más simple. El compilador tiene muchas otras características importantes: en primer lugar, la velocidad de trabajo y la calidad del código de la máquina, por lo que los compiladores verifican el código solo en busca de errores obvios. Los analizadores estáticos están diseñados para un análisis de código más detallado.

Tipos de errores detectados por analizadores estáticos

  • Comportamiento indefinido  : variables no inicializadas, acceso a punteros NULL. Los compiladores también señalan los casos más simples.
  • Violación del algoritmo para usar la biblioteca. Por ejemplo, cada uno fopennecesita fclose. Y si la variable del archivo se pierde antes de que se cierre el archivo, el analizador puede informar un error.
  • Escenarios comunes que conducen a un comportamiento no documentado de . La biblioteca estándar de C es notoria por sus muchas fallas técnicas. Algunas funciones, como gets, son inherentemente inseguras. sprintfy strcpyseguro sólo bajo ciertas condiciones.
  • Un desbordamiento de búfer  es cuando un programa de computadora escribe datos más allá de los límites de un búfer asignado en la memoria.
void hacerAlgo ( const char * x ) { caracteres [ 40 ] ; sprintf ( s , "[%s]" , x ); // sprintf al búfer local, posible desbordamiento .... } Objeto * p = obtenerObjeto (); int pNum = reinterpret_cast < int > ( p ); // verdadero en x86-32, parte del puntero se perderá en x64; necesita intptr_t
  • Errores en código repetitivo. Muchos programas ejecutan lo mismo varias veces con diferentes argumentos. Por lo general, los fragmentos repetidos no se escriben desde cero, sino que se duplican y corrigen.
destino _ x = origen . x + dx ; destino _ y = origen . y + dx ; // ¡Error, necesito dy!
  • Errores de cadena de formato: en funciones como esta, printfpuede haber errores con una cadena de formato que no coincide con el tipo real de parámetros.
std :: wstrings ; _ printf ( "s es %s" , s );
  • El parámetro sin cambios pasado a la función es una señal de los requisitos modificados para el programa. Una vez que el parámetro estaba habilitado, pero ahora ya no es necesario. En este caso, el programador puede deshacerse de este parámetro por completo, y de la lógica asociada con él.
void doSomething ( int n , bool flag ) // flag siempre es verdadero { si ( bandera ) { // algo de lógica } más { // el código está ahí, pero no se usa } } hacerAlgo ( n , verdadero ); ... hacerAlgo ( 10 , verdadero ); ... hacerAlgo ( x.size ( ) , true );
  • Fugas de memoria y otros recursos. En aras de la equidad, se debe tener en cuenta que, en general, los analizadores estáticos pierden frente a los analizadores de códigos dinámicos en el campo de la detección de fugas. [2]
Traverser * t = new Traverser ( Nombre ); si ( ! t -> Válido ()) { devuelve FALSO ; // Accidentalmente escribió return antes de eliminar. eliminar t ; }
  • Otros errores: muchas funciones de las bibliotecas estándar no tienen efectos secundarios y llamarlas como procedimientos no tiene sentido.
std :: cadenas ; _ ... s . vacío (); // el código no hace nada; probablemente quisiste decir s.clear()?

Aplicación

Recientemente, el análisis estático se ha utilizado cada vez más para verificar las propiedades del software utilizado en sistemas informáticos altamente confiables, especialmente críticos para la vida (críticos para la seguridad).). También se usa para encontrar código que potencialmente contiene vulnerabilidades (a veces llamado Prueba de seguridad de aplicaciones estáticas , SAST). [3]

El análisis estático se usa constantemente para software crítico en las siguientes áreas:

  1. Software para dispositivos médicos. [cuatro]
  2. Software para centrales nucleares y sistemas de protección de reactores ( Reactor Protection Systems ) [5]
  3. Software de aviación (combinado con análisis dinámico) [6]
  4. Software en el transporte por carretera o ferroviario [7]

Según los datos de VDC para 2012, aproximadamente el 28 % de los desarrolladores de software integrado utilizan herramientas de análisis estático y el 39 % comenzará a utilizarlas dentro de 2 años. [ocho]

Métodos formales

Herramientas de análisis estático

Herramientas de lenguaje de análisis, algunas de las cuales son destacadas por CISO CLUB [9] :

C/C++:

C#:

Java:

JavaScript:

.RED:

  • .NET Compiler Platform ( Roslyn ) es un marco de compilación para C# y VB.NET que proporciona una interfaz para el analizador.
  • fxcop
  • Microsoft FxCop
  • NDepende
  • Estudio PVS
  • Reafilado
  • policía de estilo
  • YASCA

PHP:

Pitón: [11] [12]

  • escama8
  • grado
  • Pychecker
  • pilinto
  • McCabe
  • hojuelas
  • pycodestyle
  • Screener de aplicaciones solares
  • YASCA

rubí:


Otro:

  • T-SQL Analyzer es una herramienta que puede ver módulos de programa en bases de datos que ejecutan Microsoft SQL Server 2005 o 2008 y detectar posibles problemas relacionados con la mala calidad del código.
  • AK-VS 2 de CJSC NPO Echelon (Búsqueda de NDV, identificación de patrones peligrosos por CWE[13] )
  • SonarQube  es una plataforma de análisis de código y gestión de calidad con soporte para varios lenguajes de programación a través de un sistema de plugins.
  • AppChecker es un analizador de código estático comercial de NPO ESHELON diseñado para la búsqueda automatizada de defectos en el código fuente de aplicaciones desarrolladas en C#, C/C++, Java, PHP.
  • Svace es una herramienta de análisis estático desarrollada en ISP RAS . Soporta lenguajes de programación C/C++, Java, C#. [catorce]

Véase también

Notas

  1. ↑ Objetivos de calidad del software para el código fuente. Actas de la Conferencia Embedded Real Time Software and Systems 2010 , ERTS2, Toulouse, Francia: Patrick Briand, Martin Brochet, Thierry Cambois, Emmanuel Coutenceau, Olivier Guetta, Daniel Mainberte, Frederic Mondot, Patrick Munier, Loic Noury, Philippe Spozio, Frederic Retailleau http: //www.erts2010.org/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010/ERTS2010_0035_final.pdf Archivado el 12 de marzo de 2012 en Wayback Machine .
  2. ↑ Sí, PVS-Studio puede detectar fugas de memoria . Archivado el 15 de mayo de 2018 en Wayback Machine /PVS Studio Blog.
  3. ↑ Improving Software Security with Precise Static and Runtime Analysis, Benjamin Livshits, sección 7.3 "Técnicas estáticas para la seguridad", tesis doctoral de Stanford, 2006. http://research.microsoft.com/en-us/um/people/livshits/papers /pdf/thesis.pdf Archivado el 5 de junio de 2011 en Wayback Machine .
  4. ↑ Investigación de seguridad del software de la bomba de infusión de la FDA en la FDA . Administración de Alimentos y Medicamentos (8 de septiembre de 2010). Consultado el 9 de septiembre de 2010. Archivado desde el original el 1 de septiembre de 2010.
  5. ↑ Sistemas de seguridad basados ​​en computadora: orientación técnica para evaluar aspectos de software de sistemas de protección basados ​​en computadora digital, http://www.hse.gov.uk/nuclear/operational/tech_asst_guides/tast046.pdf Archivado el 9 de octubre de 2012 en Wayback Machine .
  6. ↑ Documento de posición CAST-9. Consideraciones para evaluar los enfoques de ingeniería de seguridad para Software Assurance Archivado el 6 de octubre de 2013 en Wayback Machine // FAA, Equipo de software de las autoridades de certificación (CAST), enero de 2002: “Verification. El solicitante/desarrollador debe especificar una combinación de análisis estáticos y dinámicos y aplicarla al software”.
  7. ↑ Bill Graham. Análisis estático, software ferroviario de seguridad crítica y EN 50128 . Consultado el 2 de septiembre de 2016. Archivado desde el original el 25 de agosto de 2016.
  8. ↑ Prevención de defectos automatizada de investigación de VDC para la calidad del software integrado . Investigación de VDC (1 de febrero de 2012). Consultado el 10 de abril de 2012. Archivado desde el original el 7 de abril de 2012.
  9. ↑ TOP herramientas gratuitas para análisis de código estático  (ruso)  ? . cisoclub.ru (11 de febrero de 2021). Consultado el 19 de noviembre de 2021. Archivado desde el original el 19 de septiembre de 2021.
  10. ↑ Analizador estático de Clang . clang-analyzer.llvm.org. Consultado el 14 de mayo de 2016. Archivado desde el original el 8 de octubre de 2011.
  11. ↑ Anand Balachandran Pillai. Arquitectura de Software con Python. - Packt Publishing Ltd, 2017. - P. 63-64.
  12. ↑ Adam Goucher, Tim Riley. Hermosas pruebas: los principales profesionales revelan cómo mejoran el software . - O'Reilly Media, Inc., 2009. - Pág  . 126 .
  13. ↑ Auditoría del código del programa para requisitos de seguridad: seguridad de la información, auditoría, código del programa, seguridad, Alexey Markov, Valentin Tsirlov, CISSP, código de seguridad... Copia de archivo fechada el 27 de mayo de 2016 en Wayback Machine , NPO Echelon CJSC
  14. ↑ Analizador estático Svace. Búsqueda industrial de errores críticos en el ciclo de desarrollo de software seguro . Consultado el 10 de noviembre de 2017. Archivado desde el original el 21 de junio de 2018.

Enlaces