Una onza de prevención: seguridad y protección a través de estándares de codificación de software

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.

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 estas mismas normas también aportan beneficios en el área de la ciberseguridad, cumpliendo una doble función.

Desde el desarrollo de software hasta la ingeniería de software

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.

Los llamamos ingenieros de software, pero el título va más allá de la práctica. La programación se convierte en ingeniería cuando el trabajo se rige por un estándar —un estándar de codificación— que se aplica durante la escritura del código y se verifica mediante controles. Eso es lo que reduce los costos y aumenta la calidad.

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.

El costo de la mala calidad

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 proviene de una charla de 1972 titulada " El programador humilde ", escrita por Edsger W. Dijkstra. Sigue siendo muy relevante hoy en día.

Es importante comprender cómo la calidad influye en los costos del desarrollo de software. Capers Jones , investigador, lleva décadas estudiando 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 saludable o deficiente.

Por qué necesitamos reparar los defectos de manera temprana

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:

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:

• Lo que hacen la mayoría de los desarrolladores no es repetible. Es decir, si le doy la misma tarea a dos personas diferentes, los resultados no serán los mismos.
• Falta de buenas prácticas bien ejercidas. Los desarrolladores de software consideran los estándares de codificación como una palabra sin sentido. Se conciben como un conjunto de reglas que el líder del equipo insiste en seguir, en lugar de comprender que el estándar de codificación es la encarnación del conocimiento, la práctica y la experiencia. Un ingeniero eléctrico sabe que los estándares son la clave para crear un producto seguro desde el principio. Un desarrollador de software piensa que los estándares son una limitación que los frena… un...falsos positivos."
• La formación de los desarrolladores es desconocida e incoherente. La educación en desarrollo de software no está estandarizada como lo está con las disciplinas de ingeniería. Los estándares y las prácticas establecidas a menudo no forman parte del plan de estudios, sino que el énfasis está en los lenguajes de programación.

Los estándares de codificación mejoran la seguridad y la protección

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 esta afirmación, consideremos la investigación realizada por el Software Engineering Institute (SEI), donde descubrieron, como era de esperar, que la seguridad y la fiabilidad van de la mano y que la seguridad del software puede predecirse a partir del número y el tipo de defectos de calidad encontrados. Además, los defectos críticos suelen ser errores de codificación que pueden prevenirse mediante inspecciones y herramientas como el análisis estático.

Estándares de la industria

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.

• MISRA C/C++. Desarrollado por el Consorcio MISRA, describe un subconjunto del lenguaje C o C++ y las directrices para su uso con el fin de mejorar la seguridad de la aplicación. Aunque originalmente se diseñó para aplicaciones automotrices, se utiliza en todos los sectores, especialmente en aplicaciones críticas para la seguridad. "MISRA", "MISRA C" y el logotipo triangular son marcas registradas de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Reservados todos los derechos.
• SEI / SANS CERT. El Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI) cuenta con un conjunto de directrices para ayudar a los desarrolladores a crear software más seguro y confiable. Estas directrices, clasificadas por orden de importancia en grupos de "reglas" y "recomendaciones", son exhaustivas y amplias, e incluyen metadatos de riesgo.
• OWASP Top 10. El proyecto de seguridad de aplicaciones web abiertas (OWASP), como su nombre indica, es una organización comprometida con la mejora de la seguridad de las aplicaciones web. Por ello, su proyecto OWASP Top 10 proporciona una lista de las vulnerabilidades de seguridad de aplicaciones web más comunes y de mayor impacto. La última versión de OWASP Top 10 está directamente correlacionada con identificadores CWE específicos e incluye metadatos de riesgo.
• Estándar de codificación C ++ de vehículos aéreos de combate de ataque conjunto (JSF AV). Un estándar basado en un subconjunto de MISRA C específicamente para el programa JSF.
• CWE - Top 25 de enumeración de debilidades comunes. CWE es una lista de debilidades de software descubiertas basada en el análisis de vulnerabilidades reportadas (CVE). El Top 25 enumera las debilidades de seguridad más comunes y peligrosas seleccionadas de la lista más grande de CWE, que son todos exploits que tienen una alta probabilidad de ocurrir y el impacto de explotar la debilidad es grande. CWE también incluye información sobre riesgos en forma de impacto técnico, lo que ayuda a comprender qué problemas son más importantes para su organización.

Consideremos MISRA C , que, como mencioné, no se limita a aplicaciones automotrices. Sin embargo, es un estándar vigente desde 1998 y está bien definido. Se actualiza cada dos años. A medida que evolucionan los lenguajes C y C++, también evolucionan los estándares relacionados. Es un estándar muy flexible que contempla diferentes niveles de gravedad y cuenta con una estrategia documentada para gestionar y registrar las desviaciones.

