Oficial de Segurança
Triagem de vulns e compliance.
O InfoSec Officer é a persona que mantém software e sistemas de IA defensáveis sob mudança. Em um SDLC AI-nativo, o InfoSec Officer opera um agente Threat Triager, quatro slash prompts e um catálogo validado de MCPs ancorado no GitHub Advanced Security e Microsoft Defender for Cloud — não um backlog de checklists em PDF.
Resumo executivo
O InfoSec Officer é dono da postura de segurança do pipeline de entrega e dos produtos que ele entrega. Em um SDLC AI-nativo, ele opera um agente Threat Triager com quatro slash prompts (/vuln-triage, /sbom-scan, /threat-model, /incident-security), instruções com escopo para caminhos sensíveis à segurança e um catálogo validado de MCPs que alcança GitHub Advanced Security, Dependabot, CodeQL, Secret Scanning, Push Protection, Microsoft Defender for Cloud, Microsoft Sentinel, Microsoft Purview, Entra ID e Azure Key Vault.
As entregas primárias são filas de vulnerabilidades triadas com SLAs, bills of materials de software assinados, modelos de ameaça anexados a cada decisão de arquitetura e respostas a incidentes coordenadas através do Sentinel. O InfoSec Officer transforma segurança de um bloqueador de release em uma camada contínua, quase toda automática, produtora de evidências.
Segurança é uma propriedade do pipeline, não um evento de auditoria. O InfoSec Officer conecta políticas, detecções e remediações às ferramentas do dia a dia para que, quando um PR chega ao merge, a maioria das perguntas já esteja respondida.
Papel e responsabilidades
Pense no InfoSec Officer como o marechal de incêndio de uma cidade. Ele não combate cada incêndio, mas escreve o código de construção, certifica inspeções, conduz simulações e coordena a resposta quando um incêndio real acontece. Em um SDLC AI-nativo, o InfoSec Officer enforça o código e orquestra a resposta através de superfícies do GitHub, Azure e Microsoft 365.
Responsabilidades primárias:
- Triar alertas de vulnerabilidade do GitHub Advanced Security, Dependabot e Defender for Cloud
- Manter o SBOM (software bill of materials) por serviço com proveniência assinada
- Criar modelos de ameaça para cada nova arquitetura; atualizar quando a arquitetura mudar
- Coordenar resposta a incidentes de segurança através do Microsoft Sentinel e issues do GitHub
- Enforçar Push Protection, Secret Scanning, CodeQL e políticas do Dependabot em cada repositório
- Integrar segurança de IA (filtros de conteúdo, redação de PII) com os pipelines do ML AI Engineer
- Operar o agente Threat Triager e os prompts
/vuln-triage,/sbom-scan,/threat-model,/incident-security - Gerenciar higiene de identidade e segredos via Microsoft Entra ID e Azure Key Vault
Jobs to be done
- Como InfoSec Officer, eu quero cada alerta do Dependabot ou CodeQL triado dentro do SLA, para que janelas de exposição sejam minimizadas.
- Como InfoSec Officer, eu quero um SBOM assinado publicado a cada release, para que perguntas sobre supply chain tenham respostas imediatas.
- Como InfoSec Officer, eu quero modelos de ameaça anexados a PRs de arquitetura, para que mitigações estejam em vigor antes do código aterrissar.
- Como InfoSec Officer, eu quero Push Protection e Secret Scanning habilitados por padrão, para que credenciais nunca alcancem uma branch remota.
- Como InfoSec Officer, eu quero achados do Defender for Cloud convertidos em issues do GitHub automaticamente, para que o trabalho de remediação seja visível no mesmo backlog que features.
- Como InfoSec Officer, eu quero alertas do Sentinel enriquecidos com contexto de repositório, para que a triagem seja rápida e precisa.
- Como InfoSec Officer, eu quero timelines de incidente produzidas automaticamente a partir de chat, commits e alertas, para que revisões pós-incidente sejam baseadas em fatos.
- Como InfoSec Officer, eu quero todos os segredos armazenados no Azure Key Vault com managed identity, para que nenhuma credencial de longa duração fique no CI.
Dores antes do AI-nativo
- Fadiga de alertas. Milhares de alertas do Dependabot e CodeQL sem triagem, então problemas reais se escondem no ruído.
- SBOMs como PDFs. Bills of materials produzidos uma vez, nunca assinados, nunca consumidos no CI.
- Modelos de ameaça em um cofre. Modelos de ameaça escritos no kickoff do projeto, nunca revisitados; descrevem um sistema que não existe mais.
- Caos de incidentes. Incidentes gerenciados em cinco ferramentas; a timeline é recuperada depois entrevistando pessoas.
- Credenciais no CI. Chaves de API em secrets do GitHub Actions, rotacionadas em feriados, armazenadas em YAML plano por acidente.
- Políticas como slides. Políticas de segurança existem no SharePoint, não como configuração enforçada.
- Segurança de IA em silo. Controles de segurança de IA pertencendo a outro time, não integrados na mesma revisão.
Fluxo diário AI-nativo
O InfoSec Officer trabalha a partir do Visual Studio Code e do terminal com Claude Code, orquestrando o Threat Triager e enforçando hooks em cada repositório.
Setup da manhã
- Abra os dashboards do Microsoft Defender for Cloud, Microsoft Sentinel e GitHub Advanced Security.
- Rode
/vuln-triage --since=yesterdaypara agrupar novos alertas por serviço e severidade. - Revise bypasses de Push Protection e notificações de Secret Scanning da noite anterior.
- Verifique logs de acesso do Azure Key Vault para anomalias; confirme que o Conditional Access do Entra ID está saudável.
- Poste o resumo de standup de segurança no Microsoft Teams com incidentes abertos e relógios de SLA.
Execução no meio do dia
- Para cada PR de arquitetura, invoque
/threat-model; o Threat Triager redige achados e mitigações STRIDE, depois abre issues de rastreamento. - Para cada cluster de vulnerabilidade, triar com
/vuln-triage: atribuir dono, severidade, janela de correção, controles compensatórios. - Rode
/sbom-scancomo parte do CI; bloquear release em componentes não assinados ou violando políticas. - Coordene o canal ativo de incidente no Microsoft Teams;
/incident-securitymantém a timeline atualizada.
Revisão no fim da tarde
- Verifique recomendações do Defender for Cloud e registre exceções de Azure Policy quando justificadas.
- Revise adições de queries CodeQL e faça merge de queries customizadas aprovadas no pack compartilhado.
- Atualize o registro de riscos trimestral no repo; publique o score de postura atualizado no Microsoft Loop.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
threat-triager | .github/agents/threat-triager.agent.md | Tria vulnerabilidades, roda scans de SBOM, redige modelos de ameaça, coordena incidentes |
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/vuln-triage | .github/prompts/vuln-triage.prompt.md | Agrupar alertas, atribuir donos, definir SLA, propor remediações |
/sbom-scan | .github/prompts/sbom-scan.prompt.md | Gerar, assinar e verificar o SBOM para um release |
/threat-model | .github/prompts/threat-model.prompt.md | Redigir análise STRIDE e tarefas de mitigação em um PR de arquitetura |
/incident-security | .github/prompts/incident-security.prompt.md | Manter timeline de incidente em tempo real a partir do Sentinel, Teams e GitHub |
Instruções com escopo
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
.github/workflows/**/*.yml | .github/instructions/actions-security.instructions.md | OIDC para Azure, sem segredos de longa duração, actions com SHA fixo |
infra/**/*.bicep | .github/instructions/infra-security.instructions.md | Referências ao Key Vault, managed identity, isolamento de rede |
src/**/auth/** | .github/instructions/auth.instructions.md | Padrões do Entra ID, tratamento de tokens, mínimo privilégio |
prompts/**/*.prompt.md | .github/instructions/ai-safety.instructions.md | Guardrails de segurança de conteúdo e redação de PII |
Hooks
pre-commit: Secret Scanning, push protection, verificação de política de dependênciaspre-push: queries rápidas do CodeQL em arquivos alteradospost-merge: triagem do Dependabot, atualização de SBOM, sincronização com Defender for Cloudpre-release: gate de assinatura de SBOM e presença de modelo de ameaçaon-incident: criar um registro de incidente no Sentinel e fixar o canal do Microsoft Teams
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| GitHub MCP Server | Ler alertas do Advanced Security, Dependabot, CodeQL, gerenciar issues e PRs | GitHub |
| Azure MCP Server | Operar Defender for Cloud, Sentinel, Key Vault, Entra ID, Azure Policy | Microsoft |
| Microsoft Learn Docs MCP | Resolver orientação de segurança atualizada em stacks Microsoft | Microsoft |
| Azure DevOps MCP Server | Rastrear work items de remediação quando o time usa Azure DevOps | Microsoft |
| Playwright MCP | Validar fluxos de UX de segurança (SSO, MFA, consentimento) ponta a ponta | Microsoft |
Exemplos reais
Exemplo 1: triagem de zero-day em menos de uma hora
Um CVE atinge uma dependência amplamente usada. /vuln-triage identifica 23 repos expostos e mapeia cada um ao seu dono de serviço. O Threat Triager abre issues com PRs de correção já rascunhados pelo Copilot. Em menos de uma hora, 19 PRs estão merged; os 4 restantes recebem controles compensatórios documentados. Defender for Cloud confirma que a exposição foi fechada.
Exemplo 2: modelo de ameaça direciona mudança de design
Um PR de arquitetura propõe um novo endpoint que aceita URLs assinadas. /threat-model sinaliza um risco de replay e sugere um nonce mais expiração curta. O Software Architect atualiza o design antes do merge do PR; as tarefas de mitigação são linkadas e fechadas automaticamente quando a implementação aterrissa.
Exemplo 3: SBOM assinado bloqueia um release
O workflow de release invoca /sbom-scan. O pipeline detecta uma dependência transitiva não assinada e bloqueia o release. O InfoSec Officer confirma que o componente não está sob exploração ativa, registra uma exceção temporária no Azure Policy, e o release prossegue com trilha de auditoria completa.
Anti-padrões
- Triagem em planilha. Triagem fora do GitHub perde contexto e rastreamento de SLA; fique em issues.
- Segredos de longa duração. Qualquer segredo com mais de 90 dias é uma responsabilidade; use managed identity e referências ao Key Vault.
- Modelos de ameaça únicos. Modelos devem evoluir com o sistema; vincule-os a PRs de arquitetura.
- Ignorar bypasses de Push Protection. Cada bypass é revisado no mesmo dia, não no final do trimestre.
- Silos de segurança. Segurança de IA pertence ao mesmo pipeline que segurança de aplicação, com os mesmos revisores.
- Política como PDF. Políticas que não são configurações do Azure Policy ou GitHub Advanced Security não existem.
- Incidentes sem timelines. Todo incidente produz uma timeline reproduzível gerada a partir de ferramentas, não de memória.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agêntico) | Fonte |
|---|---|---|---|
| Tempo médio para triar CVE | 4 dias | < 4 horas | Histórico de /vuln-triage |
| Cobertura de SBOM | 40 por cento | 100 por cento dos releases | GitHub Actions |
| Cobertura de modelo de ameaça em PRs de arquitetura | 20 por cento | 100 por cento | Execuções de /threat-model |
| Segredos detectados no push | 12 por mês | 0 | Logs de Push Protection |
| Achados altos do Defender for Cloud > 7 dias | 30 | < 5 | Defender for Cloud |
| Incidentes do Sentinel com timeline automatizada | 10 por cento | 100 por cento | Workbooks do Sentinel |
| Rotação de credenciais do Key Vault em dia | 60 por cento | 100 por cento | Auditoria do Entra ID |
Maturidade em quatro níveis
- L1 Manual: Advisories rastreados em planilha, sem SBOM, modelos de ameaça apenas no kickoff.
- L2 Assistido: Dependabot e Secret Scanning habilitados mas sem triagem; dashboards do Defender for Cloud acompanhados ad hoc.
- L3 Aumentado: Agente Threat Triager, quatro slash prompts, instruções com escopo, pack customizado do CodeQL, integração com Sentinel.
- L4 Autônomo: Triagem automatizada com enforcement de SLA, SBOMs assinados bloqueando release, modelos de ameaça anexados a cada PR de arquitetura, incidentes com timelines auto-geradas.
Integração com outras personas
- Do Software Architect: diagramas de design e ADRs alimentando
/threat-model. - Para o Developer: issues de remediação com rascunhos de correção linkados.
- Com o ML AI Engineer: configuração de segurança de IA, filtros de segurança de conteúdo, redação de PII.
- Com o SRE: runbooks compartilhados do Sentinel e resposta a incidentes.
- Com o Compliance Auditor: SBOMs, modelos de ameaça e pacotes de evidência de grau auditável.
- Do Data Engineer: classificações do Purview direcionando controles de tratamento de dados.
- Com o DBA: revisões de acesso a banco de dados e verificações de mínimo privilégio.
Glossário
- SBOM: software bill of materials — lista assinada de cada componente em um release.
- STRIDE: taxonomia de modelagem de ameaças (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
- Push Protection: feature do GitHub Advanced Security que bloqueia segredos de alcançar branches remotas.
- Managed identity: identidade do Microsoft Entra ID usada por workloads, eliminando credenciais armazenadas.
- Dependabot: serviço do GitHub que abre PRs para dependências vulneráveis.
- Incidente do Sentinel: um objeto de caso do Microsoft Sentinel que coleta alertas, entidades e timeline.
- Controle compensatório: uma mitigação alternativa quando a correção preferida ainda não é viável.
Referências
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection
- Microsoft Defender for Cloud — proteção de postura e workloads
- Microsoft Sentinel — SIEM e SOAR
- Azure Key Vault — gerenciamento de segredos, chaves e certificados
- Microsoft Entra ID — gerenciamento de identidade e acesso
- Azure Policy — enforcement de política como código
- Microsoft Purview — governança e sensibilidade de dados
- GitHub Actions — orquestração de CI e deploy em todo o stack
- Microsoft Learn Docs MCP — recuperação de documentação first-party no momento da implementação
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection