¿Cuál es la diferencia entre el estándar de codificación segura CERT C y otros estándares de codificación?

CERT C es una guía específica para escribir "software seguro y resistente en C y C ++". La atención se centra en el asesoramiento específico del idioma sobre qué hacer y qué no hacer con un lenguaje muy poderoso que supone que usted sabe lo que está haciendo. Tenga en cuenta que estos lenguajes a menudo se usan para escribir código de bajo nivel para dispositivos de infraestructura o para sistemas integrados, por lo que es vital que estén bien escritos.

PCI-DSS es específico de la industria de pagos y es una combinación de declaraciones de políticas y prácticas que no son específicas del código. Vale la pena leerlo si almacena información de la tarjeta de crédito o para obtener información general sobre buenas prácticas de seguridad, pero no está directamente relacionado con usted de otra manera.

El Top 25 de CWE es una lista de los errores de software más comunes cometidos por personas que escriben software sin importar el idioma o el propósito.

El Top 10 de OWASP es la lista de las vulnerabilidades más comunes en aplicaciones basadas en web, que incluye vulnerabilidades no codificadas.

NIST SAMATE es parte de un marco de garantía de software. Detalla los procesos y las prácticas para garantizar que un producto de software haga solo lo que se pretende y está libre de manipulación.

En resumen, use CERT C para su C y C ++. Y lea e incorpore el Top x según corresponda a sus productos de software. SAMATE es mucho más grande que su tarea actual.

La última vez que comencé en Greenfields (2006) usamos un libro llamado "Los elementos del estilo C #" como nuestra Biblia de normas. Solo lo usamos para resolver disputas donde el equipo no pudo ponerse de acuerdo sobre un enfoque. Aunque no sé si refleja la última versión de C #.

Por las razones descritas anteriormente por @ DodgyG33za, Estándar de codificación CERT C se comunicará más efectivamente con los desarrolladores. Además, el estándar de codificación Java de CERT se divide en dos secciones: Reglas de Java y Pautas de codificación de Java . Hay muchas otras referencias disponibles comercialmente por Gary McGraw, John Viega, Jason Grembi, Mike Howard, etc. Habiendo trabajado en ellas, soy parcial a la Serie de guías de bolsillo DHS Software Assurance .

El Top 10 de OWASP proporciona un inicio, pero el OWASP Developers Guide v2.9 (2005) ofrece más detalles y discusión. "Desafortunadamente, la OWASP Developer Guide nunca despegó con la audiencia prevista: los desarrolladores". Actualmente en revisión, la Guía del desarrollador era más una forma de realizar una prueba de penetración de aplicaciones web, el material ahora se cubre mejor en OWASP Guía de pruebas . La Guía de pruebas salió en 2014 y ofrece la Perspectiva de los interruptores . La OWASP Code Review Guide proporciona material actualizado desde el Perspectiva del Defensor . Por cierto, PCI cita al Top 10 de OWASP como uno de los criterios para el cumplimiento.

La Enumeración de debilidad común es más una herramienta analítica para el "uso de herramientas y servicios de seguridad de software que pueden encontrar estas debilidades en la fuente. "código y sistemas operativos, así como una mejor comprensión y gestión de las debilidades del software relacionadas con la arquitectura y el diseño". Las mitigaciones en el CWE pueden proporcionar información, pero no específicos para la corrección de código. Del mismo modo, el NIST Proyecto SAMATE "se dedica a mejorar la seguridad del software mediante el desarrollo de métodos para permitir las evaluaciones de las herramientas de software, midiendo la efectividad de las herramientas. y técnicas, e identificando lagunas en herramientas y métodos ". Al igual que CWE, SAMATE no proporciona a los desarrolladores pautas de codificación. Más bien, SAMATE es un proyecto de investigación que apoya a los creadores de herramientas y académicos con el Conjunto de datos de referencia de Software Assurance (SARD) y el Exposición de herramientas de análisis estático (SATE). Estas son valiosas contribuciones a Software Assurance pero no son recursos que uno proporcionaría directamente a los desarrolladores.