Análisis de programas estáticos

En informática , el análisis estático de programas (también conocido como análisis estático o simulación estática ) es el análisis de programas informáticos realizado sin ejecutarlos, en contraste con el análisis dinámico de programas , que se realiza sobre los programas durante su ejecución en el entorno integrado. ^{[1] [2]}

El término se aplica generalmente al análisis realizado por una herramienta automatizada, y el análisis humano se suele denominar "comprensión del programa", " comprensión del programa " o "revisión del código" . En este último caso, también se utilizan la inspección y los recorridos de software . En la mayoría de los casos, el análisis se realiza en alguna versión del código fuente de un programa y, en otros casos, en alguna forma de su código objeto .

La sofisticación del análisis que realizan las herramientas varía desde aquellas que sólo consideran el comportamiento de declaraciones y enunciados individuales ^[3] hasta aquellas que incluyen el código fuente completo de un programa en su análisis. Los usos de la información obtenida del análisis varían desde resaltar posibles errores de codificación (por ejemplo, la herramienta lint ) hasta métodos formales que prueban matemáticamente propiedades sobre un programa dado (por ejemplo, su comportamiento coincide con el de su especificación).

Las métricas de software y la ingeniería inversa pueden describirse como formas de análisis estático. La derivación de métricas de software y el análisis estático se utilizan cada vez más de forma conjunta, especialmente en la creación de sistemas integrados, mediante la definición de los denominados objetivos de calidad del software . ^[4]

Un uso comercial cada vez mayor del análisis estático es la verificación de propiedades del software utilizado en sistemas informáticos críticos para la seguridad y la localización de código potencialmente vulnerable . ^[5] Por ejemplo, las siguientes industrias han identificado el uso del análisis de código estático como un medio para mejorar la calidad de un software cada vez más sofisticado y complejo:

1. Software médico : La Administración de Alimentos y Medicamentos de los Estados Unidos (FDA) ha identificado el uso del análisis estático para dispositivos médicos. ^[6]
2. Software nuclear: En el Reino Unido, la Oficina de Regulación Nuclear (ONR) recomienda el uso de análisis estático en los sistemas de protección de reactores . ^[7]
3. Software de aviación (en combinación con análisis dinámico ). ^[8]
4. Automoción y máquinas (las características de seguridad funcional forman parte integral de cada fase de desarrollo de un producto automotor, ISO 26262 , sección 8).

Un estudio de 2012 realizado por VDC Research reveló que el 28,7% de los ingenieros de software integrado encuestados utilizan herramientas de análisis estático y el 39,7% espera utilizarlas en los próximos dos años. ^[9] Un estudio de 2010 descubrió que el 60% de los desarrolladores entrevistados en proyectos de investigación europeos utilizaban al menos los analizadores estáticos integrados en su IDE básico. Sin embargo, solo alrededor del 10% empleaba otra herramienta de análisis adicional (y quizás más avanzada). ^[10]

En la industria de seguridad de aplicaciones también se utiliza el nombre de pruebas estáticas de seguridad de aplicaciones (SAST, por sus siglas en inglés). SAST es una parte importante de los ciclos de vida de desarrollo de seguridad (SDL, por sus siglas en inglés), como el SDL definido por Microsoft ^[11] y una práctica común en las empresas de software. ^[12]

El OMG ( Object Management Group ) publicó un estudio sobre los tipos de análisis de software necesarios para la medición y evaluación de la calidad del software . Este documento sobre "Cómo ofrecer sistemas de TI resilientes, seguros, eficientes y fácilmente modificables de acuerdo con las recomendaciones de CISQ" describe tres niveles de análisis de software. ^[13]

Nivel de unidad

Análisis que se lleva a cabo dentro de un programa o subrutina específica, sin conectarse con el contexto de ese programa.

Nivel de tecnología

Análisis que tiene en cuenta las interacciones entre los programas de la unidad para obtener una visión más holística y semántica del programa general con el fin de encontrar problemas y evitar falsos positivos obvios.

Nivel del sistema

Análisis que tiene en cuenta las interacciones entre programas unitarios, pero sin limitarse a una tecnología o lenguaje de programación específico.

Se puede definir un nivel adicional de análisis de software.

Nivel de misión/negocio

