Cumplimiento de software DO-178C para la industria aeroespacial y de defensa

El análisis de código estático es el análisis del código sin ejecución real del mismo. Análisis estático Expone vulnerabilidades de seguridad y protección en el código mediante la aplicación de un conjunto integral de técnicas de análisis de código que incluyen:

• Análisis basado en patrones
• Análisis del flujo de datos
• Análisis de flujo de control
• Interpretación abstracta
• Métricas de código y más

Estos métodos identifican desbordamientos de búfer de memoria, divisiones por cero, uso de bibliotecas inseguras, reglas de codificación de organización, violaciones de directivas, etc.

En D0-178C, los objetivos del análisis estático se enmarcan en la Sección 6 relacionada con los procesos de verificación de software. Los objetivos del análisis estático se centran en garantizar que el código de software esté libre de ciertos tipos de defectos y siga buenas prácticas de codificación.

Por ejemplo, la Sección 6.3.4 Revisión y análisis del código fuente ofrece una descripción general de las actividades de verificación de software necesarias para revisar el código en términos de cumplimiento, verificabilidad y trazabilidad. Sin embargo, esta sección también especifica la necesidad de inspeccionar el código para verificar su conformidad con los estándares, precisión y consistencia, todas las cuales son buenas aplicaciones para el análisis estático.

Si bien D0-178C no tiene un requisito específico para el análisis estático, las pautas y los objetivos relacionados con el análisis estático se distribuyen en las secciones del Capítulo 6. Es fundamental interpretar y aplicar estas pautas de manera adecuada en el contexto del proyecto para garantizar el cumplimiento de D0-178C para la certificación de software aerotransportado.

Requisitos en DO-178C

Algunos requisitos típicos para el análisis estático en D0-178C pueden incluir los siguientes.

La mayoría de estas actividades de verificación se respaldan mediante la automatización del análisis estático mediante herramientas avanzadas y modernas como Parasoft C/C++test. Además, Parasoft proporciona métricas de código sobre mantenibilidad, claridad, capacidad de prueba, portabilidad, solidez, reutilización, complejidad y soporte para revisiones de código por pares en equipo. También se proporciona análisis dinámico, pruebas unitarias y otras funciones de detección de errores en tiempo de ejecución.

Detección temprana de defectos

La detección temprana de defectos con herramientas de análisis estático puede mejorar significativamente el cumplimiento de la norma D0-178C al abordar posibles problemas de codificación y vulnerabilidades en el proceso de desarrollo de software. El análisis estático analiza el código fuente sin ejecutarlo, identificando defectos y posibles problemas según reglas predefinidas.

Las herramientas de análisis estático pueden detectar errores de codificación y fallos en el código fuente en las primeras fases del proceso de desarrollo. Al identificar y corregir estos errores en una fase temprana, el equipo de desarrollo puede evitar que estos defectos se propaguen a etapas posteriores del desarrollo, donde podrían ser más difíciles y costosos de corregir.

El software crítico para la seguridad que se utiliza en los sistemas aerotransportados debe estar protegido contra posibles vulnerabilidades de seguridad. Las herramientas de análisis estático pueden identificar posibles debilidades de seguridad en el código, como desbordamientos de búfer, problemas de validación de entrada y otros defectos relacionados con la seguridad. Abordar estas vulnerabilidades en las primeras etapas del proceso de desarrollo mejora la seguridad del software.

La norma D0-178C exige actividades de verificación exhaustivas durante todo el ciclo de vida del desarrollo de software (Capítulo 6). El análisis estático, al ser una forma de verificación estática, permite la verificación temprana del código fuente. Al encontrar y abordar los defectos en una etapa temprana, el software puede avanzar a través de las etapas de verificación posteriores con mayor confianza, ahorrando tiempo y esfuerzo a largo plazo.

Al adoptar el análisis estático en las primeras etapas del proceso de desarrollo de software, junto con otros métodos de verificación y validación, los equipos pueden abordar de manera proactiva los defectos y las vulnerabilidades de seguridad. Esto conduce a un proceso de certificación más ágil y a una mayor probabilidad de producir software confiable y seguro para su uso en sistemas aéreos.

Algunos de los tipos comunes de defectos que el análisis estático de Parasoft C++test puede detectar incluyen:

Estos son solo algunos ejemplos de los tipos de defectos que el análisis estático de Parasoft C++test puede detectar. Además, las herramientas de análisis estático como Parasoft C++test se pueden personalizar para incluir o excluir ciertos tipos de comprobaciones según los requisitos específicos del proyecto y los estándares de codificación.

