¿Cómo saber cuándo se completa una prueba de pluma?

Entonces, esta es realmente una pregunta muy interesante para la industria en general. La forma en que te sugiero que lo manejes es

• Tenga algo en su contrato que niegue la responsabilidad por las vulnerabilidades que no se notaron durante la prueba. La razón de esto es que es básicamente imposible asegurarse de que haya encontrado todos los problemas explotables en un sitio web o en cualquier otro sistema. Para escoger un ejemplo, piense en todos los sitios que se sentían vulnerables a shellshock durante años y años, todos deberían ¿Las compañías de pruebas de lápiz que tocaron uno de esos sitios son responsables de no informar a sus clientes?

• Ten una metodología que diga lo que harás. Esto debería cubrir las áreas generales de prueba que se completarán. Para los sitios web, considere basarse en algo como el Top 10 de OWASP como punto de partida. Esto le brinda cierta información en común con el cliente sobre lo que verá.

• Asegúrese de que su empresa cubra los conceptos básicos con una lista de verificación. como dice @rapli, documenta todas las cosas pequeñas, pero no exageres la severidad. Si bien es importante asegurarse de que su prueba no sea solo una lista de verificación, usar una puede evitar errores vergonzosos donde las pruebas básicas se pierden.

El problema con el que podría encontrarse se encontrará con expectativas poco realistas de los clientes. Ese es un caso por caso para abordar. Si obtiene un cliente que espera que su aplicación compleja se revise por completo en aproximadamente 5 días / persona de prueba, debe explicar por qué no es un concepto práctico :)

Especifique en el contrato qué aspectos de seguridad investiga y solo se responsabiliza de ellos. No siempre encontrarás vulnerabilidades. Pero le garantizo que encontrará pocas cosas menores, y le sugiero que incluya todos los pequeños detalles que pueda en el informe, los HSTS faltantes en los encabezados, los cifrados débiles, etc. Así que verán que hizo algo.

Hay algunas herramientas de información que conozco, pero no están disponibles públicamente ni son productos de pago.

Como adición a las otras respuestas:

Cuando su contrato establece su alcance y las vulnerabilidades que debe probar, podría anotar que realmente probó los casos en alcance contra las vulnerabilidades conocidas definidas en el contrato. Algo como:

SQL injection:

SQL-Injections are ...

We identified 42 Input fields in the Webpages in Scope. We identified 0 
Input fields vulnerable to SQL injection (with our used method).

El inconveniente es: en caso de que realmente haya una inyección SQL posible en uno de los campos listados adjuntos al informe; no prometió seguridad al 100%, pero prometió que esto no es una vulnerabilidad, pero seguramente cometió un error, por eso debería indicar de alguna manera qué tipo de pruebas utilizó, qué tipo de inyecciones de SQL son lo último en tecnología. en la introducción a las inyecciones de SQL, por lo que no se le culpará por no encontrar los ataques que se encontrarán en el futuro.

Esto también funciona para cosas generales de seguridad del sitio web:

HTTPS: https is ... recommended to use TLS X.Y ...

We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.

También intente crear plantillas de sus informes, ya que no desea volver a escribir todo lo relacionado con SQL-Injection y HTTPS / TLS, etc. una y otra vez, por lo que solo tiene que completar los resultados de sus pruebas. Esto también asegurará que haya realizado todas las pruebas y no se haya perdido ninguna, cuando vea un párrafo que no se ha escrito y que no se haya encontrado nada, ni tenga ningún hallazgo.