mundo real, ¿cuántos aquí se someten a revisiones de código de seguridad en profundidad? Los que sí lo hacen, ¿con qué frecuencia, una vez por trimestre, una vez por versión, una vez por luna azul? Los que no, ¿por qué no? (No se refiere a programadores pequeños o aficionados, no es que los trivialice, es solo que no espero que lo hagan ;-)).¿Qué tan populares son las revisiones del código de seguridad?
Como consultor de seguridad, generalmente soy el que realiza las revisiones de seguridad, sin embargo, esto solo suele ser para organizaciones muy sensibles a la seguridad (por ejemplo, grandes bancos, proveedores de software, militares, etc.) o como un resultado de requisitos reglamentarios (por ejemplo, PCI-DSS).
Ahora, pocos grupos (excepto los de las compañías más grandes como Microsoft, Intel, RSA, etc.) realmente disfrutan de la revisión, aunque realmente debería ser una experiencia positiva. Me parece que esto se debe principalmente a la alta inversión percibida, de recursos, tiempo y, por supuesto, efectivo para atraer a los consultores.
Bien, por lo que no solo se percibe, es bastante real: se acepta comúnmente que un único revisor puede cubrir entre 50-100 LoC por hora. Aunque hemos logrado multiplicar eso, dado que solo estamos buscando problemas de seguridad específicos (y los clientes están presionando mucho para reducir los costos) y podemos minimizar el alcance de acuerdo con el riesgo, podemos maximizar un máximo de alrededor de 1000 LoC por hora. Para cualquier sistema de tamaño medio a grande, esto todavía representa cientos de costosas horas de consultoría, nada triviales.
La alternativa más común es la de los escáneres automáticos de código fuente, ala Fortify, onzas, etc. Sin embargo, además de los costos de licencia, esto está lejos de ser eficiente; normalmente encontramos que estas herramientas producen resultados en 100 mil, con un muy alta (70-90%) tasa de falsos positivos (y duplicados). Así que todavía está gastando grandes cantidades de tiempo revisando los resultados, Y estas herramientas no cubren un conjunto sustancial de vulnerabilidades potenciales (por ejemplo, fallas lógicas, lógica de negocios, etc.)
Dicho esto, (y una gran EXENCIÓN DE RESPONSABILIDAD debería ir aquí :) He estado trabajando en los últimos meses con uno de los vendedores de herramientas para desarrollar un servicio que haría esto de manera muy eficiente, por ejemplo: ser capaz de cubrir 500K LoC en solo una semana de trabajo y, sin embargo, proporcionar resultados reales, precisos y completos, prácticamente cero falsos positivos y casi ningún error falso perdido.
Aquellos de ustedes que deberían estar haciendo SCR, pero no lo hacen, ¿esto sería suficiente para convencerlos de lo contrario? o hay algo más que te detenga? ¿O simplemente no es un problema para ti?
Para aclarar, no estoy tratando de promover mi o mi servicio, tratando de conseguir un poco de perspectiva del mundo real más allá de mi propia agenda de seguridad de evangelización. Me gustaría ver los problemas como otros programadores los ven ...
Más aclaración, NO estoy preguntando CÓMO realizar revisiones de código, qué opciones hay, etc. Tengo mucha experiencia en este campo, y es esta experiencia que vendo a mis clientes. Mi pregunta es si las revisiones de códigos son tan impopulares como parecen, POR QUÉ esta actividad específica no es tan popular como debería ser, y CÓMO podemos cambiar esto. (Irrelevantes de elección de la metodología, herramientas, etc.)
Además, como Corneliu y otros señalaron, las revisiones de código de seguridad no debe tomarse solo como la única protección y verificación de la seguridad de un sistema, más bien debe ser un elemento de un marco completo y holístico de SDLC (ciclo de vida de desarrollo seguro). Sin embargo, tampoco debe ser olvidado. Así que mi pregunta se centra realmente en ese elemento, ya sea en el contexto del SDLC completo o solo como un paso adelante de penetrar y parchar.
BTW, felicidades por ser usuario # 100,000! –