Shift dejó sus pruebas de software críticas para la seguridad con la automatización de pruebas

Estamos en una crisis de costos con software crítico para la seguridad, lo que significa que la mayor funcionalidad requerida ha crecido más allá de la capacidad de pagar por su desarrollo. El Programa Boeing 787, por ejemplo, requirió 6.5 millones de líneas de código, cuyo diseño, desarrollo y prueba costaron 4 millones de dólares. La tendencia en los principales proyectos críticos para la seguridad muestra un crecimiento exponencial en los costos totales, siendo el software una porción más grande del presupuesto total de desarrollo año tras año. El próximo gran programa aeroespacial probablemente será inasequible utilizando las mismas técnicas utilizadas en programas anteriores. Entonces, ¿qué podemos hacer?

La certificación de seguridad y la prueba y verificación requeridas es una gran parte del presupuesto de desarrollo de software. Prueba de cambio a la izquierda de software (es decir, antes en el ciclo de vida del desarrollo de software) mientras que el aprovechamiento de la automatización paga grandes dividendos en costos, riesgos y cronograma. La Figura 1 a continuación muestra el costo en millones de dólares por mil líneas de código para el desarrollo de software de aerolíneas comerciales (Datos de Boeing y Airbus), que muestra claramente el aumento exponencial.

Figura 1: Costo de desarrollo de software por líneas de código en proyectos de aviación comercial. Datos tomados de métricas de proyectos de Airbus y Boeing.

Dónde se crean y se encuentran los errores y el impacto en el costo

Como era de esperar, la mayoría de los defectos se introducen en un proyecto al principio, incluso antes de que se escriba la primera línea de código. La mayoría de los errores se encuentran y se corrigen durante las pruebas, pero un buen porcentaje (¡hasta un 20%!) Se descubre durante la operación, después de que el producto se ha vendido y enviado. En los sistemas certificados, esto significa un ciclo de reparación-prueba-recertificación extremadamente costoso o soluciones para el operador para el problema. La Figura 2 muestra el porcentaje relativo de errores introducidos y detectados en cada fase del ciclo de vida del desarrollo de software.

Figura 2: Gráfico que muestra el porcentaje de defectos introducidos y detectados durante las diferentes fases de desarrollo.

Los defectos son más baratos de corregir al principio del ciclo de vida y se vuelven exponencialmente más costosos de encontrar y corregir a lo largo del proyecto. En funcionamiento, después de que un producto se ha enviado a las manos del cliente, es el más caro de reparar. Los costos de reparación de defectos posteriores a la implementación son conservadores y no incluyen daños a su marca ni responsabilidad por incidentes de seguridad en el campo. La Figura 3 muestra el costo relativo de reparar un defecto en cada etapa del ciclo de vida. Claramente, el objetivo es mover los defectos detectados y reparados antes en el ciclo de vida, en otras palabras, para "cambiar a la izquierda". Además, es deseable reducir la cantidad de defectos que llegan al cliente (una realidad en todos los dominios).

Figura 3: Costo relativo para encontrar y corregir errores durante cada fase de desarrollo. Durante los requisitos y el diseño es la línea de base (1x) y el lugar menos costoso para reparar defectos. Fuente de las Figuras 2 y 3: Presentación de SAVI a la Conferencia INCOSE SE 2012.

El papel de la automatización de pruebas en Shift-Left

La industria del software crítico para la seguridad reconoce la necesidad de cambiar la forma en que se hacen las cosas. Demasiados proyectos están reinventando la rueda, y certificar software nuevo requiere mucho tiempo y es costoso. El crecimiento de la conectividad y la funcionalidad de los nuevos productos significa que los métodos deben cambiar. En esta publicación, no cubriremos todas las técnicas que se proponen, sino que nos concentraremos en el papel que desempeña la automatización de pruebas en el cambio a la izquierda en la reducción, detección y corrección de defectos y vulnerabilidades de seguridad.

Una gran parte de cualquier proyecto crítico para la seguridad son las pruebas, y la automatización es absolutamente necesaria para lograr los objetivos de seguridad, protección y calidad. A continuación, se muestra un ejemplo de las formas en que las herramientas de automatización de pruebas respaldan nuevos métodos de desarrollo de software y aumentan la productividad de las pruebas y la documentación:

