Realización de una revisión manual del código de seguridad: ¿de qué se debe tener cuidado?

Al darse cuenta de que incluso tiene una pregunta de este tipo, ya le pone por delante del juego.
También añadiría:

  

(C) No es muy bueno para revisar el código, por lo que solo obtendrás "fruta de bajo rendimiento"
  (D) Realmente es un pentestro, que cree que " oh, muy fácil " se ramifica en el código, por lo que obtendrás resultados similares a un pentest, solo se remonta al código real.
  (E) Es un desarrollador, sin mucha comprensión de la seguridad, pero conoce un código incorrecto.
  etc ...

El punto del asunto es que parece que no está siendo muy transparente contigo, por lo que realmente no importa qué opción sea. Incluso (A) My code has no problems no vale mucho, a menos que pueda respaldarlo con una prueba de los problemas que su código no tiene (sic).
Y no, ejecutar una herramienta automatizada no cuenta no como una revisión del código de seguridad, como aparentemente sintió, correctamente.

Entonces, a tus preguntas:

1. What should you ask him to do "Revisión del código de seguridad". Él debería decirle a usted lo que hará y / o recomendar qué más necesita (esto podría / debería ser una lista bastante larga). Por supuesto, usted puede / debería darle más información, por ejemplo, qué hace su aplicación, quién tiene acceso, qué tan sensible es la información, etc. Sin embargo, incluso si no lo hace, debe solicitar esta información. Sin él, simplemente no es una revisión de código de nivel profesional.

2. How do I cross-check his work - Yo diría que, en general, hay 3 posibilidades:

• Aprende lo suficiente sobre el tema para comprender lo que dice estar haciendo y para hacer las preguntas difíciles, o busca a alguien que lo haga (siempre es cierto cuando se trata con un proveedor de un servicio que no entiendes muy bien ...)
• Haga que otro consultor realice una revisión competitiva, incluso si solo está en un subconjunto de la aplicación.
• (Y este es el bueno) Realice una prueba de penetración de caja negra externa. Esta es la mejor manera de validar la revisión del código. Por supuesto, pídale a alguien más que haga el pentest y compare los resultados. Tenga en cuenta que no todas las vulnerabilidades encontradas en pentest son relevantes para una revisión de código, y viceversa, pero debería darle alguna indicación.

Llego a esto desde la posición de ser el tipo que realiza la revisión del código de seguridad (aunque no hice la tuya ;-) Entonces, lo que desea averiguar es si el código podría implementarse con bajo riesgo y, de no ser así, cuáles son los riesgos. Por lo tanto, debe preguntarle a su consultor que, en lugar de preguntar "¿puede encontrar algunas vulnerabilidades en mi código?". La respuesta a la pregunta relacionada con el riesgo debe incluir:

• lo que ha intentado para identificar los riesgos
• qué ataques ha considerado (asumo que una aplicación PHP estará basada en la web, en cuyo caso la lista de los 10 principales de OWASP es apropiada como iniciador)
• por qué consideró esos ataques (en otras palabras, qué modelo de amenaza utilizó)
• qué riesgo residual queda

Debe considerar tanto la amplitud como la profundidad de la revisión. Por amplitud, me refiero a qué rango de riesgos / ataques / amenazas se cubrirán en la revisión. Debe comenzar con el Estándar de verificación de seguridad de aplicaciones de OWASP para tener una idea de lo que se debe cubrir aquí. Por profundidad, me refiero a qué tan bien el consultor verificará que cada área ha sido defendida adecuadamente. En el extremo inferior, una herramienta de exploración automatizada ofrece poca garantía. En el extremo superior, una inspección manual o un caso de prueba real debe demostrar esencialmente que las defensas correctas están en su lugar, se han diseñado correctamente y se utilizan en todos los lugares en que deben estar.