Como tecnología capaz de detectar infracciones de las directrices de los estándares de codificación, como el análisis estático, las versiones recientes de MISRA tienen en cuenta qué directrices son determinables (detectables con alta precisión mediante 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.

Papel del análisis estático

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.

Una onza de prevención

Consideremos un ejemplo en el que, durante las pruebas, se detecta un error de desbordamiento de búfer bastante complejo, quizás con una herramienta de seguridad de aplicaciones dinámicas (DAST). Esto es una casualidad afortunada, ya que las pruebas ejecutaron precisamente la ruta de código que contiene el error. Una vez detectado y depurado, es necesario volver a probarlo, y así sucesivamente. El análisis estático mediante análisis de flujo también podría haber detectado 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 se ejecutan. Por lo tanto, su eficacia depende de la cobertura del código de prueba. Considere qué sucedería si un estándar de codificación hubiera prohibido el código que originó este error.

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 adoptaríamos el enfoque de construir un puente y luego probarlo haciendo pasar camiones cada vez más grandes hasta que se derrumbe, midiendo el peso del último camión que lo soporta y reconstruyéndolo para que aguante ese nuevo peso. Este enfoque sería absurdo, aunque no difiere mucho de nuestra metodología para el desarrollo de software.

Construyalo bien la primera vez

Una vez que un equipo adopta un estándar de codificación y aplica el análisis estático correctamente, el estándar deja de ser una red por la que se arrastra el código y comienza a darle forma a medida que se escribe.

Detectar un defecto a tiempo es bueno. No escribirlo en absoluto es mejor. Eso es lo que significa el enfoque de "desplazamiento a la izquierda", llevado al extremo: no se trata de detectar los problemas antes, sino de trasladar el estándar al momento en que se escribe el código, de modo que el problema nunca llegue a manifestarse.

Aquí es donde la pregunta del agente de codificación se responde por sí sola. Cada vez se genera más código en lugar de escribirlo a mano. La reacción instintiva es preguntarse si los estándares siguen vigentes.

Aplican más.

Lo que importa no es quién o qué escribe el código, sino que el código cumpla con el estándar.

Si se realiza una comprobación en el momento de la creación del código, este cumple con el estándar. Si se realiza una comprobación posterior en lote, se obtiene una lista de aspectos que corregir.

Un desarrollador que utiliza un linter que cumple con los estándares y se activa mientras escribe está en el lado correcto de esa línea. Lo mismo ocurre con un agente de codificación que incorpora análisis estático en su bucle, rechazando y regenerando el código antes de que un humano vea el resultado.

Eso recorta lo que llega a la verificación. No elimina la verificación. Si se coloca el estándar delante del generador, el código sigue devolviendo infracciones. Menos que con una solicitud simple, pero no cero.

Así que se hacen ambas cosas. Primero, se guía la generación hacia el estándar y luego se verifica el resultado. Se confía, pero se verifica. A la verificación no le importa si la línea la escribió una persona o un modelo. El análisis estático lee el código, no a los autores.

Consideremos la vulnerabilidad Heartbleed . Actualmente existen detectores para esta vulnerabilidad específica, pero hay una forma de escribir código que evite que Heartbleed ocurra. La prevención es un método mejor y más seguro.

Resumen

Una metodología de prevención sólida cuesta menos que corregir los errores que evita.

"Quienes deseen un software realmente fiable descubrirán que, en primer lugar, deben encontrar la manera de evitar la mayoría de los errores."

—Dijkstra

Los estándares de codificación son principios de ingeniería sólidos y aplicables: la materialización del conocimiento, la práctica y la experiencia. El conocimiento reside en el estándar, no en la mente de un solo autor. Eso es lo que lo convierte en ingeniería y no solo en codificación. El trabajo se rige por un estándar, que se aplica a medida que se escribe el código y se verifica al finalizar, de modo que el resultado es sólido desde su concepción, en lugar de ser corregido mediante depuración.

El objetivo nunca fue mejorar en la detección de errores, sino dejar de escribirlos.
No arregles el código. Escribe mejor código.

Ya sea que ese código provenga de un desarrollador o de un generador, el estándar y la verificación no cambian.

El coste de un buen software es menor que el de uno malo. Si actualmente no utiliza el análisis estático, o solo lo usa para la detección temprana, eche un vistazo a las herramientas de análisis estático de Parasoft para C, C++ , Java , C# y VB.NET, que incluyen una amplia biblioteca de comprobadores para todos los estándares de seguridad más populares.