Apoyar métodos de desarrollo ágiles e iterativos: Se comprenden los problemas con el método en cascada y muchos equipos están utilizando métodos de desarrollo más modernos para mejorar la calidad y la seguridad. La automatización de pruebas es una parte importante de cualquier método de desarrollo iterativo, ya que los conjuntos de pruebas se ejecutan en cada nueva iteración de un módulo, componente, etc. La automatización de pruebas admite estos métodos con pruebas automatizadas repetibles, proporcionando informes en varios niveles para cada prueba, pero también acumulativos. resultados a lo largo del tiempo. Las herramientas de análisis dinámico son fundamentales para detectar errores en tiempo de ejecución que son difíciles de detectar, y el análisis estático juega un papel importante en la detección de defectos antes de que comiencen las pruebas.

Inspecciones de software de apoyo: Una de las mejores prácticas para eliminar defectos al principio del ciclo de vida del desarrollo son las inspecciones. Las inspecciones significan revisar todo, no solo el código fuente. Por ejemplo, inspeccionar los requisitos y el diseño es fundamental para prevenir la principal fuente de errores en el sistema (consulte la Figura 2). Muchos errores están literalmente diseñados en el sistema. Las herramientas juegan un papel menor en esta etapa, pero mejoran la efectividad de las revisiones de código. Las pruebas unitarias automatizadas, la detección dinámica de errores y el análisis estático proporcionan una detección de errores muy mejorada en las primeras etapas de codificación de un proyecto. Los resultados de las pruebas automatizadas se pueden presentar en revisiones de código, lo que reduce la dependencia de la detección manual de errores y permite más tiempo para detectar requisitos incorrectos y decisiones de diseño. 

Aumento de la productividad de las pruebas: Las pruebas manuales son tediosas y menos repetibles. La recopilación de resultados puede ser ad hoc y se pueden perder errores a pesar de los resultados "correctos". Lograr la cobertura de código requerida, que varía según el estándar de seguridad y la criticidad del proyecto, es difícil de rastrear. La automatización de pruebas no solo hace que las pruebas sean mucho menos tediosas y repetibles, sino que las capacidades de generación de informes de las herramientas de prueba avanzadas crean información de gestión importante sobre el estado del proyecto. Agregar análisis dinámico, que analiza el código cuando se está ejecutando (para detectar errores complicados en tiempo de ejecución) y análisis estático, que analiza el código antes de que se ejecute, aumenta en gran medida la capacidad de detección de errores de las herramientas de prueba.

Automatización del cumplimiento del estándar de codificación: Muchos proyectos críticos para la seguridad requieren estándares de código fuente. MISRA, por ejemplo, es común en el software automotriz, pero ha ganado aceptación en otras industrias. Algunos estándares requieren que el código cumpla con un estándar de la empresa que cumpla con ciertos objetivos. En cada caso, la aplicación manual del cumplimiento de la codificación es tediosa y propensa a errores. Las herramientas de análisis estático son ideales para hacer cumplir el cumplimiento y las herramientas avanzadas van más allá al detectar errores que van más allá de las violaciones de formato.

Automatización de la documentación de certificación: Una gran parte de la carga de trabajo para lograr certificaciones de seguridad de software se encuentra en los procesos de documentación, validación y verificación. La automatización de pruebas reduce significativamente el costo de documentar los resultados de las pruebas y el análisis de cobertura. 

Aceleración de la reutilización de software de terceros: Una estrategia clave para aumentar la productividad es reutilizar el software. Idealmente, los componentes ya certificados se pueden utilizar para reducir los costos de desarrollo de estas subunidades. Los proyectos deben hacer uso de software COTS (comercial disponible en el mercado) y posiblemente código fuente abierto y otro código fuente. Automatizar la evaluación de este software con herramientas de análisis estáticas y dinámicas disminuye el riesgo de utilizar estos componentes.

Mejora de la calidad, la seguridad y la protección: Incluso los regímenes de prueba estrictos pueden pasar por alto errores críticos. La cobertura del código por sí sola no es suficiente para garantizar un comportamiento adecuado en el caso de ataques de seguridad o código multiproceso, por ejemplo. Las herramientas de análisis estático pueden detectar errores en el código fuente sin ejecutar una prueba específica y pueden encontrar errores como vulnerabilidades de seguridad que son difíciles de descubrir en las pruebas unitarias o del sistema. Las herramientas de análisis dinámico pueden detectar errores en la ejecución del código durante las pruebas que podrían reflejarse en los resultados de las pruebas (por ejemplo, una pérdida de memoria lenta). Las pruebas de penetración y fuzzing durante las pruebas del sistema pueden encontrar errores que no se hayan detectado durante las condiciones normales de funcionamiento. En general, los defectos adicionales y las vulnerabilidades de seguridad que se encuentran en las herramientas de última generación ayudan a reducir el costo, el riesgo y muchos de los errores del 20% aproximadamente que entran en producción.

