Francamente, tratamos de no pasar por su base de código, tratamos de escribir herramientas para hacer eso por nosotros.
Primero, la teoría. La seguridad es un requisito de un sistema de software, por lo que, al igual que otros requisitos (funcionalidad, usabilidad, accesibilidad, rendimiento, etc.), debe considerarse en cada etapa del flujo de trabajo de ingeniería de software, desde la recopilación de requisitos hasta la implementación y el mantenimiento. De hecho, esto es posible, y existe una guía para ayudar a los equipos de proyectos de software a hacer eso. Aunque trabajo principalmente con desarrolladores de iOS, mi descripción favorita del "ciclo de vida de desarrollo seguro" es de Microsoft Press .
En este modelo, la seguridad de la aplicación comienza cuando intentamos obtener los requisitos de nuestros usuarios. Necesitamos descubrir sus preocupaciones de seguridad y privacidad, lo cual no es fácil porque somos los expertos, no los usuarios, y si comprenden sus requisitos de seguridad, es posible que les resulte difícil expresarlos. También necesitamos descubrir a qué riesgos estará expuesto el software en la implementación y a qué nivel de riesgo es aceptable.
Diseñamos nuestra aplicación teniendo en cuenta esos requisitos. Escribimos el código con el objetivo de satisfacer esos requisitos y evitar riesgos adicionales asociados con errores de seguridad a nivel de código. Probamos el software para asegurarnos de que nuestro modelo de seguridad sea coherente con lo que realmente construimos, luego implementamos el software de una manera que coincida con los supuestos que hicimos sobre el entorno cuando diseñamos la cosa. Finalmente, brindamos soporte y mantenimiento que ayudan al usuario a operar el software de una manera consistente con sus requisitos de seguridad, y que les permite (y a nosotros) reaccionar a los nuevos cambios en los riesgos presentados.
Ok, mucho para la teoría. En la práctica , por razones que se explican muy bien (aunque de manera no técnica) en Geekonomics y que se deben principalmente a la forma en que las empresas de software están motivadas, la mayoría de las cosas anteriores no suceden. En cambio, obtenemos esto. Los desarrolladores:
- contrata a un chico o chica de seguridad para que esté presente cuando están haciendo una oferta para un contrato, para demostrar que "obtienen" seguridad.
- escribir software
- contrata a un chico o chica de seguridad para validar el software antes del lanzamiento, solucionando muchos problemas que surgieron en el paso 2.
- parchear todo lo demás después de la implementación.
Entonces, lo que la mayoría de las personas de seguridad de aplicaciones realmente están haciendo es, como usted dice, encontrar errores. Esta es realmente una revisión de código glorificada, pero es una revisión de código altamente enfocada llevada a cabo por personas que son expertos en el tipo de errores que esta revisión está buscando, por lo que todavía hay valor en obtener ayuda externa para hacerlo. Esa es una regla general de las compras, por supuesto: siempre haga que alguien más pruebe que no estuvo involucrado en hacer la cosa.
Si aceptamos lo anterior como cierto, se deduce que las personas que toman decisiones de compra probablemente equiparen a "agente de seguridad capaz" con "encuentra muchos errores". Aquellos que hacen que las computadoras hagan el trabajo por ellos encontrarán más errores que aquellos que no lo hacen, por lo que, por supuesto, dependen en gran medida de las herramientas de análisis estático y tratarán de pasar más tiempo extendiendo las herramientas que codificando problemas específicos para clientes específicos. Luego concluimos que es más probable que las personas de seguridad de aplicaciones escriban herramientas para leer código que leer código.
** Advertencia: lo que queda es opinión personal y especulación **
La realidad está rota. Notará que la teoría de la seguridad del software tenía que ver con identificar y responder al riesgo de depender de un sistema de software, mientras que la práctica consistía en encontrar la mayor cantidad posible de errores. Claro, eso todavía reducirá el riesgo, pero solo como un efecto secundario. El objetivo del juego se ha vuelto menos importante que "ganar" el juego, por lo que las reglas se cambian para que sea más fácil ganar.
¿Qué puede hacer usted como desarrollador de software al respecto? Juega el juego según sus reglas originales. Encuentre a alguien en su equipo (preferiblemente en realidad en su equipo, en lugar de un contratista, de modo que estén motivados para proporcionar resultados a largo plazo en lugar de una victoria rápida) que comprenda la importancia de la seguridad y capacite a los bejeezus. Dele a esa persona la responsabilidad de dirigir al equipo para proporcionar la seguridad de extremo a extremo descrita al comienzo de mi respuesta.
Además, dele a esa persona la autoridad para seguir adelante . Si un diseño no expresa los requisitos de seguridad, debe ser revisado. Si la implementación no cumple con los requisitos de seguridad, no debe liberarse . Su persona de seguridad puede hacer la llamada del juicio, pero se le debe permitir actuar en ese juicio. Me doy cuenta de que esto puede sonar como el tipo de seguridad que dice "la seguridad OMFG es lo más importante", pero eso no es lo que quiero decir. Si su producto tampoco cumple con los requisitos de funcionalidad, usabilidad o rendimiento, tampoco debe liberarlo.
¿Por qué querrías hacer eso? Debería ser más barato: todos hemos visto (y probablemente citado por un representante barato de +10) la tabla de Código Completo donde los defectos se vuelven más caros cuanto más tarde los arregles, ¿verdad? Los defectos de seguridad también son defectos. Siendo las reglas del juego del mundo real, la mayoría de ellas son problemas en los requisitos que se fijan en el mantenimiento. ¿Eso es barato?
Ok, ahora ¿qué puedo yo como una pistola de seguridad para alquilar hacer al respecto? Bueno, resulta que también puedo negarme a jugar según las reglas enmendadas. Puedo decirle a los desarrolladores que se trata de reducir el riesgo, que esto se puede hacer en cada etapa, y luego puedo ayudarlos a hacerlo.