Una guía práctica para hacer que su código base heredado cumpla con MISRA C 2012

La reutilización del código heredado es una realidad, pero la reutilización del código heredado en un proyecto de software crítico para la seguridad y el logro Misra El cumplimiento de C 2012 es una tarea abrumadora.

Los principios originales de MISRA se crearon para aplicarse a medida que se desarrolla el código. Incluso el propio documento tiene una advertencia:

"… Es probable que un proyecto que verifica el cumplimiento de MISRA C al final de su ciclo dedique una cantidad considerable de tiempo a volver a codificar, revisar y probar. Por lo tanto, se espera que el proceso de desarrollo de software requiera la aplicación temprana de los principios de MISRA C."

Debido a que muchas organizaciones necesitan reutilizar sus bases de código heredadas por motivos comerciales, el documento de orientación Cumplimiento de MISRA: 2016 se creó en respuesta a estos desafíos. En él, hay una clara distinción entre el nuevo código nativo que se desarrolla en el ámbito de un proyecto actual y el código "adoptado", que se desarrolló fuera del ámbito del proyecto. En esta publicación, explico un enfoque práctico para lidiar con el código heredado y Misra Cumplimiento de C.

Los tonos de gris de seguir las pautas de MISRA

Aunque parece que debería ser sencillo entender con qué tipo de código está tratando, la situación en muchos casos no es en blanco y negro. Por ejemplo, se produce un prototipo inicial que se desarrolló sin seguir las pautas de MISRA, y luego la gerencia se da cuenta de que el cumplimiento es un requisito para el mercado previsto. Por lo general, la base de código heredada nunca se desarrolló teniendo en cuenta las pautas de codificación. Por lo tanto, una base de código no se puede clasificar automáticamente como "código adoptado" si se requieren actualizaciones en el contexto de un nuevo proyecto. Esto puede volverse complejo.

Con demasiada frecuencia, los escaneos iniciales de una gran base de código a través de una herramienta de análisis estático con todas las reglas de MISRA C 2012 habilitadas, incluida la Enmienda 1, producen decenas de miles de violaciones. Después del impacto inicial, los equipos comienzan a encontrar formas “creativas” de abordar las violaciones. Es importante que los equipos de desarrollo no se desanimen: hay luz al final del túnel.

Con el tiempo, he recopilado e identificado las mejores prácticas y enfoques que los equipos de desarrollo han utilizado para hacer que el código sea compatible sin interferir con la velocidad de desarrollo en curso. En esta publicación, comparto algunos enfoques prácticos y equilibrados para hacer que las bases de código existentes sean compatibles con MISRA.

Utilice el marco de cumplimiento de MISRA: 2016

MISRA C 2012 es un conjunto de pautas de codificación para el lenguaje de programación C. El enfoque del estándar es aumentar la seguridad del software al evitar de manera preventiva que los programadores cometan errores de codificación que pueden provocar fallas en el tiempo de ejecución (y posibles problemas de seguridad) al evitar construcciones de problemas conocidos en el lenguaje C. A lo largo de los años, muchos desarrolladores de sistemas embebidos se quejaron (y todavía lo están) de que MISRA C era un estándar demasiado estricto y de que el costo de escribir un código totalmente compatible era difícil de justificar. Siendo realistas, dado que MISRA C se aplica en software crítico para la seguridad, el valor de aplicar el estándar a un proyecto depende de factores como:

• Riesgo de mal funcionamiento del sistema debido a una falla del software
• Costo de una falla del sistema para la empresa
• Herramientas de desarrollo y plataforma de destino
• Nivel de experiencia del desarrollador

Por lo tanto, los programadores deben encontrar un término medio práctico que satisfaga el espíritu del estándar y aún así reclamar el cumplimiento de MISRA sin desperdiciar esfuerzos en actividades sin valor agregado.

En el documento Cumplimiento de MISRA: 2016 el Consorcio MISRA proporciona la respuesta que necesitaba la comunidad, con un marco razonablemente bien definido de lo que la declaración "Cumple con MISRA" realmente significa. El documento ayuda a la organización a utilizar un lenguaje común que articule los requisitos de cumplimiento definiendo los siguientes artefactos:

• Plan de cumplimiento de las pautas - demuestra cómo se verifica cada directriz MISRA.
• Plan de reclasificación de las pautas - comunica la severidad acordada de las reglas individuales en las pautas como parte de la relación proveedor / cliente.
• Informe de desviaciones - documenta las violaciones de las directrices con la justificación adecuada.
• Resumen de cumplimiento de las pautas - es el registro principal del cumplimiento general del proyecto.

Para centrarse en qué hacer con un código base heredado, el documento clave es el Recategorización de las pautas plan. Este documento captura todas las directivas y reglas e identifica qué categorías se han vuelto a categorizar. Por ejemplo, el siguiente diagrama muestra parte de un plan de reclasificación:

