Nel software libero c'è una discreta regolare continuità tra le discussioni puramente interne e le regole delle pubbliche relazioni. Ciò avviene in parte perchè il pubblico di destinazione è mal definito. Dato che la maggioranza o tutti i post sono pubblicamente accessibili, il progetto non ha il controllo pieno sull'impressione che ne ha il mondo. Qualcuno,— diciamo, un editor slashdot.org —può attrarre l'attenzione dei lettori verso un post che nessuno si sarebbe mai aspettato che sarebbe stato visto dall'esterno del progetto. Questo è un fatto concreto con la quale convivono tutti i progetti open source, ma in pratica, il rischio è piccolo. In generale gli annunci che più il progetto vuole che siano pubblicizzati sono quelli che saranno più pubblicizzati, nell'ipotesi che usiate i meccanismi giusti per indicare la rilevanza di una notizia al mondo esterno.
Per gli annunci principali tendono ad esserci quattro o cinque principali canali di distribuzione, sui quali gli annunci dovrebbero essere fatti quanto più simultaneamente possibile:
La pagina principale del vostro progetto è vista probabilmente da più gente che qualsiasi altra parte del progetto. Se avete annunci veramente importanti mettete lì una breve inserzione. La breve inserzione dovrebbe essere un piccolo specchietto che linki al comunicato stampa (vedere sotto) per maggiori informazioni.
Allo stesso tempo, voi dovreste avere una area “Notizie” o ”Comunicati stampa” sul sito, dove un annuncio possa essere scritto nei dettagli. Parte del proposito di un comunicato stampa e quella di fornire un solo canonico “oggetto annuncio”a cui altri siti possano linkare, in modo da assicurarsi che esso sia strutturato di conseguenza: sia come pagina web per le release, sia come nuova entrata nel blog, sia come altro tipo di entità che possa essere linkata pur essendo tuttavia tenuta distinta da altri comunicati stampa nella stessa area.
Se il vostro progetto ha un feed RSS, assicuratevi che l'annuncio vada anche lì. Ciò può avvenire automaticamente quando create il comunicato stampa, a seconda di come le cose sono messe sul vostro sito. (RSS è un meccanismo per distribuire sommari di meta dati ricchi agli “iscritti”, cioè gente che ha indicato un interesse nel ricevere questi sommari. Vedere per maggiori informazioni sugli RSS. Se l'annuncio riguarda una nuova release del software, allora aggiornate la voce del vostro progetto su (vedere http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html per maggiori informazioni sugli RSS.)
Se l'annuncio riguarda una nuova release del software, allora aggiornate la voce del vostro progetto su http://freshmeat.net/ (vedere su come creare la voce in primo luogo). Ogni volta che aggiornate una voce di Freshmet, quella voce va sulla change list per il giorno. La change list non è aggiornata solo sullo stesso Freshmet, ma sui vari portali (incluso http://slashdot.org) che sono osservati ansiosamente da orde di gente. Freshmet offre gli stessi dati via feed RSS, così la gente che non è iscritta al suo feed RSS del vostro progetto può ancora vedere l'annuncio attraverso quelli di Freshmet.
Mandate una email alla mailing list degli annunci del progetto. Il nome di questa mailing list dovrebbe essere veramente “annuncia”, ciòè, annuncia@yourprojectdomain.org,
perché questa è una convenzione piuttosto standard ora e lo statuto della mailing list dovrebbe render chiaro che è a traffico molto lento riservata agli annunci principali del progetto. La maggior parte di questi annunci saranno sulle release del software, ma occasionalmente su altri eventi, come una iniziativa di raccolta fondi, la scoperta di una vulnerabilità nella sicurezza (vedere
sezione chiamata «Annunciare le Vulnerabilità della Sicurezza»)
più avanti in questo capitolo, o un cambiamento nel progetto può essere postato anche lì. Poiché essa è a basso traffico e usata solo per cose importanti, la mailing list annuncia ha tipicamente la più alta quantità di iscritti di ogni mailing list nel progetto (certo, ciò significa che voi non dovete abusare con essa— riflettete prima di postare). Per evitare che gente a caso faccia annunci, o peggio, spam di passaggio, la mailing list annuncia deve sempre essere moderata.
Cercate di fare gli annunci in tutti i posti in modo simultaneo quanto più è possibile. La gente potrebbe confondersi vedendo un annuncio sulla mailing list ma poi non vedendolo nella pagina principale del sito del progetto o nell'area dei comunicati stampa. Se ricevete i vari cambiamenti (emails, scrittura delle pagine web, ecc..) in un fila di attesa e le mandate tutte in un riga potete mantenere molto piccola la finestra di incoerenza.
Per un evento meno importante, potete eliminare una o tutte le uscite di cui sopra. L'evento sarà ugualmente notato dal mondo di fuori in proporzione alla susa importanza. Per esempio, se una nuova release del software è un evento importante, il fissare solamente la data della nuova release, mentre tuttavia in qualche modo fa notizia, non è quasi così impostate quanto la release stessa. Il fissare una data ha il valore di una email alle mailing list giornaliere (non alla maling list annuncia) e di un aggiornamento della linea del tempo del progetto e della pagina web dello stato, ma niente di più.
Comunque potreste vedere quella data apparire nella discussione da qualche altra parte in Internet, ovunque ci sia gente interessata al progetto. Persone che stanno in disparte sulle vostre mailing list, solo per ascoltare e mai dire qualcosa, non stanno necessariamente zitte altrove. L'orale dà una distribuzione molto ampia; dovreste contare su essa, e costruire anche annunci minori in modo da incoraggiare una trasmissione informale accurata. Nello specifico, post che vi aspettate siano quotati dovrebbero avere una parte finalizzata ad essere quotata, giusto come se steste scrivendo un comunicato stampa. Per esempio:
Giusto un aggiornamento nel progresso: state progettando di rilasciare la versione 2.0 di Scanley a metà Agosto 2005. Potete sempre controllare http://www.scanley.org/status.html per aggiornamenti. La principale funzionalità sarà la ricerca con le espressioni regolari.
Le altre nuove funzionalità includono: ... Ci saranno anche varie correzioni di bug, incluso: ...
Il primo paragrafo è breve, dà i due più importanti pezzi di informazione (la data del rilascio e la principale nuova funzionalità), e un URL da visitare per ulteriori notizie. Se quel paragrafo è la sola notizia che attraversa lo schermo di qualcuno, state ancora facendo molto bene. Il resto della email potrebbe andar perso senza aver effetto sulla sostanza del contenuto. Certo, a volte le persone vorranno linkare all'intera email comunque, ma appunto come spesso, essi ne citeranno solo una piccola parte. Dato che l'ultima ipotesi è una possibilità, potete anche renderla facile per loro, e nel patteggiare avere qualche influenza su ciò che viene citato.
Gestire le vulnerabilità della sicurezza è differente dal gestire ogni altro tipo di report di bug. Nel software libero, fare le cose apertamente e con trasparenza è normale quasi come un credo religioso. Ogni passo della gestione standard dei bug è visibile a tutti quelli che hanno la cura di di guardare: l'arrivo del report iniziale, la conseguente discussione, e l'eventuale correzione.
I bug della sicurezza sono differenti. Essi possono compromettere i dati degli utenti, e magari l'intero computer dell'utente. Per discutere apertamente un tale problema si dovrebbe avvisare della sua esistenza il mondo intero—incluse tutte le parti che potrebbero fare un uso maligno del bug. Anche solo facendo l'invio della correzione in effetti dà l'annuncio dell'esistenza del bug (ci sono persone potenziali che sferrano gli attacchi che guardano i log degli invii dei progetti pubblici, sistematicamente alla ricerca di cambiamenti che indicano problemi di sicurezza nel codice di pre cambiamento). Molti progetti open source hanno fissato lo stesso gruppo di passi per gestire questo conflitto fra l'essere aperti e la segretezza, basati su queste linee guida:
Non parlate del bug pubblicamente finché non sia disponibile un correzione; quindi fornite la correzione all'esatto stesso momento in cui annunciate il bug.
Arrivate con quella correzione quando più velocemente potete—specialmente se qualcuno al di fuori del progetto riportò il bug, perché allora voi sapete che c'è almeno una persona al di fuori del progetto che è in grado di sfruttare la vulnerabilità.
In pratica questi principi portano a una serie di passi molto standardizzati che sono descritti nella sezione sotto.
Ovviamente il progetto ha bisogno di ricevere i bug nella sicurezza da ognuno. Ma gli indirizzi dei rapporti dei bug non ne hanno bisogno, perché anche essi sono visti da chiunque. Quindi, abbiate un mailing list separata per ricevere i rapporti dei bug nella sicurezza. Questa mailing list non deve avere archivi leggibili pubblicamente, e i loro iscritti devono essere strettamente controllati—solo sviluppatori di lungo periodo fidati possono stare sulla mailing list. Se avete bisogno di una definizione formale di “fidati”, dovete usare “chiunque abbia avuto l'accesso all'invio da due anni o più”, o qualcosa di simile, per evitare favoritismi. Questo è il gruppo che deve gestire i bug nella sicurezza.
Idealmente, la mailing list sulla sicurezza non dovrebbe essere protetta da spam o moderata, perché non potete volere che un importante report sia filtrato o ritardato giusto perché è avvenuto che nessun moderatore fosse online quel weekend. Se usate programmi di protezione da spm automatici, cercate di configurarli con settaggi di alta tolleranza; è meglio consentire pochi spam che perdere un report. Affinché la mailing list sia efficiente dovete pubblicizzare il suo indirizzo, certo; ma dato che non sarà moderata o, al massimo, leggermente protetta da spam, non cercate mai di postare il suo indirizzo senza una qualche sorta di trasformazione di nascondimento, come descritto in sezione chiamata «Nascondere gli indirizzi presenti negli archivi» in Capitolo 3, L'Infrastruttura Tecnica . Fortunatamente per nascondere dell'indirizzo non c'è bisogno che l'indirizzo sia illeggibile; vedere http://subversion.tigris.org/security.html, e prendete visione del sorgente della pagina Html, per un esempio.
E così cosa fa la mailing list quando riceve un report? Il primo compito è quello di valutare la serietà e la urgenza del problema:
Quanto seria è la vulnerabilità? Permette a chi fa l'attacco di prendere la direzione del computer si qualcuno che usa ilo vostro software? O si perdono semplicemente informazioni sulla grandezza di qualcuno dei suoi file?
Quanto facile è sfruttare la vulnerabilità? Può un attacco essere prestabilito, o richiede una conoscenza profonda, o un calcolo studiato, e fortuna?
Chi fece il report del problema a voi? Lar risposta a questa domanda non cambiate la natura della vulnerabilità, certo, ma vi dà un'idea di quante altre persone potrebbero sapere di essa. Se il report viene da una degli sviluppatori del progetto, voi potete respirare un pò più facilmente (ma solo un poco) perché potete confidare sul fatto che egli non ha parlato a nessuno di esso. D'altro canto, se il report viene con una email da anonimo14@globalhackerz.net,
allora sarebbe meglio che che voi agiate quanto più velocemente possibile. La persona vi fece un favore informandovi del problema, ma non avete idea di quante persone sono state informate da lui, o di quanto abbia aspettato prima di sfruttare la vulnerabilità sulle installazione caricate.
Notate che la differenza di cui stiamo parlando qui è fra urgente e estremamente urgente. Anche quando il report proviene da una fonte nota e amica, ci potrebbe essere altra gente sulla rete che scoprì il bug da tempo e che non lo ha giusto riportata. La sola occasione in cui le cose non sono urgenti è quando il bug in modo innato non compromette la sicurezza in modo serio.
L'esempio "anonimo14@globalhackerz.net" non è faceto, tra parentesi. Voi potete ricevere realmente dei rapporti di bug da persone dall'identità nascosta, che con le loro parole e il loro comportamento, non chiariscono del tutto se sono dalla vostra parte o no. Non ha importanza: se hanno fatto rapporto sul buco nella sicurezza a voi essi riterranno di avervi fatto un favore, e voi potete rispondere a modo. Ringraziateli per il report, dategli una data nella o prima della quale progettate di rilasciare una correzione pubblica, e teneteli nel giro. A volte essi possono dare a voi una data—cioè, una minaccia intrinseca di pubblicizzare il bug in una certa data, siate pronti o no. Questo può essere avvertito come un minaccioso gioco di potere, ma è più probabilmente una azione preventiva risultante dalla passata delusione con produttori di software indifferenti che non presero i report di sicurezza abbastanza seriamente. D'altra parte, voi non potete permettervi di irritare questa persona. Dopotutto, se ilo bug è serio, egli ha conoscenze che potrebbero causare grossi problemi ai vostri utenti. Trattate bene queste persone che fanno i report, e sperate che trattino bene voi.
Un'altra persona che fa frequenti report di sicurezza è il professionista della sicurezza, uno che controlla il codice per campare e si mantiene con le ultime notizie sulle vulnerabilità della sicurezza. Queste persone hanno di solito esperienza su tutti e due i lati della staccionata—essi hanno ricevuto e mandato report, magari più della maggioranza degli sviluppatori nel vostro progetto. Essi anche di solito danno anche una scadenza sulla correzione di una vulnerabilità, prima che diventi pubblica. Questa scadenza può essere in un certo modo negoziabile ma questo tocca a chi manda il report; le scadenze sono diventate riconosciute fra i professionisti della sicurezza in qualche grado come l'unica via affidabile per ottenere che le organizzazioni affrontino i problemi di sicurezza tempestivamente. Così non trattate le scadenze da maleducati; è una tradizione che gode di buona reputazione, e ci sono buone ragioni per questo.
Una volta che ne conoscete la serietà e l'urgenza, potete partire col lavoro della correzione. A volte c'è un compromesso fra il fare una correzione elegantemente e il farla velocemente; questo è il perché dovete accordarvi sull'urgenza prima di partire. Mantenete la discussione ristretta ai membri della mailing list, più chi fece il report originariamente (se lui vuole essere coinvolto), a qualche sviluppatore che è necessario tirare dentro per ragioni tecniche.
Non inviate la correzione al deposito. Mantenetela in forma di patch fino alla data di andare in pubblico. Nel caso doveste inviarla, anche con un log innocente a vedersi, qualcuno potrebbe notarla e capire il cambiamento. Voi non sapete mai chi sta guardando nel deposito, e perché sarebbe interessato. Cessare le email di invio non aiuterebbe; prima di tutto l'interruzione nella sequenza dell'invio delle email potrebbe sembrare il se stessa sospetta, e comunque, i dati sarebbero tuttavia nel deposito. Appunto fate tutto lo sviluppo in una patch e tenete la patch in qualche posto privato, magari un deposito privato separato conosciuto solo alle persone al corrente del bug. (Se usate un sistema di controllo della versione decentrato come Arch o SVK, potete fare il lavoro sotto il pieno controllo della versione, e giusto tenete quel deposito inaccessibile agli esterni.)
Potete aver visto un numero CAN o un numero CVE associati con i problemi di sicurezza. Questi numeri di solito appaiono come "CAN-2004-0397" o "CVE-2002-0092", per esempio.
Ambedue i tipi di numeri rappresentano lo stesso tipo di entità: una voce nella lista di “Vulnerabilità comuni ed Esposizioni” curata in http://cve.mitre.org/. Il proposito della lista è quello di fornire nomi standardizzati per tutti i problemi conosciuti di sicurezza, in modo che chiunque deve usare un unico nome canonico quando ne discute uno e un posto centralizzato dove andare per trovare maggiori informazioni. La sola differenza tra il numero “CAN” e “CVE” è che il primo rappresentata una voce candidata, non ancora approvata per l'inserimento nella lista della dal Consiglio editoriale della CVE e il secondo rappresenta una voce approvata. Comunque tutti e due i tipi di voce sono visibili al pubblico, e il numero di una voce non cambia quando è approvato—il prefisso “CAN” è solo sostituito da “CVE”
Una voce CAN/CVE non contiene di per se stessa una descrizione completa del bug non dice come proteggersi da essa. Invece, contiene un breve sommario, e un elenco di riferimenti a risorse esterne (come archivi di mailing lista) dove la gente possa andare per prende maggiori informazioni. Il vero proposito di è quello di fornire uno spazio ben organizzato in cui in cui ogni vulnerabilità possa avere un nome e una chiara rotta verso dati ulteriori. Vedere http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 per un esempio di voce. Notate che i riferimenti possono essere molto succinti, con le sorgenti che appaiono abbreviazioni criptate. Una chiave per queste abbreviazione si trova a http://cve.mitre.org/cve/refs/refkey.html.
Se la vostra vulnerabilità soddisfa i criteri CVE, potete voler acquisire ad esso un numero CAN. Il procedimento per fare ciò e deliberatamente impedito: fondamentalmente voi dovete conoscere qualcuno, o conoscere qualcuno che conosce qualcuno. Ciò non è folle come potrebbe suonare. Affinché il Consiglio Editoriale del CVE eviti di essere travolto con candidature spurie o scritte in modo deficitario, prende candidature solo da fonti già note o fidate. Per ottenere che la vostra vulnerabilità sia elencata, quindi, avete bisogno di un percorso di conoscenze dal vostro progetto al Consiglio Editoriale del CVE. Chiedete fra i vostri sviluppatori; uno di essi o probabilmente conosce qualcun altro che ha percorso il procedimento CAN prima, o qualcuno che lo ha, ecc.. Il vantaggio di fare ciò in questo modo è anche quello che in qualche punto lungo la catena, qualcuno può sapere abbastanza da dire a) che essa non conterebbe come vulnerabilità o come esposizione in accordo con i criteri del MITRE, per cui non è il caso di inviarla o b) la vulnerabilità ha già un numero CAN o CVE. La seconda cosa può presentarsi se il bug è stato appena pubblicato su un'altra mailing list consultiva di sicurezza, per esempio su http://www.cert.org/ o sulla mailing list BugTraq a http://www.securityfocus.com/. (Se ciò è avvenuto senza che il vostro progetto ne abbia sentito parlare, allora vi dovreste preoccupare di cos'altro potrebbe andare avanti di cui voi non avete conoscenza).
Se ottenete un numero CAN/CVE, voi volete ottenerlo nei primi stadi dell'investigazione sul bug, in modo che tutte le ulteriori comunicazioni possano far riferimento a quel numero. Le voci CAN vengono impedite fino alla data della pubblicazione; la voce consisterà in un simbolo vuoto (così voi non perdete il nome), ma ciò non rivelerà nessuna informazione sulla vulnerabilità fino alla data in cui voi annunciate il bug e la correzione.
Maggiori informazioni sul processo CAN/CVE possono essere trovate a http://cve.mitre.org/about/candidates.html, e una esposizione particolarmente chiara dell'uso da parte di un progetto open source dei numeri CAN/CVE si trova a http://www.debian.org/security/cve-compatibility.
Una volta che il team delle risposte sulla sicurezza (cioè quegli sviluppatori che stanno sulla mailing list della sicurezza, o che sono stati tirati dentro l'affare della sicurezza con un particolare rapporto) ha una correzione pronta, dovete decidere come distribuirla.
Se inviate semplicemente la correzione al deposito, o diversamente la annunciate al mondo, voi in effetti costringete chiunque usi il vostro software ad aggiornare immediatamente o rischiare di essere bucato. Talvolta è appropriato, quindi, fare una pre notifica per certi utenti importanti. Ciò è particolarmente vero per il software client/server, dove ci possono essere ben noti server che sono degli allettanti obiettivi per chi fa gli attacchi. Gli amministratori di questi server apprezzerebbero il fatto di avere qualche giorno in più o due per fare l'aggiornamento, in modo da essere protetti nel frattempo che il metodo di attacco diventa di pubblica conoscenza.
Pre notifica significa semplicemente inviare email a quegli amministratori prima della data dell'uscita, per dire loro della vulnerabilità e come correggerla. Dovreste mandare la pre notifica solo a persone che voi confidate siano discrete con le informazioni. Cioè, la qualifica per ricevere la pre notifica è duplice: il destinatario deve far girare un grosso, importante server l'essere in pericolo sarebbe una questione seria, e e il destinatario dovrebbe essere noto per non essere uno che chiacchiera sul problema di sicurezza prima della data dell'uscita.
Mandate le email di prenotifica individualmente (una alla volta) ad ogni destinatario. Non mandate la lista intera dei destinatari subito, perché essi vedrebbero i nomi gli uni degli altri—nel senso che voi stareste avvisando ogni destinatario del fatto che ogni altro destinatario può avere una buca nella sicurezza nel suo server. Mandando a tutti loro l'email via CC non visibile (BCC) non è una buona soluzione nemmeno, perché alcuni admin proteggono la loro casella di posta con filtri antispam che o bloccano o riducono la priorità delle email BCC, dal momento che così tanto spam è inviato via BCC di questi tempi.
Qui c'è un esempio di email di pre notifica:
DA: Qui il Vostro Nome To: admin@large-famous-server.com Risposta a: Qui in Vosto Nome (non l'indirizzo della mailing list sulla sicurezza) Oggetto: Notifica confidenziale della vulnerabilità di Scanley. Questa email è una una notifica confidenziale di una allarme nel server di Scanley. Prego *non inoltrare* nessuna parte di questa email ad alcuno. Non c'è annuncio fino al 19 Maggio e noi gradiremmo tenere questa informazione bloccata fino ad allora. State ricevendo questa email perché (noi pensiamo) che voi facciate girare un server Scanley e vorreste averlo sistemato prima che il buco nella sicurezza venga reso pubblico il 19 Maggio. Riferimenti: =========== CAN-2004-1771: Sovraccarico dello stack di Scanley nelle query Vulnerabilità: ============== Il server può essere messo nelle condizioni di eseguire comandi arbitrari se il locale del server è mal configurato e il client invia una query mal formata. Serietà: ========= Molto seria. Può comportare l'arbitraria esecuzioni di codice sul server. Soluzioni: ============ Il mettere l'opzione del 'processo del linguaggio naturale' a 'off' in scanley.conf blocca questa vulnerabilità Patch: ====== La patch di sotto si applica a Scanley 3.0, 3.1, e 3.2. Una nuova release (la Scanley 3.2.1) verrà creata il o appena prima del 19 Maggio, in modo che sia disponibile nello stesso momento in cui questa vulnerabilità è resa pubblica. Potete sistemare adesso, o appunto aspettare la release pubblica. L'unica differenza fra la 3.2 e la 3.2.1 sarà questa patch. [...la patch va qui...]
Se avete un numero CAN, includetelo nella pre notifica (come mostrato sopra) anche le informazioni a sono ancora bloccate e quindi la pagina del MITRE non mostra nulla. L'inclusione del numero CAN mette il destinatario in grado di sapere con certezza che il bug del quale è stato pre notificato è lo stesso di cui ha sentito parlare attraverso i canali pubblici, così egli non ha a preoccuparsi se è necessaria qualche azione ulteriore o no, che è precisamente lo scopo dei numeri CAN/CVE.
L'ultimo passo nella gestione di un bug di sicurezza è quello di di distribuire la pubblicità della correzione. In un unico, comprensivo annuncio, dovreste descrivere il problema, dare il numero CAN/CVE, se esiste, descrivere come risolvere il problema, e come correggerlo permanentemente. Di solito “fix” significa aggiornare alla nuova versione del software, sebbene, a volte, significa applicare una patch, particolarmente se il software è fatto girare normalmente in una forma sorgente in qualche modo. Se create una nuova release, essa dovrebbe differire dalla release esistente esattamente per la patch sulla sicurezza. In questo modo gli admin prudenti possono aggiornare senza preoccuparsi su quale altra cosa essa stia avendo effetto; essi non dovrebbero nemmeno preoccuparsi dei futuri aggiornamenti perché la correzione della sicurezza ci sarà in tutte le release future come cosa naturale. (Dettagli sulle procedure della release sono discussi in sezione chiamata «Le Releases di Sicurezza» in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano.)
Se o meno la correzione pubblica comporta una nuova release, fate l'annuncio con circa la stessa priorità che in una nuova release: mandate una email alle mailing list annuncia del progetto, fate un nuovo comunicato stampa, aggiornate la voce di Freshmet, ecc.. Mentre non dovreste mai minimizzare l'esistenza di un bug di sicurezza al di fuori della relazione con la reputazione del progetto, potete impostare certamente il tono e la prominenza di un annuncio di sicurezza perché sia adatto alla severità del problema. Se il buco nella sicurezza è solo una rischiosità secondaria relativa alle informazioni, non un metodo di attacco che consente all'intero computer dell'utente di essere rilevato, allora esso non può giustificare tanta agitazione. Potete anche decidere di non distrarre la mailing list annuncia con esso. Dopotutto, se il progetto guarda al lupo ogni volta, gli utenti potrebbero finire col pensare che il software sia meno sicuro di quanto in realtà lo sia, e potrebbero anche non credervi quando avete da annunciare veramente un grosso problema. Vedere
http://cve.mitre.org/about/terminology.html per una buona introduzione al problema del giudizio sulla severità.
In generale, se siete incerti su come trattare un problema di sicurezza, trovate qualcuno esperto e parlategli di esso. Valutare e gestire le vulnerabilità è molto una abilità acquisita, ed è facile fare dei passi falsi le prime volte.