Per come la descrivi, hai scoperto la vulnerabilità più tramite test intuitivi, piuttosto che mediante test basati su casi di test. Questo è un modo molto buono e valido di test. I clienti finali utilizzano sicuramente il software senza alcun requisito o documento di specifica del test.

Ora, per come la vedo io, non "comunichi al team di sviluppo" nulla. Devi solo compilare la segnalazione del problema (bug) nel sistema di gestione dei problemi e notificare al project manager che è stato rilevato un problema ad alto impatto. È nell'autorità e nella responsabilità del project manager decidere cosa fare con il problema: risolvere, non risolvere, ritardare la risoluzione.

Per essere sicuri di essere coperti in caso di problemi futuri, se il bug non è stato risolto, assicurati di avere una comunicazione scritta con le persone coinvolte (utilizzando strumenti dedicati, come il sistema di gestione dei problemi; o anche la posta elettronica).

non è esattamente nell'ambito della user story originale

La sicurezza del sito e la sicurezza dei dati sono le prime "user story" del progetto, per come la vedo io. L '"utente" è il business, che preferisce restare nel mercato, senza scandali per la fuga di dati. Tutto il resto viene dopo. E le parole esatte non contano.

ma poiché la sicurezza non è stata coinvolta abbastanza presto nella fase di raccolta dei requisiti / progettazione della storia prima dello sviluppo, questo requisito non è stato chiaramente catturato nella storia dell'utente.

Quel pensiero è una enorme bandiera rossa. Sono uno sviluppatore e la sicurezza di base è implicita quando consegno un prodotto. Non dovrebbe aver bisogno di essere in una user story. Se compro un'auto, non scelgo marca, modello e raggio esplosivo e se non dico nulla di quest'ultima il produttore può scegliere quello che gli piace di più. La mia macchina non deve esplodere, punto. Questo è implicito quando dico che voglio comprare un'auto.

Se non disponi di linee guida di sicurezza di base alle quali tutti i tuoi sviluppatori aderiscono senza doverle pronunciare ogni volta, ne hai bisogno. Ieri. Ma ancora una volta ... una sicurezza difettosa è un prodotto difettoso, proprio come gli arresti anomali casuali o la lentezza inaccettabile. Gli sviluppatori dovrebbero saperlo. Non è un ripensamento, è il loro lavoro. Uno sviluppatore che non conosce la sicurezza di base non dovrebbe sviluppare software, dovrebbe imparare a sviluppare software.

Quello che dovresti fare è prima parlare con lo sviluppatore nel corridoio. Dì loro cosa hai trovato, chiedi loro di cambiarlo. Chiedete loro come vorrebbero che questo requisito venisse acquisito in futuro. Chiedi loro se hanno bisogno di aiuto per discutere con chi è responsabile delle tempistiche perché questo deve essere risolto prima. Gli sviluppatori probabilmente conoscono i dettagli e sanno quanto tempo ci vorrà. Sanno se questo è effettivamente un problema critico o forse solo un errore di configurazione nel tuo ambiente QA. Quando sai cosa è necessario fare, invia un ticket con tutto ciò che hai concordato e informa la direzione del progetto. Questo dovrebbe aiutare lo sviluppatore e te stesso a evitare inutili giochi sussurrati cinesi in cui tutti nel progetto parlano del ticket, tranne le due persone che potrebbero effettivamente risolvere il problema.

Se gli sviluppatori non si conformano, segnala un bug critico nel tuo sistema, proprio come faresti se notassi qualcosa di molto sbagliato che non è stato specificato nei requisiti. Sono sicuro che ci sono pulsanti "Annulla" e "Indietro" e nessuno ha specificato che dovrebbero effettivamente tornare indietro o annullare invece di mandare in crash l'applicazione. Quindi non è che non si possa avere un bug senza i requisiti specificati.

Voglio generalizzare un po 'qui e allontanarmi dalla considerazione specifica della sicurezza.

Quando le aziende lavorano, non lo fanno nel vuoto. L'azienda utilizza la cultura dei propri dipendenti. Utilizza lezioni di prodotti e clienti precedenti. Utilizza le migliori pratiche dei settori in cui opera.