Estándares de Codificación

En cuanto a las normas de codificación, la norma D0-178C no prescribe un conjunto específico de normas de codificación que se deban seguir, sino que proporciona directrices y objetivos para establecer y cumplir normas de codificación adecuadas para el desarrollo de software a bordo crítico para la seguridad.

Las secciones relevantes de D0-178C que se refieren a los estándares de codificación se encuentran principalmente en el Capítulo 6 Proceso de verificación de software y el Capítulo 11 Datos del ciclo de vida del software. Esto es lo que D0-178C normalmente requiere con respecto a los estándares de codificación.

D0-178C reconoce que diferentes proyectos pueden tener diferentes estándares de codificación (por ejemplo, MISRA C/C++, CERT C/C++, CWE, OWASP, DISA ASD STIG, etc.) dependiendo de factores como la complejidad del software, la criticidad del sistema y el entorno de desarrollo.

Por lo tanto, los estándares y reglas de codificación específicos son determinados por el equipo de desarrollo, siempre que cumplan con las pautas descritas anteriormente.

Una parte fundamental de la evidencia de certificación requerida para el cumplimiento de la norma D0-178C es la documentación recopilada durante estas revisiones y el proceso de verificación. Es importante que el estándar de codificación respalde los procesos de inspección y documentación requeridos.

MISRA C: 2023

MIRA C es un conjunto de pautas de codificación para el lenguaje de programación C, versiones C89/C90, C99, C11 y C18. El objetivo de la norma es aumentar la seguridad del software al evitar de forma preventiva que los programadores cometan errores de codificación que pueden provocar fallos en tiempo de ejecución (y posibles problemas de seguridad) al evitar construcciones problemáticas conocidas en el lenguaje C.

MISRA C puede ayudar a satisfacer los requisitos de D0-178C, que es el estándar de software utilizado para la certificación de sistemas aerotransportados. A continuación, se muestra cómo MISRA C puede cumplir con los requisitos.

1. Cumple todas las casillas de los requisitos del estándar de codificación enumerados en la sección anterior.
2. Proporciona un estándar de codificación bien definido y ampliamente reconocido que puede ser adoptado por el equipo de desarrollo para crear código consistente y confiable.
3. Implica revisiones periódicas del código para garantizar el cumplimiento de la norma.

La adopción de MISRA C ayuda a minimizar la posibilidad de errores y ambigüedades en la codificación, lo que mejora la seguridad y la fiabilidad del software. El enfoque del estándar de codificación en la solidez y la corrección del código se alinea bien con los objetivos de D0-178C para garantizar el desarrollo de software de alta integridad para sistemas aerotransportados.

Es importante tener en cuenta que MISRA C no es una garantía de cumplimiento de la certificación por sí mismo. Es una de las herramientas y procesos que contribuyen a las actividades generales de desarrollo y verificación de software requeridas para la certificación D0-178C. Además, cada proyecto puede tener requisitos y limitaciones específicos, por lo que es posible que el estándar MISRA C deba adaptarse o complementarse con reglas y prácticas de codificación específicas del proyecto.

A lo largo de los años, muchos desarrolladores de sistemas integrados se quejaron (y siguen quejándose) de que MISRA C era un estándar demasiado estricto y de que el coste de escribir 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 un fallo del software
• Costo de una falla del sistema para la empresa
• Herramientas de desarrollo y plataforma de destino
• Nivel de experiencia del desarrollador

Los programadores deben encontrar un punto 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 que no agregan valor.

Prueba de cumplimiento de MISRA

Un problema clave al que se enfrentan los desarrolladores de software crítico para la seguridad es cómo demostrar y probar el cumplimiento al final del proyecto. Existe una tendencia a agregar más información de la necesaria a los informes. Puede convertirse en 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.

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 de calificación de la herramienta. Si la información no es requerida por la norma, evite agregarla. Combinar 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 mejor solución es que la documentación se genere automáticamente, como hace Parasoft.

El documento MISRA Compliance: 2020 también ayuda a las organizaciones a utilizar un lenguaje común que articule los requisitos de cumplimiento al definir los siguientes elementos:

• Resumen de cumplimiento de las directrices
• Plan de cumplimiento de las directrices
• Informe de desviaciones
• Plan de recategorización de directrices

