Recentemente sono stato coinvolto in una revisione del codice di sicurezza.
Ho trovato molte stringhe di formato, overflow del buffer e pericolose chiamate alla funzione libc.
In questo momento ho bisogno di scrivere un rapporto con tutto il materiale fondato in modo chiaro e utile.
Voglio conoscere la tua esperienza su come organizzi questo tipo di rapporto.
Ho bisogno di cavarmela con - ci sono un milione di modi diversi per farlo e la maggior parte delle organizzazioni ha il suo. La maggior parte della mia esperienza in società di servizi professionali globali ha lo scopo di fornire questo tipo di report ai responsabili IT Security, CISO ed Executive boards, quindi il tuo chilometraggio può variare. Un breve riepilogo:
Primo: pensa al tuo pubblico
Se consegni agli sviluppatori IT e ai team di supporto, tutto ciò che vorranno è un elenco di problemi con priorità, i passaggi da correggere e un link alla descrizione del fornitore (ad esempio la pagina MS KB)
Se consegnate ai capi dipartimento, vorrebbero un elenco con priorità con una stima del rischio e della probabilità di sfruttamento, il tempo per sistemare ciascuna di esse e possibilmente rilasciare i proprietari (anche se potrebbe non essere una vostra responsabilità)
Ci sono altri tipi di pubblico, ma questi due sono probabilmente i più comuni. Pertanto, spesso è utile fornire un rapporto adatto a entrambi.
Quello che di solito preparo è un sommario esecutivo che elenca il motivo per cui il lavoro è stato svolto (ad esempio per un audit), implicazioni di alto livello dei risultati (solitamente gli indicatori Rosso / Ambra / Verde per il consiglio) e una stima del tempo da correggere. Ciò aiuta l'alta direzione a stabilire priorità per budget e risorse. La formulazione qui deve essere adatta per essere presa alla lavagna se necessario, quindi nessun dettaglio tecnico!
Inoltre includerò un'appendice tecnica che contiene le informazioni necessarie al team di riparazione per apportare le correzioni pertinenti. Questo può essere semplice come un foglio di calcolo Excel.
Qual è l'obiettivo del rapporto?
Alcune organizzazioni eseguono tali rapporti perché la gente glielo dice, non hanno idea di cosa fare con loro e lo buttano via immediatamente.
Alcune organizzazioni utilizzano erroneamente tali rapporti per giudicare l'idoneità del codice. È sbagliato, perché la maggior parte dei problemi segnalati sono "falsi positivi", semplici avvertimenti di pericoli, ma non di bug praticamente sfruttabili.
Alcune organizzazioni, quelle intelligenti, includono questo nel loro processo di sviluppo. Eseguono regolarmente tali rapporti e tracciano nel tempo le riduzioni degli avvisi man mano che entrano nel codice e risolvono i problemi.
Una volta individuato l'obiettivo, inseriscilo come elemento principale e organizza le cose per supportarlo.
Leggi altre domande sui tag professional-education code-review