SkillEngenhariaSíntese

Extracting Security Requirements

Converte contexto de produto, risco e compliance em requisitos de segurança verificáveis.

Em:Secure Feature Threat Modeling
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo

Em uma frase.

Derivar requisitos de segurança claros a partir do contexto da mudança. O resultado deve ser verificável em review, teste, monitoramento ou evidência de configuração.

Aplicação

Quando
faz sentido.

Usar
  • Antes de implementar feature que manipula dados sensíveis.
  • Ao expor endpoint, webhook, integração externa ou job com privilégio elevado.
  • Quando há autenticação, autorização, sessão, token, segredo, auditoria ou criptografia envolvida.
  • Quando um requisito de compliance precisa virar critério técnico.
Prompt

Instruções
para a IA.

Passo 1 - Identificar o objetivo de proteção

Para cada parte da feature, responda:

- Que dado ou capacidade precisa ser protegida?

- Quem pode acessar? - Quem não pode acessar? - O que precisa ser auditável? - O que precisa permanecer disponível?

Passo 2 - Classificar domínios de segurança

Mapeie requisitos nos domínios aplicáveis:

- Autenticação.

- Autorização. - Proteção de dados. - Validação de entrada. - Logging e auditoria. - Gestão de sessão/token. - Segredos e credenciais. - Disponibilidade e abuso. - Privacidade e retenção.

Passo 3 - Escrever requisitos testáveis

Cada requisito deve conter:

- Identificador curto.

- Descrição objetiva. - Racional de risco. - Prioridade. - Critério de aceitação. - Referência a ameaça, dado, ator ou obrigação.

Evite requisito como "ser seguro". Prefira "o endpoint X deve negar acesso a recursos cujo `owner_id` não pertença ao usuário autenticado".

### Passo 4 - Separar requisito de controle

Requisito diz o que deve ser verdade. Controle diz como será implementado. Não prenda a solução cedo demais quando houver alternativas técnicas.
Constelação

Onde
ela vive.

Workflows que usam
Bundles que incluem