In quanto tale, direi che ci sono storie di utenti implicite che sono legate all'etica di un'azienda. Tali storie utente implicite esistono (e dovrebbero esistere) nella mente di ogni sviluppatore.

È salutare per uno sviluppatore dire: "Sto soddisfacendo questo caso d'uso ... ma non lo facciamo di solito faccio le cose in questo modo. È meglio che verifichi con il PM che questo è ciò che si intende. " Questo è simile alla situazione in cui due casi d'uso sono in conflitto.

Seguire pratiche di sviluppo irreggimentate presuppone che le persone non commettano errori. Le persone commettono errori, come dimenticare di includere requisiti importanti. Vale la pena notare che seguire pratiche di sviluppo irreggimentate può anche aiutare a proteggersi dagli errori. Ma non ti muovi da una scogliera perché è quello che dice la mappa di fare.

Posso pensare a diversi requisiti impliciti che spesso esistono, di solito senza essere esplicitamente specificati. Spesso il prodotto deve:

• Rispettare i requisiti legali
• Rispettare accordi / contratti di licenza
• Non essere terribilmente inefficace
• Non screditare l'azienda
• Non comportarsi in modo da mettere in pericolo la vita

Potrebbero esserci situazioni in cui alcune delle precedenti sono deliberatamente violate, ma ciò deve accadere per decisione deliberata, non dimenticata user story.

Per quanto riguarda ciò che dovresti fare. File un ticket.

questo requisito non è stato chiaramente colto nella User story.

Potrebbero essere trapelati dati sensibili dei clienti.

La parola chiave nella User story è utente .

I punti espliciti scritti nella storia, tipicamente nuove funzionalità, sono semplicemente un sottoinsieme di ciò che è richiesto per la spedizione. È anche implicitamente richiesto per mantenere l ' intero stato corrente delle cose che l'utente desidera. Questo ovviamente include il non far trapelare i propri dati sensibili.

Nessuna user story può essere spedita se introduce qualcosa di attivamente dannoso per l'utente, punto. Non importa quale altra nuova funzionalità abiliti .

Detto questo, consigli pragmatici su cosa fare qui:

1. Vai direttamente al team di sviluppo, scopri chi sta lavorando alla storia e racconta loro la vulnerabilità - l'obiettivo è accertare se capiscono chiaramente che la storia non può essere spedita finché non viene affrontata. In tal caso, lavoro fatto.

—— OR ——

2. Se che non funziona, forse a causa di una disfunzione all'interno del team di sviluppo e / o dell'implementazione da parte dell'organizzazione del suo processo agile, quindi funziona con la disfunzione piuttosto che contro di essa.

   Ogni Il processo agile ha i suoi "portelli di fuga", essenzialmente per sovvertire il processo per cose che deve essere assolutamente fatto adesso . In alcuni è qualcuno con un determinato titolo di lavoro che ti dà un colpetto sulla spalla, altri è un bug ticket P0, ecc. Scopri cosa c'è nella tua organizzazione e fallo. Se non hai l'autorità, non hai altra scelta che intensificare.

Pensa all'utente! La tua organizzazione ti ringrazierò (eventualmente!)

Non esiste una soluzione generale.

A breve termine

• Parla con il project manager, il team di sviluppo o lo scrum master. Dovresti affrontare le tue preoccupazioni e chiedere loro di risolverle prima del rilascio. Se non funziona, dovresti coinvolgere il tuo capo, forse anche il suo capo. Dipende dalla tua relazione.
• Potresti aprire un bug. Se la gravità è sufficientemente elevata, potrebbe non essere consentito inviare la versione del software. Ma questo potrebbe far arrabbiare gli sviluppatori.

Più avanti lungo la strada:

• Dovresti scrivere / richiedere storie relative alla sicurezza.
• Chiedere al progetto di modificare la definizione di done. Molti test di sicurezza possono essere l'integrazione in pipeline di test automatizzati / CI / CD. Una storia è finita solo quando tutti i test, inclusi i test di sicurezza, sono stati superati.