Análisis que tiene en cuenta los términos, reglas y procesos de la capa de negocio/misión que se implementan dentro del sistema de software para su funcionamiento como parte de las actividades de la capa de empresa o de programa/misión. Estos elementos se implementan sin limitarse a una tecnología o lenguaje de programación específico y, en muchos casos, se distribuyen en varios lenguajes, pero se extraen y analizan de forma estática para comprender el sistema y garantizar la misión.

El término métodos formales se aplica al análisis de software (y hardware de computadoras ) cuyos resultados se obtienen únicamente mediante el uso de métodos matemáticos rigurosos. Las técnicas matemáticas utilizadas incluyen la semántica denotacional , la semántica axiomática , la semántica operacional y la interpretación abstracta .

Mediante una reducción directa al problema de la detención , es posible demostrar que (para cualquier lenguaje completo de Turing ), encontrar todos los posibles errores de ejecución en un programa arbitrario (o, de manera más general, cualquier tipo de violación de una especificación en el resultado final de un programa) es indecidible : no existe un método mecánico que pueda responder siempre con veracidad si un programa arbitrario puede o no presentar errores de ejecución. Este resultado data de los trabajos de Church , Gödel y Turing en la década de 1930 (véase: Problema de la detención y Teorema de Rice ). Como sucede con muchas cuestiones indecidibles, todavía se pueden intentar dar soluciones aproximadas útiles.

Algunas de las técnicas de implementación del análisis estático formal incluyen: ^[14]

• Interpretación abstracta , para modelar el efecto que cada enunciado tiene sobre el estado de una máquina abstracta (es decir, 'ejecuta' el software basándose en las propiedades matemáticas de cada enunciado y declaración). Esta máquina abstracta sobreaproxima los comportamientos del sistema: el sistema abstracto se vuelve así más simple de analizar, a expensas de la incompletitud (no cada propiedad verdadera del sistema original es verdadera del sistema abstracto). Sin embargo, si se hace correctamente, la interpretación abstracta es sólida (cada propiedad verdadera del sistema abstracto puede mapearse a una propiedad verdadera del sistema original). ^[15]
• Análisis de flujo de datos , una técnica basada en celosía para recopilar información sobre el posible conjunto de valores;
• Lógica de Hoare , un sistema formal con un conjunto de reglas lógicas para razonar rigurosamente sobre la corrección de los programas informáticos . Hay soporte de herramientas para algunos lenguajes de programación (por ejemplo, el lenguaje de programación SPARK (un subconjunto de Ada ) y el lenguaje de modelado Java —JML— utilizando ESC/Java y ESC/Java2 , el complemento Frama-C WP ( precondición más débil ) para el lenguaje C ampliado con ACSL ( lenguaje de especificación C ANSI/ISO )).
• La verificación de modelos considera sistemas que tienen un estado finito o que pueden reducirse a un estado finito por abstracción ;
• Ejecución simbólica , tal como se utiliza para derivar expresiones matemáticas que representan el valor de variables mutadas en puntos particulares del código.

El análisis estático basado en datos aprovecha bases de código extensas para inferir reglas de codificación y mejorar la precisión del análisis. ^{[16] [17]} Por ejemplo, se pueden utilizar todos los paquetes de código abierto de Java disponibles en GitHub para aprender buenas estrategias de análisis. La inferencia de reglas puede utilizar técnicas de aprendizaje automático. ^[18] También es posible aprender de una gran cantidad de correcciones y advertencias pasadas. ^[16]

Los analizadores estáticos generan advertencias. Para ciertos tipos de advertencias, es posible diseñar e implementar técnicas de corrección automáticas . Por ejemplo, Logozzo y Ball han propuesto correcciones automáticas para cccheck de C# . ^[19]

• Ayewah, Nathaniel; Hovemeyer, David; Morgenthaler, J. David; Penix, John; Pugh, William (2008). "Uso del análisis estático para encontrar errores". IEEE Software . 25 (5): 22–29. CiteSeerX  10.1.1.187.8985 . doi :10.1109/MS.2008.130. S2CID  20646690.
• Brian Chess, Jacob West (Fortify Software) (2007). Programación segura con análisis estático . Addison-Wesley. ISBN 978-0-321-42477-8.
• Flemming Nielson; Hanne R. Nielson; Chris Hankin (10 de diciembre de 2004). Principles of Program Analysis (edición de 1999 (corregida en 2004)). Springer. ISBN 978-3-540-65410-0.
• "Interpretación abstracta y análisis estático", Escuela Internacional de Invierno sobre Semántica y Aplicaciones 2003, por David A. Schmidt