¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
Saltar a la sección
Blog de Parasoft
Implementar y mantener el estándar de codificación correcto para sus proyectos de desarrollo es clave para brindar soluciones de software seguras. En esta publicación, nuestro experto analiza por qué debe asegurarse de mantener el estándar de codificación correcto y cómo puede hacerlo.
Saltar a la sección
El software ha migrado del escritorio a prácticamente todo lo que tocamos. Desde termostatos inteligentes hasta bombas de infusión y coches, el software es omnipresente y está en crecimiento. Las llamadas "cosas" del Internet de las cosas (IdC) cada vez tienen más lógica. Con ello, un mayor riesgo de fallo. Muchos de estos dispositivos se utilizan en áreas críticas para la seguridad, como la medicina y la automoción, donde pueden causar daños físicos.
La mayoría de las empresas que desarrollan dispositivos consideran, con razón, el desarrollo de software actual como un caos casi descontrolado. Pero hay esperanza. El software PUEDE y DEBE tratarse como una práctica de ingeniería. Los estándares de codificación, que forman parte integral de las buenas prácticas de ingeniería de software, nos permiten pasar del ciclo de "construir, fallar, corregir" a un ciclo de "diseñar, construir, entregar" con alta calidad, seguridad y protección.
Resulta que estos mismos estándares también brindan beneficios en las áreas de ciberseguridad, cumpliendo una doble función. Esta publicación analiza:
El impacto del software en el mundo real a menudo se descarta. Uno de mis temas principales que discuto continuamente como evangelista en Parasoft, es que el desarrollo de software realmente debería ser ingeniería.
Con frecuencia llamamos a los desarrolladores de software por el título de ingenieros de software, pero ese no es necesariamente el término adecuado para la forma en que trabajan hoy. Evolucionar hacia una buena práctica de ingeniería de software da como resultado que los costos bajen y la calidad aumente. Una parte clave de esto es la adopción de estándares, en particular, estándares de codificación.
La era de los vehículos definidos por software, el IoT médico e industrial y los dispositivos permanentemente conectados está aquí. El software se está infiltrando en productos, dispositivos y otros lugares en los que nunca pensamos. Ahora debemos pensar mucho en el software de estos productos y sus ramificaciones.
Una de las cosas interesantes que trato de explicar es que construir un buen software es diferente a construir algo como un automóvil. Si estoy tratando de construir un automóvil de alta calidad, debo gastar más en materiales y más tiempo para construirlo. Resulta que en software, no se gasta más para crear software de alta calidad. Gasta más para crear software de baja calidad.
Debemos entender que en el software, la mayoría de los defectos provienen del programador, quien los coloca en el producto. Si podemos dejar de introducir defectos a medida que desarrollamos el software, podemos tener un software mucho mejor, a un precio más bajo.
Esta cita es de una charla de 1972, llamada "El humilde programador", escrito por Edsger W. Dijkstra. Sigue siendo muy relevante hoy en día.
Es importante darse cuenta de cómo la calidad afecta los costos de desarrollo de software. Alcaparras jonesEl investigador lleva décadas siguiendo este tema y realiza una encuesta anual sobre los costos del software. Las cifras no varían mucho de un año a otro. Los datos muestran que el costo típico del software, desde los requisitos hasta la codificación y el mantenimiento, aumenta con cada fase. Sin embargo, la forma en que los equipos abordan la calidad determina si su proceso es correcto o patológico.
Software Quality 2011: una encuesta sobre el estado del arte en software – Capers Jones
Tiene sentido que si encontramos un defecto justo cuando se escribe el código, el costo es relativamente bajo, por ejemplo, unos minutos del tiempo de un desarrollador. Si es posible eliminar el 85% de los defectos en la fase de desarrollo, hay un gran impacto en el costo. Considere el ahora famoso gráfico de Capers Jones que muestra el costo promedio de corregir defectos en cada etapa de desarrollo:
Fuentes: medición de software aplicado, Capers Jones, 1996, Building Security into The Software Life Cycle, Marco M. Morana, 2006
La reparación de defectos posteriores al lanzamiento cuesta alrededor de $ 16,000 (posiblemente mucho más) según la investigación de compañías reales que fabrican software real, no un modelo teórico. Si observamos los esfuerzos de calidad y seguridad del último ciclo, como las pruebas de penetración, los problemas de seguridad que se encuentran aquí se encuentran en el extremo costoso del ciclo. Probablemente sea 15 veces más costoso que encontrar vulnerabilidades a través de pruebas versus auditorías de seguridad tempranas.
Un enfoque obsoleto y demostrablemente falso es mejorar la calidad del software probándolo al final de su ciclo de vida, justo antes de su lanzamiento. En el mundo de la fabricación, entienden que esto es imposible, pero por alguna razón, creemos que podemos probar la calidad y la seguridad del software.
Las razones por las que digo que el desarrollo de software casi nunca es ingeniería son estas características comunes del desarrollo de software actual:
El objetivo de los estándares de codificación de software es inculcar prácticas de programación comprobadas que conduzcan a un código seguro, confiable, comprobable y mantenible. Por lo general, esto significa evitar prácticas de codificación no seguras conocidas o código que pueda causar un comportamiento impredecible. Esto se vuelve crítico en lenguajes de programación como C y C++ donde el potencial para escribir código inseguro o inseguro es alto.
Sin embargo, creo que la industria ha perdido el rumbo con estos estándares de programación. En la última década, las herramientas (como las herramientas de análisis estático) han pasado de detectar código potencialmente problemático que es inseguro o una debilidad conocida del lenguaje a centrarse en buscar defectos como una forma de prueba temprana, también conocida como desplazamiento a la izquierda.
Aunque buscar defectos es importante, crear software de sonido es una actividad más productiva. Lo que deberíamos estar haciendo es construir y hacer cumplir los estándares para evitar la situación en la que se introducen defectos en primer lugar, desplazándose aún más hacia la izquierda.
Para respaldar esto, considere la investigacion realizado por el Instituto de Ingeniería de Software (SEI) donde encontraron, como era de esperar, que la seguridad y la confiabilidad van de la mano y que la seguridad del software se puede predecir por el número y los tipos de defectos de calidad encontrados. Además, los defectos críticos suelen ser errores de codificación que se pueden prevenir mediante inspecciones y herramientas como el análisis estático.
Esta publicación no entra en detalles sobre cada uno de estos estándares de codificación, pero hay una cantidad considerable de trabajo en los siguientes estándares de la industria. Aunque su aplicación puede ser específica para un tipo específico, estas normas se están adoptando en muchas industrias. Estos son algunos ejemplos de estándares de codificación establecidos para la seguridad y la protección.
Consideremos MIRA C, que mencioné no es solo para aplicaciones de automóviles. Sin embargo, es un estándar que ha estado en uso desde 1998 y está bien definido. Se actualiza cada par de años que lo revisan. A medida que evolucionan los lenguajes C y C++, evolucionan los estándares a su alrededor. Es un estándar muy flexible que tiene en cuenta diferentes niveles de gravedad y existe una estrategia documentada para manejar y documentar las desviaciones.
Como la tecnología que puede detectar violaciones de las pautas estándar de codificación, como el análisis estático, las versiones recientes de Misra Tenga en cuenta qué pautas son decidibles (detectables con alta precisión por herramientas) y cuáles no. Esto nos lleva al tema de la adopción y la aplicación, y a la importancia de las herramientas de análisis estático en los estándares de codificación.
Las investigaciones muestran que la eliminación inadecuada de defectos es la principal causa de la mala calidad del software. Los programadores son aproximadamente un 35% eficientes en encontrar defectos en su propio software. Más adelante en el ciclo de desarrollo, la mayoría de los defectos que podemos aspirar a eliminar después de todas las revisiones de diseño, revisiones por pares, pruebas unitarias y pruebas funcionales es de alrededor del 75 %.
El análisis estático, cuando se usa correctamente en un modo preventivo, puede aumentar la eliminación de defectos hasta aproximadamente un 85%. Sin embargo, el enfoque del uso del análisis estático para la mayoría de las organizaciones hoy en día es la detección y la solución rápida.
Son posibles más beneficios cuando se utilizan herramientas de análisis estático para prevenir prácticas de programación deficientes conocidas y características del lenguaje en primer lugar. Aquí es donde los estándares de codificación entran en juego como pautas y subconjuntos de lenguajes de programación que evitan que los defectos comunes como desbordamientos de búfer o falta de inicialización se escriban en el código.
Considere un ejemplo en el que, durante una prueba, se detecta un error de desbordamiento de búfer bastante complejo, quizás con una herramienta de seguridad dinámica de aplicaciones (DAST). Esto es un golpe de suerte, ya que la prueba simplemente ejecutó la ruta de código que contiene el error. Una vez detectado y depurado, es necesario volver a probarlo, y así sucesivamente. Análisis estático mediante análisis de flujo Es posible que también haya encontrado este error, pero depende de la complejidad de la aplicación.
La detección de errores en tiempo de ejecución es precisa, pero solo verifica las líneas de código que ejecuta. Por lo tanto, es tan bueno como la cobertura de su código de prueba. Considere si un estándar de codificación había prohibido el código que habilitó este error en primer lugar.
Los estándares de codificación como MISRA C no describen cómo detectar la memoria no inicializada, por ejemplo, sino que guían a los programadores para escribir código que no conduzca a tal error en primer lugar. Creo que esto es mucho más un enfoque de ingeniería: programa de acuerdo con estándares bien conocidos y aceptados. Tomemos, por ejemplo, la ingeniería civil y la construcción de puentes.
No tomaríamos el enfoque de construir un puente y luego probarlo conduciendo camiones cada vez más grandes sobre él hasta que colapsara, midiendo el peso del último camión exitoso y construyéndolo de nuevo para soportar ese nuevo peso. Este enfoque sería una tontería aún, no es diferente a la forma en que abordamos el desarrollo de software.
Una vez que un equipo de software adopta un estándar de codificación y el análisis estático se aplica correctamente, puede detectar errores con anticipación y prevenirlos. En otras palabras, en lugar de encontrar un defecto temprano, lo cual es bueno, el equipo está cambiando la forma en que escriben el código, ¡lo cual es mejor!
Considere el gráfico heartbleed vulnerabilidad. Ahora hay detectores para esta instancia específica de vulnerabilidad, pero hay una forma de escribir código para que Heartbleed nunca haya sucedido en primer lugar. La prevención es un método mejor y más seguro.
Contar con una metodología de prevención sólida resulta más económico que solucionar estos problemas.
"Quienes deseen un software realmente fiable descubrirán que, en primer lugar, deben encontrar la manera de evitar la mayoría de los errores."
—Dykstra
Los estándares de codificación incorporan principios de ingeniería sólidos para la programación en sus respectivos lenguajes y forman la base de cualquier enfoque preventivo. El costo de un buen software es menor que el costo de un software malo. Si no está utilizando el análisis estático en la actualidad, o solo lo está utilizando para la detección temprana, eche un vistazo a las herramientas de análisis estático de Parasoft para C y C ++, Java y C # y VB.NET con una rica biblioteca de verificadores para todos los estándares de seguridad integrados.