¿Qué efecto tiene el desplazamiento a la izquierda?

Está claro que se debe hacer algo para resolver los problemas que se muestran tan claramente en la Figura 2. Se están introduciendo demasiados defectos, que no se detectan, al comienzo del ciclo de vida, y se dejan demasiados en el producto cuando se fabrica y en manos de los clientes (o en aviones o automóviles según sea el caso). La adopción de nuevos métodos de desarrollo, la reutilización de componentes, el aprovechamiento de COTS y el código abierto y la automatización de herramientas son todos pasos clave para mejorar la productividad del desarrollo.

Suponiendo un proceso de desarrollo que utiliza herramientas de última generación, donde se detectan y corrigen más defectos en una etapa más temprana del ciclo de vida, las pruebas unitarias son extremadamente efectivas, lo que ayuda a que menos errores lleguen a producción. En la Figura 4, un ejemplo hipotético muestra el cambio en la detección de defectos durante el ciclo de vida, donde la mayor parte de la detección y reparación de defectos se desplaza hacia la izquierda, al principio del ciclo de vida.

Figura 4: Un gráfico que muestra un proceso de desarrollo mejorado que desplaza la detección de errores y vulnerabilidades de seguridad más temprano en el ciclo de vida.

Sabemos por la Figura 3 anterior que los costos aumentan significativamente en cada fase de desarrollo. La Figura 5 a continuación muestra la comparación de los costos para corregir defectos en el método tradicional versus el método nuevo y mejorado que se muestra en la Figura 4. Encontrar y corregir errores antes, como era de esperar, cuesta menos que arreglarlos más tarde. En la situación que se presenta aquí, la diferencia de costo total es de alrededor del 40% a favor del enfoque de desplazamiento a la izquierda.

Figura 5: Un gráfico que muestra el costo relativo para corregir errores en el enfoque tradicional versus el enfoque de cambio a la izquierda. Incluso con la misma cantidad de defectos totales, la detección temprana reduce los costos de manera significativa.

La importancia de las cadenas de herramientas certificadas y la asistencia para la calificación

El uso de herramientas automatizadas en proyectos críticos para la seguridad requería confianza en las herramientas mismas. El fabricante del producto tiene la responsabilidad de tener la confianza de que los procesos y herramientas utilizados para crear el software cumplen con los requisitos del estándar. Los proveedores de herramientas pueden ayudar con esto haciendo que las herramientas estén certificadas por organismos de estándares de seguridad antes de venderlas a los fabricantes o, en los casos en que no sea posible dicha certificación previa, brindar asistencia para la calificación. Luego, pueden utilizar la evidencia de certificación del proveedor de la herramienta en su propio envío para la certificación y reducir el esfuerzo necesario. (Por ejemplo, Parasoft C / C ++test ha sido certificado por TÜV SÜD para estar calificado para el desarrollo de software relacionado con la seguridad de acuerdo con las normas IEC 61508 e ISO 26262).

En algunos estándares de seguridad de software, como DO-178B y DO-178C, la certificación se realiza a nivel de sistema y las herramientas y el software individuales no se certifican de forma independiente. En estos casos, el proveedor de herramientas proporciona kits de calificación y asistencia en términos de documentación y servicios profesionales, lo que reduce en gran medida el costo y el esfuerzo necesarios para calificar las herramientas para su uso en el proyecto.

Conclusión

El software crítico para la seguridad ciertamente se encuentra en una crisis de costos. Los proyectos nuevos y de gran envergadura críticos para la seguridad se están volviendo demasiado costosos de desarrollar, hasta el punto de que pueden no ser rentables. Se necesitan nuevos métodos para desarrollar software crítico para la seguridad, y ese esfuerzo debe reducir la cantidad de errores que se encuentran al final del ciclo de vida del desarrollo del software. Cambiar la detección y reparación de defectos y vulnerabilidades de seguridad lo más temprano posible en el ciclo de vida reduce los costos de manera significativa. La automatización de pruebas juega un papel en la mejora de la eficiencia y los resultados de las pruebas y es una parte importante de un nuevo enfoque para el desarrollo de software crítico para la seguridad.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.

por Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.