Il tuo ruolo è avvisare in caso di problemi di sicurezza o potenziali problemi di sicurezza. Possono essere scoperti durante la progettazione (errori di architettura, ad esempio) o durante lo sviluppo (SDLC errato o inesistente), o versioni successive . Ovviamente ci sono momenti migliori e peggiori per scoprire una vulnerabilità, ma è sempre meglio scoprirla in primo luogo (prima che qualcuno la scopra per te).

Dato che il tuo ruolo è di allertare, dovresti rivolgersi alle persone che prendono decisioni su questo prodotto. In definitiva questo potrebbe essere il CEO.

Avendo tutte le informazioni fornite (tipo di problema, impatto probabile o possibile, idealmente una probabilità (ma questo non esiste nel mondo reale)), loro prenderà una decisione , sulla base di tale analisi del rischio.

Possono accettarla, correggerla o avere un'assicurazione. Questo non è un tuo problema, però. Il tuo ruolo è di allertare (e fornire sostanza per prendere una decisione).

A seconda dell'azienda, potresti avere il potere di prendere tale decisione (= un rifiuto per il rilascio), ma dal tuo descrizione sembra che non sia così.

Il documento delle storie degli utenti Requisiti funzionali : questo è ciò che il sistema deve fare, di quali funzioni ha bisogno, cosa gli utenti finali si aspettano di essere in grado di ottenere ecc.

C'è un'altra serie di requisiti su cose di base a cui gli utenti non pensano fino a quando qualcosa non va storto, questi sono chiamati Requisiti non funzionali e coprono cose come il sistema è sicuro, è stabile, è eseguito il backup, è facile da mantenere ecc.

I requisiti non funzionali non richiedono storie degli utenti, ma devono essere soddisfatti prima che un sistema possa essere pubblicato. È meglio se questi vengono documentati e compresi in anticipo, ma hai ancora il diritto di segnalare che questo sistema non ha superato un controllo critico e deve essere corretto prima di passare alla vita.

Ha un valore in dollari ($$$$) per non conformità, errore, rilascio o sfruttamento dei dati. Se è "importante", darà un valore commerciale adeguato.

Sebbene le segnalazioni di bug e i requisiti siano una parte normale del processo di sviluppo, nel grande schema delle cose non sono "così importanti". Cioè, molti requisiti vengono ignorati, alcuni hanno uno slittamento della missione. I bug sono classificati per mancanza. Avrai visto tutto questo accadere a problemi di altre persone.

Se questo è un esercizio da spuntare, non ci riuscirai. Se identifichi il valore e il rischio aziendale, puoi lavorare con la gestione del rischio e il processo di pianificazione delle emergenze per ottenere vantaggi reali.

Se hai il controllo sui requisiti, aggiungi semplicemente queste correzioni di bug ai requisiti. Tieni presente che potrebbero sorgere problemi di priorità.

Se hai autorità sugli sviluppatori, ordina loro di lavorare su questo (in termini professionali, ovviamente).

Se hai il controllo durante il rilascio, aggiungi semplicemente questo requisito al rilascio.

Se non hai controllo sui requisiti, nessuna autorità sugli sviluppatori e non puoi bloccare il rilascio, allora non puoi arrivare agli sviluppatori qual è il loro lavoro. Non è solo il tuo posto. Quello che devi fare è fare in modo che risolva questo problema, parlando con le persone che possono effettivamente dire agli sviluppatori qual è il loro lavoro.

Devi bloccare questo rilascio, quindi parla con il responsabile del rilascio o chiunque altro controlla i rilasci. È necessario aggiungerlo ai requisiti, quindi parla con il proprietario del prodotto, il responsabile del prodotto, il responsabile del progetto o chiunque definisca i requisiti. Devi rendere questo lavoro una priorità, quindi parla con il product owner, il product manager, il project manager o chiunque dia la priorità ai requisiti.

Inoltre, suggerisco di comunicare agli sviluppatori in modo diretto o indiretto ma molto chiaro il modo in cui sei (o qualcuno del tuo team è) disponibile per qualsiasi domanda sulla sicurezza, sia per questi problemi che per problemi futuri. Tieni presente che gli sviluppatori sicuramente non conosceranno la sicurezza quanto il leader della sicurezza te stesso e potrebbero anche non sapere cosa sia OWASP. La formazione sulla sicurezza potrebbe essere un'ottima idea per il futuro.