stringtranslate.com

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 .

Razón fundamental

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]

Tipos de herramientas

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.

Métodos formales

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]

Análisis estático basado en datos

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]

Remediación

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]

Véase también

Referencias

  1. ^ Wichmann, BA; Canning, AA; Clutterbuck, DL; Winsbarrow, LA; Ward, NJ; Marsh, DWR (marzo de 1995). "Perspectiva industrial sobre el análisis estático" (PDF) . Revista de ingeniería de software . 10 (2): 69–75. doi :10.1049/sej.1995.0010. Archivado desde el original (PDF) el 27 de septiembre de 2011.
  2. ^ Egele, Manuel; Scholte, Theodoor; Kirda, Engin; Kruegel, Christopher (5 de marzo de 2008). "Una encuesta sobre técnicas y herramientas de análisis dinámico automatizado de malware". Encuestas de informática de ACM . 44 (2): 6:1–6:42. doi :10.1145/2089125.2089126. ISSN  0360-0300. S2CID  1863333.
  3. ^ Khatiwada, Saket; Tushev, Miroslav; Mahmoud, Anas (1 de enero de 2018). "Semántica suficiente: un enfoque teórico de la información para la localización de errores de software basada en IR". Tecnología de la información y el software . 93 : 45–57. doi :10.1016/j.infsof.2017.08.012.
  4. ^ "Objetivos de calidad de software para código fuente" Archivado el 4 de junio de 2015 en Wayback Machine (PDF). Actas: Conferencia sobre sistemas y software integrados en tiempo real de 2010 , ERTS2010.org, Toulouse, Francia: Patrick Briand, Martin Brochet, Thierry Cambois, Emmanuel Coutenceau, Olivier Guetta, Daniel Mainberte, Frederic Mondot, Patrick Munier, Loic Noury, Philippe Spozio, Frederic Retailleau.
  5. ^ Mejorar la seguridad del software con análisis estáticos y de tiempo de ejecución precisos Archivado el 5 de junio de 2011 en Wayback Machine (PDF), Benjamin Livshits, sección 7.3 "Técnicas estáticas para la seguridad". Tesis doctoral de Stanford, 2006.
  6. ^ FDA (8 de septiembre de 2010). "Investigación sobre seguridad del software de bombas de infusión en la FDA". Administración de Alimentos y Medicamentos. Archivado desde el original el 1 de septiembre de 2010. Consultado el 9 de septiembre de 2010 .
  7. ^ Sistemas de seguridad basados ​​en computadora: guía técnica para evaluar aspectos de software de sistemas de protección basados ​​en computadora digital, "Sistemas de seguridad basados ​​en computadora" (PDF) . Archivado desde el original (PDF) el 4 de enero de 2013. Consultado el 15 de mayo de 2013 .
  8. ^ Documento de posición CAST-9. Consideraciones para evaluar los enfoques de ingeniería de seguridad para la garantía de software Archivado el 6 de octubre de 2013 en Wayback Machine // FAA, Certification Authorities Software Team (CAST), enero de 2002: "Verificación. El solicitante/desarrollador debe especificar una combinación de análisis estáticos y dinámicos y aplicarla al software".
  9. ^ VDC Research (1 de febrero de 2012). "Prevención automatizada de defectos para la calidad del software integrado". VDC Research. Archivado desde el original el 11 de abril de 2012. Consultado el 10 de abril de 2012 .
  10. ^ Prause, Christian R., René Reiners y Silviya Dencheva. "Estudio empírico del soporte de herramientas en proyectos de investigación altamente distribuidos". Ingeniería de software global (ICGSE), 2010 5.ª Conferencia internacional IEEE sobre. IEEE, 2010 https://ieeexplore.ieee.org/Xplore/login.jsp?url=%2Fielx5%2F5581168%2F5581493%2F05581551.pdf&authDecision=-203
  11. ^ M. Howard y S. Lipner. El ciclo de vida del desarrollo de seguridad: SDL: un proceso para desarrollar software demostrablemente más seguro. Microsoft Press, 2006. ISBN 978-0735622142 
  12. ^ Achim D. Brucker y Uwe Sodan. Implementación de pruebas de seguridad de aplicaciones estáticas a gran escala Archivado el 21 de octubre de 2014 en Wayback Machine . En GI Sicherheit 2014. Lecture Notes in Informatics, 228, páginas 91-101, GI, 2014.
  13. ^ "Libro blanco de OMG | CISQ - Consorcio para la calidad de la información y el software" (PDF) . Archivado (PDF) desde el original el 28 de diciembre de 2013 . Consultado el 18 de octubre de 2013 .
  14. ^ Vijay D'Silva; et al. (2008). "Un estudio de técnicas automatizadas para la verificación formal de software" (PDF) . Transactions On CAD. Archivado (PDF) desde el original el 2016-03-04 . Consultado el 2015-05-11 .
  15. ^ Jones, Paul (9 de febrero de 2010). "Un enfoque de verificación basado en métodos formales para el análisis de software de dispositivos médicos". Diseño de sistemas integrados. Archivado desde el original el 10 de julio de 2011. Consultado el 9 de septiembre de 2010 .
  16. ^ ab "Aprendiendo de los errores de otros: análisis de código basado en datos". www.slideshare.net . 13 de abril de 2015.
  17. ^ Söderberg, Emma; Church, Luke; Höst, Martin (21 de junio de 2021). "Mejoras de usabilidad basadas en datos abiertos del análisis de código estático y sus desafíos". Evaluación y valoración en ingeniería de software . EASE '21. Nueva York, NY, EE. UU.: Association for Computing Machinery. págs. 272–277. doi :10.1145/3463274.3463808. ISBN 978-1-4503-9053-8.
  18. ^ Oh, Hakjoo; Yang, Hongseok; Yi, Kwangkeun (2015). "Aprendizaje de una estrategia para adaptar un análisis de programa mediante optimización bayesiana". Actas de la Conferencia internacional ACM SIGPLAN de 2015 sobre programación orientada a objetos, sistemas, lenguajes y aplicaciones - OOPSLA 2015. págs. 572–588. doi :10.1145/2814270.2814309. ISBN 9781450336895. Número de identificación del sujeto  13940725.
  19. ^ Logozzo, Francesco; Ball, Thomas (15 de noviembre de 2012). "Reparación automática de programas modular y verificada". Avisos SIGPLAN de la ACM . 47 (10): 133–146. doi :10.1145/2398857.2384626. ISSN  0362-1340.

Lectura adicional