Las siguientes capturas de pantalla de Parasoft muestran informes generados automáticamente con enlaces a otros registros y/o expansión de información en la página.

Certificado SEI/CERT

El Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI) tiene un conjunto de pautas para ayudar a los desarrolladores a crear software más seguro y confiable. La primera, que comenzó en 2006 en una reunión del Comité de Normas C, Norma CERT C Se publicó en 2008 y está en constante desarrollo y evolución.

Hay una versión en formato libro publicada en 2016, pero no incluye las últimas actualizaciones. Este estándar no tiene versiones congeladas específicas como CWE Top 25 y OWASP Top 10. El estándar surgió de una gran comunidad de más de 3,000 personas con un enfoque en la ingeniería y la prevención. Por lo tanto, los estándares de codificación segura de CERT se centran en la prevención de las causas fundamentales de las vulnerabilidades de seguridad en lugar de tratar o gestionar los síntomas mediante la búsqueda de vulnerabilidades.

Las pautas de codificación de CERT están disponibles para C, C++, Java, Perl y Android y se dividen en dos categorías principales.

Las reglas son pautas que pueden detectarse mediante herramientas de análisis estático y que requieren una aplicación estricta, mientras que las recomendaciones son pautas que tienen un impacto menor y, a veces, son difíciles de analizar automáticamente.

El CERT incluye un sistema de evaluación de riesgos que combina la probabilidad de ocurrencia, la gravedad y la dificultad relativa de mitigación. Esto ayuda a los desarrolladores a priorizar qué violaciones de las pautas son las más importantes para investigar. La inclusión del esfuerzo de mitigación en la prioridad de las pautas es una adición importante a los estándares de codificación segura del CERT, de los que carecen muchos otros estándares.

El factor de costo permite la creación del diagrama de diana CERT en el que la diana central son las pautas de mayor gravedad que son más difíciles de solucionar. El beneficio de esta priorización es centrarse en las infracciones más críticas que brindan el mayor beneficio por la inversión en mejoras de seguridad, al tiempo que ayuda al equipo de desarrollo a filtrar las advertencias menos importantes.

Conformidad con SEI CERT C/C++

Según la documentación de SEI CERT C, la conformidad “requiere que el código no contenga ninguna violación de las reglas especificadas en esta norma. Si se alega una condición excepcional, la excepción debe corresponder a una condición excepcional predefinida y la aplicación de esta excepción debe estar documentada en el código fuente”.

Aunque la conformidad es menos específica que las normas como MISRA, los principios siguen siendo similares. Las reglas deben seguirse y las desviaciones solo deben ocurrir en raras ocasiones y deben estar bien documentadas. Las recomendaciones deben usarse cuando sea posible y aquellas que no sean necesarias deben documentarse.

Las infracciones que persistan en el código fuente deben documentarse. Sin embargo, no se acepta ninguna desviación en el rendimiento o la usabilidad y es responsabilidad del desarrollador demostrar que la desviación no generará una vulnerabilidad.

Parasoft C/C++test ofrece un panel de control y reportes completos de cumplimiento de CERT. Los reportes de cumplimiento individuales están disponibles a pedido según la última versión del software o cualquier versión anterior.

Estos informes se pueden ordenar y explorar para investigar las infracciones con más detalle. Hay disponible un plan de pruebas de conformidad para correlacionar la directriz CERT con el verificador de análisis estático de Parasoft correspondiente, que es una herramienta importante si se necesita documentación de conformidad para fines de auditoría. Además, todos los informes interesantes, según lo especificado por el equipo, están en un solo PDF disponible para que los auditores los descarguen.

Compatibilidad con CERT C/C++ en Parasoft C/C++test

Parasoft ofrece un soporte integral para los estándares de codificación segura CERT C y CERT C++ con una cobertura completa de todas las pautas CERT C/C++, incluidas las reglas y recomendaciones que se pueden detectar mediante análisis estático. Los nombres de los comprobadores, los paneles y los informes utilizan la convención de nomenclatura CERT para facilitar la conformidad y la auditoría. Un panel de conformidad CERT, que incluye la puntuación de riesgo CERT, ayuda a los desarrolladores a centrarse en las infracciones más críticas.

CWE

CWE (Common Weakness Enumeration) es una lista de debilidades de software descubiertas en base al análisis de vulnerabilidades reportadas (CVE). La colección de CVE y CWE es una iniciativa financiada por el gobierno de los EE. UU. desarrollada por la comunidad de software y administrada por la organización MITRE. En su totalidad, la lista CWE contiene más de 900 problemas de calidad y seguridad de software y hardware diferentes.

