Una auditoría de código solo debe considerarse una auditoría puntual, y no debe considerarse una garantía futura. Es posible que algún producto haya sido auditado o revisado por un tercero y puede hacer que ese informe esté disponible, pero nuevas técnicas o diferentes métodos, líneas de tiempo y presupuestos podrían dar lugar a errores adicionales que se encontrarán más adelante. Al final, es posible que no hayan encontrado nada.
Por razones legales, es poco probable que encuentre a alguien que ofrezca una garantía, una garantía o de otra manera en una revisión del código. Más útil sería una revisión del proceso de desarrollo de pruebas, controles, procedimientos y revisiones en curso.
Lo que puede encontrar es documentación de vulnerabilidades existentes y parches que puede aplicar, revisiones, discusiones, etc. Si puede verificar la suma de comprobación / hash de un JAR obtenido con el proporcionado por el desarrollador, esto puede proporcionarle un poco de confianza Si se trata de un proyecto de código abierto popular, es probable que las personas se quejen o publiquen parches si se encuentra una debilidad o vulnerabilidad. También puede obtener cierta seguridad de un JAR firmado. ¿Firmarías algo en lo que pusiste una puerta trasera como desarrollador original?
Además, muy pocas licencias de código abierto ofrecen alguna garantía y es posible que ni siquiera garanticen su idoneidad. Debe asumir un riesgo calculado sobre el autor del código, el servicio que proporciona la fuente o el ejecutable y los requisitos de la aplicación. También debe tener cierta seguridad razonable en los cortafuegos, AV, etc. de su propio entorno para bloquear o identificar amenazas.
Por último, es probable que la mayoría de las revisiones se activen desde la personalización del código abierto, no desde el paquete base.