Modelar as ameaças de um fluxo de desenvolvimento com IA

Escolha um cenário limitado

Comece por um fluxo de trabalho que as pessoas consigam compreender. Por exemplo, um agente lê uma issue, edita um repositório, executa testes e abre um pull request. Inclua os sistemas que tornam possíveis estas ações.

Liste os ativos importantes: código-fonte, informação de clientes, credenciais, artefactos de lançamento e disponibilidade do serviço. Identifique os responsáveis por eles. Depois, identifique as pessoas e os sistemas que podem ler ou alterar cada ativo.

A OWASP recomenda modelar o sistema, identificar ameaças, escolher respostas e validar o resultado. Use o método cedo e atualize-o à medida que o sistema muda. Orientações para modelação de ameaças.

Desenhe as fronteiras de confiança

Para o fluxo fictício de uma issue até ao PR, desenhe estas ligações:

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

Acrescente o fornecedor do modelo e o armazenamento de segredos. Assinale onde o conteúdo vem de uma fonte menos fiável. Assinale onde uma identidade ganha uma nova capacidade, como passar de ler uma issue a escrever ficheiros no repositório.

O diagrama da aplicação, por si só, não mostra todo o risco do desenvolvimento. Uma base de dados de produção pode ser privada enquanto uma tarefa de CI expõe uma credencial. Inclua ambientes temporários e acesso do suporte quando afetarem o cenário.

Escreva um percurso de falha concreto

Evite entradas como «a IA pode não ser segura». Indique um interveniente, uma ação, um ativo afetado e uma consequência. Inclua as condições necessárias para o cenário ocorrer.

Estes são exemplos, não uma lista completa de ameaças. Os seus dados, ferramentas e ambiente operacional determinam os cenários relevantes.

Escolha uma resposta com um responsável

Dê prioridade às consequências e à exposição plausível. Evite apresentar uma pontuação numérica como uma precisão que não tem. Registe a incerteza e as evidências que poderiam alterar a prioridade.

Uma resposta pode remover a capacidade arriscada, reduzir o seu âmbito, acrescentar um controlo ou aceitar um risco residual definido. A aceitação exige um responsável autorizado e uma justificação. Não deve ser uma conclusão do agente sem revisão.

Transforme a resposta escolhida em trabalho com uma condição de aceitação observável. «Melhorar a segurança do agente» é difícil de verificar. «A tarefa de teste não consegue ler o segredo de produção» define um limite que pode ser verificado.

Reveja após alterações relevantes

Um novo conector, percurso até ao modelo, ambiente ou permissão pode alterar o modelo de ameaças. Acrescente estas alterações às condições de revisão. Use também os incidentes e as avaliações falhadas para atualizar os pressupostos.

Experimente o exercício de revisão de riscos para alterar os dados, a autoridade, o público e as condições de recuperação de um cenário. O resultado sugere perguntas. Não substitui um modelo de ameaças específico do sistema nem autoriza o trabalho.