Si su modelo de seguridad se basa en el concepto de una auditoría externa puntual de todo el código base, entonces está cometiendo un error de seguridad.
... Y probablemente estés usando mal la auditoría también. Pero llegaremos a eso.
Más allá de la pregunta, todo el código debe ser auditado por seguridad. En muchos casos, esto es en realidad un requisito legal: ningún código se envía sin una auditoría, punto. La sabiduría tradicional sugiere que tal auditoría sea un evento en algún momento del ciclo de vida, pero una forma más sensata de hacerlo es auditar el código a medida que avanza. Es decir, todo el código obtiene una auditoría de seguridad antes que se puede registrar en su base de código.
La teoría es simple; El repositorio ya está auditado, por lo que no necesitamos volver a auditar sus componentes como un procedimiento estándar. Pero cuando se propone una nueva característica, un parche o una corrección de errores, la diferencia tiene que ser firmada por los mantenedores apropiados. Puede obtener la aprobación de cualquier cosa que sea importante para usted. Por ejemplo, el kernel de Linux tiene un proceso de aprobación bastante complejo que requiere varios endosos en el camino de la calidad, simplicidad, consistencia, rendimiento, etc. Sus requisitos pueden variar, pero una auditoría de seguridad debe ser parte de ese proceso de aprobación.
En este caso, no está auditando el producto de extremo a extremo, solo está auditando el diferencial. Pero miles de pequeñas auditorías a lo largo del ciclo de desarrollo del producto serán mucho más exhaustivas y exhaustivas de lo que cualquier auditoría de extremo a extremo podría esperar.
Una auditoría completa de producto es ciertamente útil y no debe evitarse. Esta auditoría debe centrarse en el producto en su totalidad de una manera que no sea tan fácil de realizar durante las auditorías a nivel de parche que ha estado realizando. Desea mirar todo el bosque de vez en cuando, no solo los árboles individuales. El calendario de estas auditorías a gran escala probablemente debería corresponder a lanzamientos importantes, cambios importantes o auditorías de certificación de cumplimiento.
Pero si se mantiene actualizado en la auditoría a nivel de parche, puede asegurarse de que el código siempre se mantenga en un estado verificable, de modo que pueda continuar enviándolo con confianza.
Acerca de las aprobaciones de tiempo de compromiso
Si su compañía no está haciendo esto, entonces está haciendo todo mal. Hay docenas, quizás cientos, de problemas que se resuelven al requerir que cada cambio de código sea aprobado por al menos otra persona, incluso (especialmente) durante el desarrollo inicial. Siempre debe tener al menos dos personas que entiendan cómo funciona cada línea de código y que acepten que el código es correcto.
Esto es al menos tan importante como las pruebas unitarias. Si no está haciendo esto, deténgalo todo y vuelva a visitar las políticas sobre calidad y seguridad.
Sí, este proceso hace escala. Como se señaló anteriormente, el proyecto de software más grande del mundo lo usa, al igual que algunas de las compañías de software más ágiles y exitosas del mundo.