el modelado de amenazas definitivamente ayudaría a determinar los casos de prueba y dónde realizar la confusión, pero mi pregunta es específica para el escaneo de códigos. ¿Ayudaría el modelado de amenazas a enfocar / priorizar o de alguna manera el análisis de código estático?
En resumen, sí lo haría. Pero también podría usar un enfoque de clasificación simple si el modelado de amenazas es demasiado costoso.
En detalle -
El análisis de código puede ser una actividad que consume tiempo. Incluso los enfoques de herramienta de punta generarán grandes cantidades de resultados que requerirán revisión y priorización por parte del ser humano. Como tal, el enfoque de modelación de amenazas puede ayudar a identificar y clasificar ese esfuerzo. Esto es especialmente importante en las revisiones de grandes bases de código.
Desde el punto de vista del modelado de amenazas, dividiría el código en las siguientes áreas (en orden de importancia):
Esto le dará un enfoque prioritario para la revisión del código y un marco para asignar el nivel apropiado de riesgo a cada hallazgo, por ejemplo, se podría considerar que una falla en la entrada del usuario de manejo de código desde un espacio no autenticado presenta una prioridad más alta para solucionar el problema del mismo tipo de problema dentro de un área limitada y confiable de la aplicación.
Tal como se solicitó, ahora se combina con la respuesta de @ this.josh (esta es una versión editada, lea @ this.josh para ver el texto completo, vale la pena leerlo)
Si está buscando hacer un trabajo más completo, entonces debe considerar la exposición:
¿Algún código se ejecuta con más frecuencia?
¿Algún código es más fácil de pasar datos?
¿Es más fácil depurar código para ver los efectos de?
¿A qué recursos accede el código?
¿Qué protege el código? (los activos)
¿Qué código se basa en el hardware para la protección?
¿Qué código se basa en otro código para protegerlo? (¿Cuál es su modelo de protección?)
¿Qué código proporciona tolerancia a fallos o recuperación de errores?
Considerar las amenazas, las exposiciones, los activos y el modelo de protección lo ayudará a tomar buenas decisiones sobre qué probar y cómo probarlo.
Definitivamente tal vez.
Los métodos y técnicas tienen valor cuando te ayudan a completar una tarea de manera más completa o con menos recursos que otro enfoque.
Entonces, ¿estás buscando hacer el trabajo a fondo o de manera más eficiente?
El modelado de amenazas puede ayudarlo a crear casos de prueba que anticipen un ataque práctico e ignoren los casos de prueba, y por lo tanto el código, que una amenaza no (o no podría) intentar explotar. Esto contrasta con la entrada de fuzzing para la mayoría o todo el código accesible. Por supuesto, tiene poco sentido verificar el código al que un atacante no pudo acceder.
Si está buscando hacer un trabajo más completo, entonces debe considerar la exposición:
¿Algún código se ejecuta con más frecuencia?
¿Algún código es más fácil de pasar datos?
¿Algún código es más fácil de depurar para ver los efectos?
Y luego, como observa @David Stubley, debe considerar el valor del código y a qué protege o proporciona acceso el código.
¿A qué recursos accede el código?
¿Qué protege el código? (los activos)
¿Qué código se basa en el hardware para la protección?
¿Qué código se basa en otro código para protegerlo? (¿Cuál es su modelo de protección?)
¿Qué código proporciona la corrección de errores o la recuperación de errores?
Teniendo en cuenta las amenazas, las exposiciones, los activos y el modelo de protección, ayudarlo a tomar buenas decisiones sobre qué probar y cómo probarlo.
parte de this.josh
Definitivamente tal vez.
Los métodos y técnicas tienen valor cuando te ayudan a completar una tarea de manera más completa o con menos recursos que otro enfoque.
Entonces, ¿estás buscando hacer el trabajo a fondo o de manera más eficiente?
El modelado de amenazas puede ayudarlo a crear casos de prueba que anticipen un ataque práctico e ignoren los casos de prueba, y por lo tanto el código, que una amenaza no (o no podría) intentar explotar. Esto contrasta con la entrada de fuzzing para la mayoría o todo el código accesible. Por supuesto, tiene poco sentido verificar el código al que un atacante no pudo acceder.
Si está buscando hacer un trabajo más completo, entonces debe considerar la exposición:
¿Algún código se ejecuta con más frecuencia?
¿Algún código es más fácil de pasar datos?
¿Algún código es más fácil de depurar para ver los efectos?
Y luego, como observa @David Stubley, debe considerar el valor del código y a qué protege o proporciona acceso el código.
¿A qué recursos accede el código?
¿Qué protege el código? (los activos)
¿Qué código se basa en el hardware para la protección?
¿Qué código se basa en otro código para protegerlo? (¿Cuál es su modelo de protección?)
¿Qué código proporciona la corrección de errores o la recuperación de errores?
Considerar las amenazas, las exposiciones, los activos y el modelo de protección lo ayudará a tomar buenas decisiones sobre qué probar y cómo probarlo.
Lea otras preguntas en las etiquetas threat-modeling vulnerability-scanners