Modella le minacce di un flusso di sviluppo con l'AI

Scegli uno scenario circoscritto

Parti da un flusso comprensibile. Per esempio, un agente legge un’issue, modifica un repository, esegue test e apre una pull request. Includi i sistemi che rendono possibili queste azioni.

Elenca le risorse importanti: codice sorgente, informazioni dei clienti, credenziali, artefatti di rilascio e disponibilità del servizio. Individuane i responsabili. Poi individua persone e sistemi che possono leggere o modificare ogni risorsa.

OWASP raccomanda di modellare il sistema, individuare minacce, scegliere risposte e validare il risultato. Usa il metodo fin dall’inizio e aggiornalo mentre il sistema cambia. Indicazioni sul threat modeling.

Disegna i confini di fiducia

Per il flusso fittizio dall’issue alla PR, disegna questi collegamenti:

Issue → agente → repository → esecutore dei test → archivio artefatti → deployment

Aggiungi il fornitore del modello e l’archivio dei segreti. Segna dove i contenuti arrivano da una fonte meno attendibile. Segna dove un’identità ottiene una nuova capacità, come passare dalla lettura di un’issue alla scrittura dei file del repository.

Il solo diagramma applicativo non mostra l’intero rischio di sviluppo. Un database di produzione può essere privato mentre un job CI espone una credenziale. Includi ambienti temporanei e accesso dell’assistenza quando influiscono sullo scenario.

Scrivi un percorso concreto di guasto

Evita voci come «l’AI potrebbe essere insicura». Scrivi soggetto, azione, risorsa interessata e conseguenza. Includi le condizioni necessarie perché lo scenario si verifichi.

Sono esempi, non un elenco completo delle minacce. Dati, strumenti e ambiente operativo determinano gli scenari pertinenti.

Scegli una risposta con un responsabile

Dai priorità alle conseguenze e all’esposizione credibile. Evita di presentare un punteggio numerico come una precisione che non hai. Registra l’incertezza e le prove che potrebbero cambiare la priorità.

Una risposta può rimuovere la capacità rischiosa, ridurne l’ambito, aggiungere un controllo o accettare un rischio residuo definito. L’accettazione richiede un responsabile autorizzato e una motivazione. Non deve essere una conclusione dell’agente non revisionata.

Trasforma la risposta scelta in lavoro con una condizione di accettazione osservabile. «Migliorare la sicurezza degli agenti» è difficile da verificare. «Il job di test non può leggere il segreto di produzione» definisce un confine verificabile.

Revisiona dopo modifiche rilevanti

Un nuovo connettore, percorso verso il modello, ambiente o permesso può cambiare il modello delle minacce. Aggiungi queste modifiche alle condizioni di revisione. Usa anche incidenti e valutazioni fallite per aggiornare le ipotesi.

Prova l’esercizio di analisi del rischio per cambiare dati, autorità, pubblico e condizioni di recupero di uno scenario. Il risultato suggerisce domande. Non sostituisce un modello di minacce specifico del sistema né autorizza il lavoro.