Para la criptografía, se considera una buena práctica liberar el código para que otros puedan auditarlo ... ¿esto también es cierto para el software de prueba de penetración?
Para la criptografía, se considera una buena práctica liberar el código para que otros puedan auditarlo ... ¿esto también es cierto para el software de prueba de penetración?
La Ley de Linus (cuanto más personas tengan acceso al código fuente, más gente encontrará e informará de errores) solo se aplica cuando las personas tienen un incentivo para corregir los errores. Este incentivo usualmente solo existe cuando usan el software. Por lo tanto, cuando su software esté altamente optimizado para usted y no espere que se forme una comunidad más grande a su alrededor, no obtendrá muchos informes de errores y parches.
Además, incluso cuando su software se usa ampliamente, esto no es una garantía de que las personas lo auditarán correctamente. Un buen ejemplo es el error del corazón , que era una vulnerabilidad de seguridad bastante típica en una pieza muy abierta muy muy muy utilizada software fuente.
Cuando se trata de un software de prueba de lápiz, también hay un componente ético a considerar. ¿Es su software realmente solo útil para la prueba de penetración, o se puede abusar de él para hacer grietas? Es posible que no desee entregar a los chiquillos de guión las herramientas para causar daños y enfrentar problemas legales.
Depende del software que sea, me imagino que tendrá mucho más control para el AV / firewall de código abierto o cualquier cosa que escuche en un socket con una cuenta privilegiada. Sin embargo, algo como una aplicación CLI para generar shellcode probablemente solo recibirá respuestas de tipo QA.
Lea otras preguntas en las etiquetas penetration-test software opensource