Ottima domanda! Ho scritto alcuni di questi, ma ho sempre avuto un modo molto formale di farlo, in modo tale che non ho mai avuto la possibilità di pensare a ciò che è veramente necessario ...
Dal punto di vista delle persone che devono utilizzare e supportare e aggiornare il tuo prodotto, penso che devi coprire:
-
Informazioni di alto livello (e un puntatore se possibile per i dettagli) - sul perché era necessaria la correzione. Qualcosa di simile - "corretta gestione del buffer delle stringhe nel componente XYZ" è utile.
-
Problemi noti: tutto ciò che non è stato ancora risolto e che è ancora presente.
-
Aggiornamenti di software di terze parti e un luogo in cui trovare la previsione corrente di tutto il software di terze parti, indipendentemente dal fatto che sia stato aggiornato o meno.
In sostanza, hanno bisogno di sapere cosa hai corretto e la tua linea di base. In particolare nel mondo di Java, ci possono essere conflitti e problemi sufficienti, che una società saggia dovrebbe tenere un conto corrente di quali server stanno eseguendo le versioni delle JVM e di altri componenti.
Altre risposte specifiche per le tue domande:
-
Dovremmo elencare le vulnerabilità corrette in Apache Httpd? O abbastanza link al sito di Apache?
- Un link sarebbe una gentilezza. Non ingombrare le note sulla versione con i dettagli di altri prodotti.
-
Dovremmo gestire l'elenco dei software di terze parti con le versioni?
- Dovrebbe essere disponibile da qualche parte, non sono sicuro che debba essere incluso nelle note di rilascio, ma in caso contrario, dovrebbe essere sul tuo sito web da qualche parte.
-
E le nostre vulnerabilità di sicurezza interna? Dovremmo elencare l'elenco delle vulnerabilità di sicurezza fisse? Potrebbe essere pericoloso per quei clienti che non eseguiranno l'aggiornamento alla versione più recente.
- Tieni presente che la mancata divulgazione di vulnerabilità note potrebbe essere considerata una responsabilità legale. Questo è uno per i tuoi avvocati. IMO, dire ai clienti in modo che sappiano perché una correzione per la sicurezza è così importante è più importante del valore di oscurarlo per la sicurezza di quelli che non possono aggiornarsi abbastanza velocemente. Detto questo, non devi dire "se tu X, Y, Z otterrai i privilegi di amministratore". Dire "vulnerabilità compromessa nel sistema di controllo degli accessi" dovrebbe essere abbastanza buono.
-
Come dovremmo annunciare le vulnerabilità della sicurezza? Dovremmo aggiungere il nostro fornitore al database CVE link e creare un nuovo CVE ogni volta che lo abbiamo trovato? O abbastanza per elencare il nostro numero di bug interno?
- Non sono sicuro di cosa intenda per "il nostro venditore" - personalmente non registrerei una terza parte per i risultati CVE senza concordare con loro su di essa.
-
Dovremmo aggiungere al database CVE solo le vulnerabilità scoperte dai nostri clienti? Dovremmo aggiungere al database CVE anche le vulnerabilità scoperte dal QA?
- Devo ancora sentire di qualsiasi fornitore che utilizza CVE per la documentazione interna di test / correzione. Penso che se l'hai trovato per primo, il collegamento al tuo repository di bug risolti dovrebbe andare bene, ma non ho fatto molto software commerciale.