El poder de 10: reglas para desarrollar código crítico para la seguridad

El poder de 10 reglas fueron creadas en 2006 por Gerard J. Holzmann del Laboratorio de Software Fiable de la NASA/JPL.[1]​ Las reglas pretenden eliminar ciertas prácticas de codificación en C que dificultan la revisión o el análisis estático del código. Estas reglas son un complemento a las directrices MISRA C y se han incorporado en el mayor conjunto de estándares de codificación de JPL.[2]​

Reglas

Las diez reglas son:[1]​

  1. Restrinja todo el código a construcciones de flujo de control muy simples. No utilice sentencias GOTO, construcciones setjmp o longjmp, ni recursividad directa o indirecta.
  2. Todos los bucles deben tener un límite superior fijo. Debe ser trivialmente posible para una herramienta de comprobación demostrar estáticamente que no se puede superar un límite superior preestablecido en el número de iteraciones de un bucle. Si el límite del bucle no puede demostrarse estáticamente, se considera que se ha infringido la norma.
  3. No utilice la asignación dinámica de memoria después de la inicialización.
  4. Ninguna función debe ser más larga de lo que se puede imprimir en una sola hoja de papel (en un formato de referencia estándar con una línea por declaración y una línea por declaración). Normalmente, esto significa no más de unas 60 líneas de código por función.
  5. La densidad de aserciones del código debe promediar un mínimo de dos aserciones en tiempo de ejecución por función. Las aserciones siempre deben estar libres de efectos secundarios y deben definirse como pruebas booleanas.
  6. Los objetos de datos deben declararse en el nivel de alcance más pequeño posible.
  7. Cada función de llamada debe comprobar los valores de retorno de función no vacíos, y la validez de los parámetros debe comprobarse dentro de cada función.
  8. El uso del preprocesador debe limitarse a la inclusión de ficheros de cabecera y definiciones de macros simples. No se permite el pegado de tokens, las listas de argumentos variables (elipses) ni las llamadas recursivas a macros.
  9. El uso de punteros debe estar restringido. Específicamente, no se permite más de un nivel de desreferencia. Las operaciones de desreferencia de punteros no pueden ocultarse en definiciones de macros o dentro de declaraciones typedef. No se permiten punteros a funciones.
  10. Todo el código debe ser compilado, desde el primer día de desarrollo, con todas las advertencias del compilador habilitadas en la configuración más pedante del compilador. Todo el código debe compilarse con esta configuración sin ninguna advertencia. Todo el código debe ser comprobado diariamente con al menos un analizador estático de código fuente de última generación, pero preferiblemente más de uno, y debe pasar los análisis con cero advertencias.

Véase también

Enlaces externos

Referencias

  1. ↑ a b The Power of 10: Rules for Developing Safety-Critical Code
  2. ↑ JPL C Coding Standard - JPL Laboratory for Reliable Software