Primero, para el código heredado "adoptado", el MISRA 2016: Cumplimiento El documento sugiere contra las recategorizaciones de una clasificación menos estricta a una más estricta. Además, es posible desaplicar Las reglas de asesoramiento todas juntas después de revisar los tipos de violaciones con el equipo.

El requisito de documentar las desviaciones solo es necesario para todas las reglas obligatorias. Se debe revisar cualquier violación en el código adoptado, y las desviaciones deben indicar claramente que las violaciones no comprometen la seguridad y la protección. Independientemente de la recategorización, si hay un hallazgo que compromete la seguridad o protección del sistema, el problema debe solucionarse. Además, las modificaciones al código heredado pueden introducir otros problemas que el desarrollador no ve claramente.

Comenzar con el fin en mente

Un problema clave que encuentran los desarrolladores de software crítico para la seguridad es cómo demostrar y probar el cumplimiento al final del proyecto. Este puede ser un tema polémico que resulte en una pérdida de tiempo y esfuerzo si los criterios de evaluación se basan en opiniones subjetivas de las distintas partes interesadas. Esta es una situación que el Cumplimiento de MISRA: 2016 El documento ayudó a aclarar.

Un enfoque recomendado para mejorar la evaluación de la preparación para el cumplimiento es utilizar las plantillas existentes tanto para el informe final de cumplimiento como para el informe de calificación de la herramienta. También existe una tendencia a agregar más información a los informes de la necesaria. Si la información no es requerida por el estándar, evite los adornos. Agregar información adicional no solo es una pérdida de tiempo, sino que también presenta el riesgo de retrasar un proceso de auditoría.

La información requerida para incluir en el informe final es proporcionada por Cumplimiento de MISRA 2016:

• Plan de cumplimiento de las pautas
• Resumen de cumplimiento de las pautas
• Detalles de todos los permisos de desviación aprobados
• Los registros de desviación que cubren todas las infracciones de las pautas recategorizadas como Requeridas.

El siguiente ejemplo de la herramienta de Parasoft muestra un formato HTML, con enlaces a las secciones correspondientes:

Establezca el objetivo final temprano

Además de las recomendaciones anteriores, hay algunos otros puntos importantes a considerar:

1. ¿Se ha establecido el GRP (Plan de Recategorización de Directrices) al comienzo del proyecto? Según el estándar MISRA, la negociación con el adquiridor es posible, al igual que la creación de múltiples GRP para el adoptado código que se utiliza sin modificaciones y nativo código que son los archivos modificados activamente durante el proyecto.

2. Para cada cambio incrementado, ¿hay visibilidad de cuántos elementos de trabajo quedan para lograr el cumplimiento total? Esto ayuda a planificar el trabajo en consecuencia y establecer las expectativas correctas con la dirección.

3. ¿Se han revisado las plantillas de informes de GPS (Resumen de cumplimiento de directrices) con el adquiridor al comienzo del proyecto y ¿se consideraron aceptables y completos?

Existen plantillas para estos documentos que los proveedores de herramientas comerciales de análisis estático, incluido Parasoft, proporcionan para ayudar a las organizaciones a cumplir con el marco de cumplimiento de MISRA 2016.

Un enfoque por fases: divide y vencerás

Aunque el escaneo inicial del código existente mediante una herramienta de análisis estático tiende a producir miles de violaciones (particularmente cuando se usa un conjunto de reglas predeterminado), no es práctico detener los nuevos esfuerzos de desarrollo para enfocarse en corregir todas estas violaciones. De hecho, he visto casos en los que se introdujeron regresiones cuando se realizaron cambios significativos en la base de código para corregir las violaciones del análisis estático. Por lo tanto, es importante establecer un flujo de trabajo para corregir las violaciones a lo largo del tiempo, sin interrumpir el proceso de desarrollo ni degradar la calidad del software.

Algunas recomendaciones clave cuando se utilizan herramientas de análisis estático por primera vez en un proyecto se indican a continuación:

• Orientación. Después del escaneo inicial del código, marque todas las violaciones iniciales como "para ser abordadas más tarde" y establezca como base. A partir de ese momento, cuando actualice el código existente y / o desarrolle un nuevo código, mantenga una política de "no se permiten nuevas infracciones". Esta política se puede aplicar mediante el proceso de revisión de código o una herramienta de integración continua (CI) como Jenkins or Bamboo. Cuando los desarrolladores tienen unas pocas horas o días libres, pueden resolver las infracciones restantes marcadas desde la línea de base. Las organizaciones pueden priorizar este enfoque basándose en el código actual en desarrollo, en los hallazgos de la revisión del código o confiando en métricas (por ejemplo, complejidad) para sugerir la próxima infracción a resolver.
• Linea en la arena. El desarrollo establece una fecha, "la línea en la arena". Después de esta fecha, cada unidad de traducción (archivo fuente individual) modificada debe tener todas las infracciones abordadas. Todas las unidades de traducción no modificadas caen automáticamente bajo la verdadera definición del código "adoptado" del documento de Cumplimiento de MISRA.
• Priorización basada en la gravedad. El desarrollador corrige todos los hallazgos obligatorios para el módulo que se les asigna. Con el tiempo, abordan todas las infracciones requeridas según lo permita el tiempo en función de una prioridad seleccionada por el líder del equipo.

