Modelați amenințările unui flux de dezvoltare cu AI

Alegeți un scenariu limitat

Începeți cu un flux de lucru pe care oamenii îl pot înțelege. De exemplu, un agent citește un tichet, editează un depozit de cod, execută teste și deschide un pull request. Includeți sistemele care fac posibile aceste acțiuni.

Enumerați activele importante: codul sursă, informațiile despre clienți, credențialele, artefactele de lansare și disponibilitatea serviciului. Identificați cine răspunde de ele. Apoi identificați oamenii și sistemele care pot citi sau modifica fiecare activ.

OWASP recomandă modelarea sistemului, identificarea amenințărilor, alegerea răspunsurilor și validarea rezultatului. Folosiți metoda devreme și actualizați-o pe măsură ce sistemul se schimbă. Ghid de modelare a amenințărilor.

Desenați limitele de încredere

Pentru fluxul fictiv de la tichet la PR, desenați aceste conexiuni:

Tichet → agent → depozit de cod → executor de teste → stocare de artefacte → instalare în mediu

Adăugați furnizorul modelului și spațiul de stocare a secretelor. Marcați unde provine conținutul dintr-o sursă mai puțin de încredere. Marcați unde o identitate dobândește o capacitate nouă, precum trecerea de la citirea unui tichet la scrierea fișierelor din depozitul de cod.

Diagrama aplicației nu arată singură întregul risc al dezvoltării. O bază de date din producție poate fi privată, în timp ce un job CI expune o credențială. Includeți mediile temporare și accesul pentru suport când afectează scenariul.

Scrieți o cale concretă de eșec

Evitați formulări precum „AI ar putea fi nesigură”. Precizați un actor, o acțiune, un activ afectat și o consecință. Includeți condițiile necesare pentru apariția scenariului.

Acestea sunt exemple, nu o listă completă de amenințări. Datele, instrumentele și mediul de operare determină scenariile relevante.

Alegeți un răspuns cu responsabil desemnat

Prioritizați consecințele și expunerea plauzibilă. Nu prezentați un scor numeric ca o precizie pe care nu o aveți. Consemnați incertitudinea și dovezile care ar putea schimba prioritatea.

Un răspuns poate elimina capacitatea riscantă, îi poate reduce domeniul, poate adăuga un control sau poate accepta un risc rezidual definit. Acceptarea necesită un responsabil autorizat și un motiv. Nu trebuie să fie concluzia neverificată a unui agent.

Transformați răspunsul ales în lucru cu o condiție de acceptare observabilă. „Îmbunătățiți securitatea agentului” este greu de verificat. „Jobul de testare nu poate citi secretul de producție” definește o limită verificabilă.

Reevaluați după schimbări importante

Un conector nou, o rută către model, un mediu sau o permisiune poate schimba modelul amenințărilor. Adăugați aceste schimbări la condițiile de reevaluare. Folosiți și incidentele și evaluările eșuate pentru actualizarea ipotezelor.

Încercați exercițiul de evaluare a riscurilor pentru a schimba datele, autoritatea, publicul și condițiile de recuperare ale unui scenariu. Rezultatul sugerează întrebări. Nu înlocuiește modelul amenințărilor specific sistemului și nu autorizează lucrul.