Come presentare al meglio "Feedback sulla vulnerabilità della sicurezza" agli sviluppatori nell'IDE (come VisualStudio)

Questa è un'idea fantastica, ma penso che per riuscirci è importante integrarlo perfettamente con l'ambiente esistente.

A tal fine, suggerirei di NON presentare un nuovo modo inaspettato di presentare le informazioni, ma di utilizzare i formati e i meccanismi esistenti.

Ad esempio, sottolinea le vulnerabilità critiche e ad alto rischio con una linea ondulata rossa - proprio come fa Visual Studio per errori di compilazione per impostazione predefinita, e proprio come quasi tutti i programmatori si aspettano. Potresti contrassegnare difetti meno gravi con colori meno spaventosi: blu, verde, ecc Farei un ulteriore passo avanti e consentire che questo sia configurabile, nella finestra di dialogo delle opzioni di% VS% di int VS, per consentire ai programmatori di adattarlo alle loro impostazioni specifiche o persino di farlo risaltare. Potresti avere un'impostazione per Critical, un altro colore per High, ecc.

Inoltre, proprio come per gli errori e gli avvisi di compilazione, dovrebbe esserci una finestra che elenca tutti i problemi attualmente trovati: più ricca è questa finestra, meglio è, ovviamente, (filtraggio, ordinamento, ecc.).

Ciò farebbe una grande distanza nel formare gli sviluppatori che difetti di sicurezza, sono bug come bug funzionali e, in alcuni casi (ad esempio Critico / Alto), dovrebbero essere trattati come errori di compilazione.

Si noti che l'Analisi del codice integrata di VS funziona in modo simile a questo (eccetto per il momento non in tempo reale).

Che ne dici di attivare una compilazione di sicurezza quando la finestra perde lo stato attivo o si concentra? O dopo 10 secondi di inazione dell'utente? Sicuramente lo fai quando il file viene salvato, è una buona cosa che avviene sempre pre-build.

Per il feedback degli sviluppatori, per quanto riguarda la visualizzazione di teschi e ossa incrociate colorati nella parte sinistra del riquadro, nell'area in cui vengono visualizzati i punti di interruzione del debug. Colorali per indicare la gravità: qualcosa come il giallo per "deve aggiustare" e il rosso per "OMG !!!" Passando il puntatore del mouse su di essi potrebbe apparire un suggerimento che descrive il bug.

Forse imposta lo sfondo su un gradiente rosso chiaro (o colorato), con l'intensità centrata sulla vulnerabilità. Oppure usa barre colorate lungo la barra di scorrimento, come lo schermo di WinDiff per mostrarti dove sono le differenze. Utilizza segmenti di linea neri, bianchi o inesistenti per nessuna regione di bug e segmenti di linea che corrispondono ai teschi che rappresentano le vulnerabilità.

Per lo meno assicurati che stia emettendo errori che interrompono la compilazione.

Devi dire allo sviluppatore che nessun sistema automatizzato può trovare ogni difetto, e lo sviluppatore deve essere in punta di piedi e cercare i difetti da solo. Un falso senso di sicurezza è la cosa absolute | worst | che potresti fornire a uno sviluppatore.

Non fidarti di nulla, prova tutto.

(Una nota a margine, semplicemente evidenziare ogni funzione pericolosa e fornire una documentazione del perché è pericoloso potrebbe essere molto utile. Inoltre, dovresti riconoscere che non sarai mai in grado di risolvere 1/2 dei gravi problemi di sicurezza in un vero applicazione con questa "soluzione". L'assenza di un controllo importante non può essere sottolineata o evidenziata, perché non esiste.)

Sviluppatore qui - usa solo gli strumenti & caratteristiche visive sono fornite all'interno dell'IDE. Non cercare di introdurre il tuo gusto in quanto è solo una cosa nuova che devono imparare. Dopotutto stai solo evidenziando un'area problematica

In nessun punto del IDE dovresti dettare la forma corretta del codice, perché non capisci il contesto in cui lo sviluppatore sta lavorando al momento. Questo tipo di lavoro dovrebbe avvenire all'interno di una pipeline di build per un rilascio.

Se blocchi un progetto dalla compilazione a causa di un problema di sicurezza percepito, il tuo strumento è un problema e deve essere rimosso immediatamente da qualsiasi ambiente di sviluppo.

A volte le persone vogliono scrivere codice vulnerabile come un'imbracatura di test OPPURE su una base di codice esistente ci sono controlli al di fuori della base di codice. Per non parlare di Roslyn Diagnostic Analyzer è terribile nell'ambito del progetto ed è limitato a una singola unità.