Lista de verificación de desarrollo de software seguro [cerrado]

Esto es como una recomendación de un producto, por lo que puede terminar cerrado. También debe tener cuidado de distinguir entre una lista de verificación y un estándar.

Si está buscando algunas listas de comprobación de alto nivel para usar en su proceso de desarrollo, puede consultar SANS SWAT , que cubre consideraciones más lógicas en lugar de problemas específicos de nivel de código. También le puede interesar la serie ISO 27000 (es decir, ISO / IEC 27034 ) (no solo 27001 o 27002 ). Otras metodologías incluyen STRIDE (no recomendaría) y DREAD de Microsoft

No está claro si esto es para un lenguaje de programación específico, pero el NASA JPL tiene pautas para C y JAVA que puede ser útil considerar como parte de los estándares de seguridad. Oracle tiene sus propias pautas de seguridad de JAVA . Las pautas de CERT que ya se encuentran en respuesta de Jaques también están en el mismo ámbito.

Deberá aclarar sus objetivos y aprovechar estas herramientas para crear:

1. Normas de codificación seguras (el código se formateará de esta manera)
2. Estándares específicos de la biblioteca / plataforma (los tokens CSRF utilizarán esta función común)
3. Prácticas de desarrollo seguro / SDLC (el código se someterá a estos escáneres, herramientas o procesos antes de comprometerse; prueba de la pluma antes de pasar a producción)
4. Pruebas y revisiones en curso (re-certificaciones de aplicaciones que ocurren regularmente; procedimientos de divulgación responsables)

Una lista de verificación podría ser una buena manera de comenzar, ya que está bien definida, pero los procesos incorrectos pueden ser igual de dañinos, por ejemplo, si promocionas la rama incorrecta con el código del buggy).

Es imposible obtener un código seguro definiendo un conjunto de reglas que cumplir. El estándar CERT al que Jacques se vincula es un buen ejemplo de esto. Hace una lista de "cosas malas que hacer", y al mirar a través de ella no encontré nada con lo que estuviera particularmente en desacuerdo. Pero la lista es tan larga y muchos de los elementos son tan esotéricos y generalizados que son relativamente inútiles, excepto como material de referencia como un diccionario.

Probablemente no haya una buena metodología que simplemente le dará seguridad. La seguridad llega a través de desarrolladores que conocen la seguridad y trabajan en una organización donde se valora la seguridad. Si su organización no entiende la seguridad, no obtendrá ninguna.

Probablemente, lo mejor que puedes hacer es fomentar el desarrollo seguro mediante el ejemplo y las revisiones de código. Necesita personas con conocimientos para leer el código antes de que entre en su producto y proporcione una crítica constructiva. Anime a sus desarrolladores a que, al menos, comprendan el top 10 de Owasp. Algunos van a ser mejores que otros.

La seguridad se trata de cultura, no de ciclos de vida o reglas siguientes. No puede definir la seguridad, ya que siempre es un objetivo móvil y diferente para cada situación.

Eche un vistazo a SDLC de Microsoft. Recomiendan usar herramientas de análisis de código estático para capturar cosas simples, como matrices fuera de límites, etc., y usar pruebas dinámicas de fuzz para ayudar a encontrar las cosas más difíciles. Pero también confían en que sus programadores aporten un alto nivel de competencia a su tarea.

Si está buscando más consejos y orientación de texto simple, consulte "Codificación segura en C y C ++" por Robert C. Seacord. El tercio medio del libro está dedicado a una lista detallada de problemas y soluciones, y parece ser la "lista de verificación" de los elementos que le interesan.

El equipo CERT del instituto de ingeniería de software de la universidad Carnegie mellon tiene un estándar de codificación seguro para C, C ++, Java, Perl:

enlace

Te dice exactamente lo que los programadores deben hacer o no, como mencionaste. Por ejemplo:

  

No aplique el operador sizeof a un puntero cuando tome el tamaño de   una matriz

Para cada regla, proporciona ejemplos de códigos buenos y malos, y una explicación de los riesgos.

Gunnar Peterson hizo un prezo (disponible a través de YouTube) que elaboró a través de su publicación en el blog en Proceso no resultados . Disfruté este enfoque y los comentarios también.

Los Controles proactivos OWASP y Tabla Periódica de Vulnerabilidades de OWASP son métodos de lista de verificación que funcionan muy bien en la construcción de la seguridad. Jim Manico hizo una gran presentación en los Controles Proactivos de OWASP, disponibles a < : //www.youtube.com/watch? v = Cg5dN8Pyn_c "> esta ubicación de YouTube .

Aquí hay algunas asignaciones de las categorías de lista de verificación SANS SWAT para Principios de AppSec, OWASP Conucopia y los proyectos de controles proactivos.