I loghi aiutano a riconoscere i programmi, ma da soli raccontano poco del lavoro svolto. Per questo nella pagina sulla sicurezza li affianco a un registro con severità, stato ed eventuale premio. Il quadro riportato qui è riferito alle evidenze del 20 settembre 2026: una fotografia datata, non un contatore sincronizzato in tempo reale con HackerOne.
Ho individuato vulnerabilità Critical e High e seguito segnalazioni attraverso conferma, risoluzione e, dove richiesto, retest. Il riepilogo comprende anche report in triage e un duplicato riconosciuto. Mantenerli distinti permette di valorizzare i risultati senza trasformarli tutti nello stesso esito.
I report risolti: Neon, Notion, Airtable, Spotify e Privy
Nel registro figurano un report Critical risolto per Neon, con premio di 5.000 dollari, e un High risolto per Notion, con premio di 2.000 dollari. Sono presenti anche un High risolto per Airtable da 750 dollari, un Medium risolto per Spotify da 700 dollari e due report risolti per Privy, rispettivamente Medium da 500 dollari e Low da 250 dollari.
Questi dati descrivono severità ed esito dei singoli report documentati. Non indicano che ogni sistema dell’azienda sia stato esaminato, né che io ne certifichi la sicurezza. Le aziende sono citate come programmi della mia ricerca indipendente, non come clienti di un incarico commerciale.
Il contributo del ricercatore comprende individuare il comportamento, costruire una prova comprensibile e rispondere alle richieste di chiarimento. Il metodo di scrittura del report spiega come collegare condizioni iniziali, comportamento osservato e impatto.
I risultati in triage vanno raccontati come tali
Il registro documenta report in stato Triaged per Twilio, Anthropic, Zabbix, Privy, Discourse e un programma privato. Per alcune di queste voci è già presente un premio; per altre non è riportato un importo. Un campo senza importo non va letto come un premio pari a zero: indica che il dato non è presente nel riepilogo pubblicato.
Lo stato Triaged va mantenuto distinto da Risolto. La valutazione può essere avanzata rispetto all’invio iniziale, ma da questa voce non si può dedurre che il problema sia già stato corretto. Il lettore deve poter vedere la distinzione accanto al nome del programma.
Quando una segnalazione cambia stato, l’aggiornamento deve riportare le nuove evidenze e una data. Un riepilogo storico conserva il significato che aveva alla data dichiarata, anche se il lavoro prosegue.
Perché compare un duplicato riconosciuto
Per Lightspark il registro indica un report High classificato come duplicato riconosciuto, con premio di 750 dollari. Lo presento con questa descrizione, senza conteggiarlo come nuova vulnerabilità unica risolta.
Il riconoscimento economico documenta un esito del lavoro; la classificazione conserva il contesto della segnalazione. Riportare entrambi permette di evitare due errori: cancellare un contributo riconosciuto oppure attribuirgli un significato diverso da quello del programma.
Lo stesso criterio vale per un eventuale premio di retest: riguarda una specifica attività di verifica e deve rimanere distinguibile dal premio del report originale.
Che cosa un lettore può verificare pubblicamente
Il mio profilo HackerOne è un riferimento pubblico per l’identità e per le informazioni che la piattaforma rende visibili. Il portfolio contiene anche sintesi documentate da evidenze riservate: non tutti i dettagli del dossier sono presenti nel profilo pubblico.
La pubblicabilità del meccanismo va verificata report per report. Severità, stato e premio non sostituiscono le condizioni di disclosure. Per questo gli esempi interattivi del sito sono dimostrativi e chiaramente separati dai risultati: rendono leggibile un criterio di sicurezza senza riprodurre un bug riservato.
Le linee guida HackerOne sulla divulgazione rimandano alle impostazioni e alle regole del singolo programma. Prima di condividere passaggi tecnici, allegati o dettagli identificativi, verifico il perimetro consentito.
Leggere il registro senza confondere le quantità
La fotografia del 20 settembre contiene 14 report: 6 risolti, 7 in triage e 1 duplicato riconosciuto. È il conteggio delle voci del registro pubblicato, non un tasso di successo su tutte le segnalazioni che abbia mai inviato. Per calcolare un tasso servirebbe un insieme completo, con periodo e criteri di inclusione dichiarati.
La documentazione HackerOne sugli stati dei report distingue Triaged, Resolved e Duplicate. Lo stato descrive il trattamento della segnalazione e può evolvere; il registro mantiene la data a cui si riferisce. Un premio già assegnato non permette di anticipare la conclusione del processo.
| Informazione | Che cosa sostiene | Che cosa non dimostra da sola |
|---|---|---|
| Critical o High | Severità attribuita a quel report | Compromissione di ogni prodotto dell’azienda |
| Risolto | Esito documentato della gestione di quel problema | Assenza di altre vulnerabilità |
| Triaged | Stato di valutazione riportato nel registro | Correzione completata |
| Duplicato riconosciuto | Contributo ricevuto e classificato dal programma | Nuova vulnerabilità unica |
| Premio | Riconoscimento economico registrato | Valore del danno o fatturato di consulenza |
Anche il numero dei programmi e quello dei report sono diversi: due report per la stessa azienda rimangono due segnalazioni, ma un solo programma. Il riepilogo permette di leggere questi livelli senza moltiplicare i clienti o le scoperte.
Dal risultato al criterio tecnico che un cliente può valutare
Il meccanismo riservato non è necessario per discutere come ragiona una verifica. Un cliente può chiedermi di definire il confine di accesso del proprio prodotto, scegliere una prova con dati fittizi e spiegare quale evidenza la confermerebbe o la smentirebbe. Il campione di report rende questo confronto leggibile senza pubblicare dettagli dei programmi.
Per un assistente sui documenti, per esempio, la domanda è se una fonte esclusa dai permessi possa entrare nella risposta. Per un CRM, se una riassegnazione abbia effetto anche su una schermata già aperta. Sono applicazioni progettuali del metodo, non descrizioni dei bug trovati in Neon, Notion o negli altri programmi.
La guida FIRST a CVSS aiuta inoltre a distinguere severità tecnica e valutazione del rischio nel contesto. Questa distinzione evita di leggere un’etichetta come una descrizione completa dell’impatto aziendale. Nel portfolio le classificazioni provengono dal registro, mentre la spiegazione del metodo resta controllabile negli esempi pubblici.
Come uso questa esperienza nei progetti software
La ricerca abitua a formulare domande precise: quale utente può compiere un’azione, su quale risorsa e in quale stato? Nel progetto di un CRM, di un assistente documentale o di uno strumento AI, queste domande aiutano a definire controlli e prove.
Per esempio, un assistente che recupera una fonte deve rispettare l’accesso del richiedente; un’integrazione che esegue un’operazione deve verificare i permessi nel componente che la applica. Il modello non dovrebbe essere l’unico punto in cui viene decisa l’autorizzazione.
Questo collegamento fra ricerca e sviluppo è il contributo che posso portare a una discussione tecnica. Un’attività di verifica su un prodotto richiede comunque un perimetro concordato, dati di prova e obiettivi chiari. Il registro seguente permette di leggere i risultati da cui parte questa esperienza.
Una lettura per approfondire
HackerOne
“Next steps may differ, depending on the individual program’s Disclosure Settings”
Vulnerability Disclosure Guidelines ↗
Le condizioni di divulgazione dipendono dal programma. Per questo un premio, lo stato del report e il permesso di pubblicarne il meccanismo devono essere letti separatamente.
Citazione breve in lingua originale. Fonte consultata il 24 settembre 2026.Fonti e contesto
Le letture sostengono i passaggi tecnici indicati. I fatti sul mio lavoro rimandano al caso del portfolio; i campioni inventati sono segnalati nel testo.
- Vulnerability Disclosure GuidelinesHackerOne
La citazione e la sua applicazione sono commentate nel riquadro precedente.
- Report StatesHackerOne
Significato degli stati della piattaforma; le voci del portfolio mantengono la propria data di riferimento.
- CVSS User GuideFIRST · CVSS v4.0
Come leggere il punteggio Base e distinguerlo dalla valutazione del rischio nel contesto dell’organizzazione.
Fonti ricontrollate il 24 settembre 2026. Per segnalare un errore o proporre un aggiornamento, scrivimi indicando il passaggio.
