Modeleu les amenaces d'un flux de desenvolupament amb IA

Trieu un escenari limitat

Comenceu amb un flux de treball que es pugui entendre. Per exemple, un agent llegeix un tiquet, edita un repositori, executa proves i obre una pull request. Incloeu els sistemes que fan possibles aquestes accions.

Enumereu els actius importants: codi font, informació de clients, credencials, artefactes de publicació i disponibilitat del servei. Identifiqueu qui n’és responsable. Després identifiqueu les persones i els sistemes que poden llegir o modificar cada actiu.

OWASP recomana modelar el sistema, identificar amenaces, triar respostes i validar el resultat. Utilitzeu el mètode des del principi i actualitzeu-lo quan canviï el sistema. Directrius de modelatge d’amenaces.

Dibuixeu els límits de confiança

Per al flux fictici de tiquet a PR, dibuixeu aquestes connexions:

Issue → agent → repository → test runner → artifact store → deployment

Afegiu el proveïdor del model i el sistema d’emmagatzematge de secrets. Marqueu on el contingut prové d’una font menys fiable. Marqueu on una identitat obté una capacitat nova, com ara passar de llegir un tiquet a escriure fitxers al repositori.

El diagrama de l’aplicació per si sol no mostra tot el risc del desenvolupament. Una base de dades de producció pot ser privada mentre una tasca de CI exposa una credencial. Incloeu els entorns temporals i l’accés del suport quan afectin l’escenari.

Escriviu una via concreta de fallada

Eviteu entrades com ara «la IA podria ser insegura». Escriviu un actor, una acció, un actiu afectat i una conseqüència. Incloeu les condicions necessàries perquè es produeixi l’escenari.

Són exemples, no una llista completa d’amenaces. Les dades, les eines i l’entorn de funcionament determinen els escenaris rellevants.

Trieu una resposta amb un responsable

Prioritzeu les conseqüències i l’exposició plausible. Eviteu presentar una puntuació numèrica com si aportés una precisió que no teniu. Registreu la incertesa i les evidències que podrien canviar la prioritat.

Una resposta pot eliminar la capacitat arriscada, reduir-ne l’abast, afegir un control o acceptar un risc residual definit. L’acceptació necessita un responsable autoritzat i un motiu. No ha de ser una conclusió de l’agent sense revisar.

Convertiu la resposta triada en feina amb una condició d’acceptació comprovable. «Milloreu la seguretat de l’agent» és difícil de verificar. «La tasca de proves no pot llegir el secret de producció» defineix un límit que es pot comprovar.

Reviseu el model després de canvis importants

Un connector, una ruta cap al model, un entorn o un permís nous poden canviar el model d’amenaces. Afegiu aquests canvis a les condicions de revisió. Utilitzeu també els incidents i les avaluacions fallides per actualitzar les hipòtesis.

Proveu l’exercici de revisió de riscos per canviar les dades, les facultats, els destinataris i les condicions de recuperació d’un escenari. El resultat suggereix preguntes. No substitueix un model d’amenaces específic del sistema ni autoritza la feina.