Estos más de 900 elementos están organizados en listas más útiles, como la conocida CWE Top 25. La lista Top 25 enumera las debilidades de seguridad más comunes y peligrosas, que son todas vulnerabilidades que tienen una alta probabilidad de ocurrir y el impacto de explotar la debilidad es grande. Las debilidades de software documentadas por una CWE son el software implicado en un conjunto de vulnerabilidades descubiertas (documentadas como CVE) cuando se realizó un análisis para descubrir la causa raíz. Las CVE son vulnerabilidades específicas observadas en productos de software que tienen una definición exacta de cómo explotarlas.

La versión actual de CWE Top 25 es de 2023 y se muestra en la tabla siguiente. Actualmente se está elaborando una versión actualizada de Top 25 con enlaces mejorados a CVE y NVD. La clasificación tiene en cuenta información del mundo real para que represente verdaderamente los 25 principales problemas de seguridad de las aplicaciones en la actualidad. Tan pronto como se publique, Parasoft tendrá soporte actualizado para la última versión.

Para los equipos de software que tienen un buen conocimiento de las 25 principales vulnerabilidades, existe otra agrupación de las siguientes vulnerabilidades más comunes e impactantes denominada CWE CUSP. Otra forma de pensar en ellas son las 25 principales menciones honoríficas.

El CWE utiliza un método de puntuación de riesgo para clasificar a los 25 mejores y al CUSP. Esta puntuación tiene en cuenta el impacto técnico de una debilidad del software (qué tan peligroso es explotar la debilidad en el mundo real), según lo mide el CWSS (Sistema de puntuación de debilidades comunes).

Algunos ejemplos de impactos técnicos de las vulnerabilidades pueden incluir:

• Denegación de servicio (DoS)
• Denegación de servicio distribuida (DDoS)
• Acceso de lectura o escritura a información protegida
• Acceso no autorizado y más

Los detalles de estos métodos no son demasiado importantes, pero la lista ordenada es útil para comprender qué vulnerabilidades son las que más deben preocuparle. Por ejemplo, es posible que su aplicación sea puramente interna y que los problemas de denegación de servicio no sean críticos para usted. Poder priorizar las debilidades más importantes para su propia aplicación puede ayudar a superar la sobrecarga con las violaciones del análisis estático.

CWE Top 25 y cumplimiento en la cúspide

Introducir el proceso de cumplimiento de estándares de codificación en el flujo de trabajo de desarrollo del equipo no es una tarea fácil. Por ello, es importante seleccionar una herramienta que ayude a lograr el cumplimiento sin imponer demasiada carga de trabajo y sin la necesidad de procedimientos manuales adicionales. Los siguientes puntos son factores importantes para la toma de decisiones al seleccionar la solución para el análisis estático.

El CWE Top 25 y su pariente menos conocido, on the Cusp, no son estándares de codificación en sí, sino una lista de debilidades que se deben evitar para mejorar la seguridad. Para cumplir con el CWE, un proyecto debe poder demostrar que ha realizado esfuerzos razonables para detectar y evitar estas debilidades comunes.

Las herramientas avanzadas de análisis estático de Parasoft para C, C++, Java y .NET son oficialmente compatibles con CWE, lo que permite la detección automática de las 25 principales debilidades y de las debilidades más comunes, entre otras. Los paneles de control centrados en CWE ofrecen a los usuarios un acceso rápido a las infracciones estándar y al estado actual del proyecto. Hay disponible una configuración CWE Top 25 integrada para C, C++, .NET y Java con cobertura total de las 25 debilidades comunes.

Las herramientas de Parasoft incluyen información del Marco común de análisis de riesgos de debilidad (CWRAF), como el impacto técnico, para que pueda beneficiarse del mismo tipo de priorización en función del riesgo, el impacto técnico y las debilidades encontradas en su propio código.

Parasoft también admite informes detallados de cumplimiento para agilizar los procesos de auditoría. Los paneles web proporcionan un enlace a los informes de cumplimiento para obtener una imagen completa de la situación de un proyecto. Además, el plan de detección de debilidades de CWE relaciona la entrada de CWE con los comprobadores que se utilizan para detectar la debilidad. Esto ayuda a ilustrar cómo se logró el cumplimiento para un auditor, y los informes de auditoría están disponibles para descargarse en formato PDF para facilitar la elaboración de informes.