Para cualquiera de los enfoques descritos anteriormente, es importante que los líderes técnicos y la administración monitoreen constantemente el progreso y el estado de cumplimiento del proyecto a través de un tablero centralizado. Por ejemplo, el centro de informes de Parasoft proporciona el siguiente panel de estado de cumplimiento preconfigurado:

Calificación de la herramienta

Un componente menos obvio del cumplimiento de MISRA, que a menudo se deja hasta el final del proyecto, es el reconocimiento de que las herramientas de desarrollo utilizadas en el producto deben estar calificadas (probadas adecuadas para el propósito) para el uso previsto. Si una herramienta necesita calificación, ¿qué nivel de validación debe realizarse?

Si bien en muchos casos se requiere la calificación de la herramienta, la Método que se utiliza para realizar la calificación de la herramienta varía según el riesgo asociado con el mal funcionamiento de la herramienta y el nivel de criticidad del software. Parasoft proporciona un kit de calificación y certificaciones para estándares de seguridad específicos y sus requisitos. En ausencia de este kit eficiente, los equipos de software deben considerar los costos de calificación de las herramientas al evaluar las herramientas comerciales, gratuitas y de código abierto.

Algunos estándares como ISO 26262 y DO-178B / C proporcionar orientación razonable sobre los requisitos de calificación de la herramienta. Independientemente del método, el objetivo del proceso de calificación de la herramienta es afirmar que “la herramienta es válida para el uso previsto” y proporcionar una prueba y una justificación de cómo el equipo llegó a esta conclusión.

A continuación, se muestran algunos pasos recomendados a seguir para un proceso de calificación de herramientas:

• Especifique los requisitos de la herramienta para su uso previsto
• Identifique un subconjunto de características del producto que se utilizan. Reducir el proceso de calificación a solo las características utilizadas
• Esquema de un plan de calificación
• Describa el conjunto de pasos de calificación (que pueden incluir pruebas realizadas por el equipo) que verifican que la herramienta cumple con los requisitos.
• Ejecute automáticamente casos de prueba que se pueden automatizar
• Proporcionar un marco para ingresar los resultados de los pasos de prueba manuales
• Plantillas de informes para reducir la cantidad de texto que deben ingresar los desarrolladores.
• Revise el informe con las partes interesadas y ciérrelo.

Pasar por alto la calificación de la herramienta desde el principio podría provocar retrasos en el proyecto al final del ciclo.

Competencia y formación del personal

La experiencia y la capacitación del personal de desarrollo es otro factor clave que las organizaciones de software pasan por alto y que los auditores identifican con frecuencia como el problema número uno al evaluar la preparación de un producto.

De acuerdo con las pautas de MISRA, competencia del personal es una parte importante del cumplimiento de MISRA. Es mejor realizar la capacitación al comienzo del proyecto y tener una fecha de capacitación registrada con todos los desarrolladores firmados que recibieron la capacitación. Al final del proyecto, el equipo de desarrollo debería poder demostrar que:

• El personal que aprobó las desviaciones comprende y ha sido capacitado para reconocer los riesgos asociados con la infracción.
• El personal ha sido capacitado para configurar y utilizar correctamente las herramientas de desarrollo y análisis estático antes de su uso.

En la práctica, la formación de un equipo experimentado es relativamente corta, pero unos pocos días invertidos en el inicio del proyecto ahorran semanas de reelaboración una vez que se ha incumplido la fecha límite del proyecto.

Resumen

No hay una fórmula mágica que haga que el logro Misra el cumplimiento del código heredado es fácil en proyectos críticos para la seguridad. Sin embargo, junto con la introducción del Cumplimiento de MISRA 2016 marco, utilizando el enfoque práctico por fases con un punto final claramente definido en mente, como se describe en esta publicación, los equipos de desarrollo de software pueden lograr el cumplimiento sin interrumpir significativamente su proceso de desarrollo. La conclusión es que todavía hay una buena cantidad de trabajo para lograr el cumplimiento, pero con una planificación inteligente y el enfoque correcto, se puede establecer un conjunto mínimo y equilibrado de tareas para hacer que tanto el código heredado como el recientemente desarrollado sean seguros.

“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.