Cómo presentar mejor 'Comentarios sobre la vulnerabilidad de la seguridad' a los desarrolladores en el IDE (como VisualStudio)

Esta es una idea muy buena, pero creo que para tener éxito es importante integrarla perfectamente en el entorno existente.

A tal fin, sugeriría que NO se presente una nueva forma inesperada de presentar la información, sino que se utilicen los mecanismos y los formatos existentes.

Por ejemplo, subraya las vulnerabilidades críticas y de alto riesgo con una línea roja ondulada, tal como lo hace Visual Studio para los errores de compilación de forma predeterminada, y tal como lo esperan casi todos los programadores. Podría marcar defectos menos graves con colores menos espeluznantes: azul, verde, etc.
Iría un paso más allá y permitiría que esto fuera configurable, en el cuadro de diálogo de opciones de Fonts and Colors del int VS, para permitir que los programadores lo adapten a su configuración específica, o incluso que se destaque. Podría tener un ajuste para Crítico, otro color para Alto, etc.

Además, al igual que con los errores de compilación y las advertencias, debería haber una ventana que enumere todos los problemas encontrados actualmente; cuanto más rica sea esta ventana, mejor, por supuesto (filtrado, clasificación, etc.).

Esto ayudaría a la capacitación de los desarrolladores de que las fallas de seguridad, son errores como errores funcionales y, en algunos casos (por ejemplo, Critical / High), deben tratarse como errores de compilación.

Tenga en cuenta que el análisis de código incorporado de VS funciona de forma similar (excepto en tiempo real, en su mayor parte).

¿Qué hay de activar una compilación de seguridad cuando la ventana pierde el foco o se enfoca? ¿O después de 10 segundos de inacción del usuario? Definitivamente, hágalo cuando se guarde el archivo, es una buena idea que siempre ocurre antes de la compilación.

Para comentarios de los desarrolladores, ¿qué tal si se muestran cráneos y tibias cruzadas de colores en el lado izquierdo del panel, en el área al lado de donde se muestran los puntos de interrupción de la depuración? Coloréelos para indicar la severidad: algo como amarillo para "debe arreglarse", y rojo para "¡Dios mío!" Al pasar el puntero del mouse sobre ellos podría aparecer una sugerencia de herramienta que describe el error.

Tal vez establezca el fondo a un degradado rojo claro (o coloreado), con la intensidad centrada en la vulnerabilidad. O use barras de colores junto a la barra de desplazamiento, como la pantalla de WinDiff para mostrarle dónde están las diferencias. Use segmentos de línea negros, blancos o inexistentes para las regiones sin errores, y los segmentos de líneas que tienen el mismo color que las calaveras que representan las vulnerabilidades.

Por lo menos asegúrese de que haya errores de salida que rompan la compilación.

Debe decirle al desarrollador que ningún sistema automatizado puede encontrar todos los defectos, y el desarrollador debe estar alerta y buscar defectos por su cuenta. Una falsa sensación de seguridad es la cosa absoluta | peor | que puede proporcionar a un desarrollador.

No confíes en nada, prueba todo.

(En una nota al margen, simplemente resaltando cada función peligrosa y proporcionando documentación de por qué es peligroso podría ser muy útil. Además, debe reconocer que nunca podrá resolver la mitad de los problemas de seguridad graves de una manera real). aplicación con esta "solución". La falta de un control importante no se puede subrayar ni resaltar, porque no existe.)

Desarrollador aquí: solo usa las herramientas & Las características visuales se proporcionan dentro del IDE. No intentes traer tu propio sabor, ya que es solo una cosa nueva que necesitan aprender. Después de todo, solo estás resaltando un área problemática

En ningún punto del IDE debe dictar la forma correcta del código, porque no entiende el contexto en el que el desarrollador está trabajando actualmente. Este tipo de trabajo debería ocurrir dentro de una tubería de compilación para un lanzamiento.

Si está bloqueando la compilación de un proyecto debido a un problema de seguridad percibido, entonces su herramienta es un problema y debe eliminarse inmediatamente de cualquier entorno de desarrollo.

Algunas veces las personas desean escribir código vulnerable como un arnés de prueba O en una base de código existente, hay controles fuera de la base de código. Sin mencionar que Roslyn Diagnostic Analyzer es terrible en el alcance del proyecto y se limita a una sola unidad.