Auditoria de Segurança Pré-Produção
Produza uma avaliação de segurança útil para a tomada de decisões do lançamento especificado. Explique o que foi examinado, o que as evidências suportam, o que permanece desconhecido e como remediar e verificar cada problema. Use o inglês como padrão para o relatório, a menos que o usuário solicite outro idioma.
Utilize apenas as capacidades disponíveis e autorizadas do host atual. Resolva referências agrupadas relativas a esta pasta de skill. Acesso a arquivos locais, shell/scanners, navegação, conectores e delegação não são assumidos. Quando uma capacidade não estiver disponível, revise as evidências fornecidas e registre lacunas U-###. Se o destino do sistema de arquivos solicitado não puder ser gravado, forneça o relatório como um artefato para download ou texto Markdown e declare essa limitação de entrega.
Calibrar antes de selecionar verificações
- Identifique a avaliação solicitada, o lançamento ou commit alvo, o destino de implantação, as evidências disponíveis e a autorização existente. Preserve o escopo do usuário e respostas anteriores.
- Leia as perguntas de escopo. Resolva Q-00 antes de inspecionar o conteúdo do repositório, se a revisão do repositório ainda não tiver sido solicitada ou claramente incluída. Uma solicitação para auditar o repositório ou código já a responde; não pergunte novamente. Se o usuário excluir a revisão do repositório, trabalhe a partir dos documentos/configuração/evidências de tempo de execução selecionados e registre o limite.
- Inspecione apenas os metadados e a documentação do projeto no escopo, sem executar o código do projeto. Registre os fatos separadamente de inferências e declarações do usuário. Faça um pequeno lote de perguntas materiais restantes e ramifique por produto, exposição, hospedagem, identidade, dados e acesso disponível. Continue o trabalho autorizado de forma independente enquanto espera; o silêncio não responde a uma escolha de escopo não resolvida.
- Registre um instantâneo do escopo, módulos selecionados, IDs de controle aplicáveis, verificações permitidas e perguntas não resolvidas no relatório. Atualize este instantâneo quando as respostas alterarem o escopo.
Roteamento para módulos relevantes
Sempre use o método de auditoria e descobertas e prioridades. Carregue os detalhes do módulo apenas quando sua superfície estiver presente ou precisar de investigação. Não carregue cada módulo simplesmente porque ele existe.
Use o mapa de cobertura de 35 domínios para relacionar as áreas de avaliação originais aos IDs de controle. Quando verificações assistidas por ferramentas estiverem no escopo, siga os procedimentos de execução do scanner para Gitleaks, Semgrep CE, Trivy e ZAP; selecione ferramentas por evidência e disponibilidade, e registre execuções reais, erros e omissões. Uma solicitação apenas manual não ativa scanners.
Para inventários de dependências, reutilize primeiro um SBOM correspondente ao alvo, depois use Trivy se a geração for necessária e permitida. Gráficos de pacotes nativos, Syft e análise de importação de código-fonte são suplementos opcionais; siga o procedimento de inventário na mesma referência. Mantenha as relações de pacotes separadas das importações de código e das relações de tempo de execução.
| Superfície | Módulo | Orientação de roteamento |
|---|---|---|
| Toda avaliação | Arquitetura | Estabeleça ativos, limites de confiança, ações críticas, exposição e responsabilidade. |
| Contas, permissões, locatários, sessões ou identidades de serviço | Identidade e acesso | Inclua identidades de infraestrutura mesmo que o produto não tenha login. |
| Interfaces web, APIs, workers, arquivos ou integrações | Aplicação e API | Selecione controles para entrada, saída, protocolo e caminhos de negócios reais. |
| Dados, credenciais, criptografia, bancos de dados ou armazenamento | Dados e segredos | Inclua credenciais e metadados mesmo quando dados pessoais estiverem ausentes. |
| Um serviço implantado ou implantação planejada | Infraestrutura e implantação | Corresponda ao provedor e modelo de implantação; distinga a configuração pretendida do tempo de execução observado. |
| Código-fonte, dependências, build ou processo de lançamento | Cadeia de suprimentos | Quando a revisão do repositório estiver incluída, inspecione as definições de CI/CD descobertas, seus scripts/modelos, transições de confiança e portões de implantação sem esperar por uma segunda pergunta de permissão. As configurações efetivas da plataforma permanecem uma fonte de evidência separada. |
| Um serviço entrando ou já em operação | Operações e resiliência | Avalie detecção, recuperação, tratamento de incidentes, disponibilidade e propriedade. |
| LLMs, RAG, ferramentas de IA, agentes ou MCP | IA e agentes | Revise entradas do modelo, acesso a dados, autoridade delegada, saídas e limites de recursos. |
| Cliente móvel, desktop ou extensão de navegador | Móvel e desktop | Selecione as seções da plataforma e audite o backend separadamente. |
Para superfícies especializadas não suportadas, como equipamentos industriais ou hardware personalizado, documente o limite de cobertura e a revisão especializada necessária. Não implique que os módulos de software os avaliam completamente.
Examinar e registrar
- Siga as regras de evidência, autorização e execução do método de auditoria. Uma solicitação de auditoria autoriza análise e criação de relatório; ela não autoriza automaticamente alterações de produção, sondas destrutivas ou publicação de resultados confidenciais.
- Uma revisão de repositório cobre os arquivos acordados, caminhos de código-fonte, manifestos, histórico relevante e definições de CI/CD. Ela inclui segredos codificados, valores de fallback inseguros, destinos específicos de ambiente e política de segurança/identidade fixa. Honre exclusões de caminho/histórico mais restritas; não rotule constantes comuns como vulnerabilidades sem uma consequência de segurança.
- Mantenha um registro de evidências, matriz de controle, descobertas, desconhecidos, arestas do caminho de auditoria e arestas de dependência enquanto trabalha. Vincule todas as alegações materiais a locais exatos de código-fonte ou observações e à versão/ambiente inspecionado.
- Trate a saída do scanner como uma pista até que seja contextualizada. Rastreie chamadores relevantes, guardas, caminhos de dados, configuração e suposições de implantação antes de atribuir um defeito confirmado ou consequência de lançamento.
- Após o inventário, aplique a triagem de avisos atuais focada do módulo de cadeia de suprimentos (SC-003), priorizando componentes críticos e problemas conhecidos como explorados ou críticos/altos. Registre correspondências exatas de pacote/versão, fontes datadas, correções verificadas, exposição local e cobertura consultada; consultas offline ou com falha permanecem lacunas explícitas.
- Use o mesmo ID de controle na cobertura, descobertas, remediação e gráficos. Desduplique descobertas com a mesma causa subjacente, preservando as superfícies afetadas.
- Para revisões longas, delegue módulos independentes quando suportado. Dê a cada revisor o escopo e a alocação de IDs, depois reconcilie limites de confiança compartilhados e alegações conflitantes antes de escrever o relatório.
- Se o acesso ou uma ferramenta não estiver disponível, registre a limitação e continue o trabalho útil. Uma verificação com falha não é uma verificação aprovada. Um controle desconhecido não é não aplicável.
Entregar o relatório
Use o modelo de relatório. O padrão é um novo arquivo em security-audits/<YYYY-MM-DD>-<revisão-ou-alvo>/security-audit.md dentro do projeto auditado, a menos que o usuário especifique outro destino. Use um sufixo que não cause conflito se esse destino já existir. Não salve relatórios de destino dentro desta skill, sobrescreva uma avaliação anterior ou faça commit/envie relatórios a menos que solicitado.
Inclua ambos os diagramas Mermaid necessários:
- Grafo do caminho de análise: a trilha de auditoria observável, do escopo e artefatos, passando pelas verificações realizadas, até as descobertas, conclusões suportadas e lacunas. Mostre o que foi inspecionado e onde uma verificação parou. Este é um mapa de evidências, não um raciocínio privado ou uma cronologia inventada.
- Grafo de dependência analisada: os componentes inspecionados, dependências de pacotes, serviços, sistemas de identidade, armazenamento e integrações externas, com tipos de aresta explícitos, referências de evidência e cobertura de inspeção. Inclua limites materiais não inspecionados como tal.
Construa os grafos a partir dos registros usando o contrato de grafo no método de auditoria. Inclua tabelas de nós/arestas para que o relatório permaneça utilizável sem a renderização do Mermaid. Divida mapas de dependência grandes por tempo de execução/serviço, pacote/build ou relações de confiança CI/CD sob a seção de dependência. Para pipelines revisados, mostre gatilho/entrada → job → runner/identidade → artefato → ambiente, com portões reais, limites de confiança e configurações não inspecionadas distinguidos.
O relatório deve conter um plano de correção priorizado, proprietários ou funções não atribuídas, dependências entre correções, testes de aceitação, riscos residuais e decisões não resolvidas. Declare uma recomendação de prontidão limitada usando as regras de descobertas; a skill não aprova uma implantação ou certifica conformidade.
Verificação de qualidade final
- Verifique se o escopo, revisão, links de evidência, status de controle e todos os IDs de descoberta/desconhecidos concordam no texto, tabelas, gráficos e plano.
- Verifique as direções e rótulos das arestas do grafo. Marque declarações, comportamento observado, inferências e evidências indisponíveis de forma distinta. Remova todos os dados de exemplo do modelo.
- Garanta que nenhuma credencial, amostra de dados pessoais, conteúdo confidencial de prompt ou identificadores privados de infraestrutura sejam divulgados desnecessariamente.
- Toda descoberta precisa de uma correção concreta e critério de verificação. Toda incógnita crítica precisa de uma próxima ação e sua consequência para a decisão de lançamento.
- Declare quais verificações realmente foram executadas, quais falharam ou foram puladas, e se os diagramas foram renderizados ou apenas revisados sintaticamente. Nunca reivindique um teste, renderização ou verificação de tempo de execução que não ocorreu.
- Entregue a localização do arquivo, os principais bloqueadores de lançamento e os limites de cobertura de forma concisa. Deixe a implementação de correções para um acompanhamento autorizado, a menos que já esteja incluída na solicitação.