O que Revisão de Segurança para Grandes Volumes de Dados faz?
Revise todo o caminho dos dados para garantir comportamento de produção limitado. Reporte descobertas baseadas em evidências, caminhos seguros confirmados, evidências ausentes e limites testados ou não testados.
Regras de Operação
- Somente leitura por padrão. Não modifique código, dependências, bancos de dados, configurações de produção ou sistemas externos.
- Não instale dependências.
- Nunca trate evidências ausentes como prova de segurança. Marque a camada afetada como Não Verificada.
- Não declare uma escala suportada sem evidências de runtime, teste de carga, plano de consulta ou equivalente.
- Trate correspondências de padrão como candidatos, não como descobertas. Leia o fluxo de dados ao redor antes de reportar.
- Prefira o escopo do usuário ou o diff atual. Mantenha descoberta, leitura, comandos e saída limitados.
Fluxo de Trabalho
1. Estabelecer escopo
Leia a solicitação, instruções do repositório, arquivos nomeados, diff atual e produtores e consumidores diretos. Declare as camadas revisadas, excluídas e ausentes.
2. Construir o perfil de escala
Registre o volume atual, limite de projeto, frequência de solicitações, concorrência, crescimento, tamanho do item, alvos de interação e limites de recursos. Se os valores estiverem ausentes, rotule as suposições diagnósticas separadamente dos valores confirmados.
Use estas sondas diagnósticas apenas quando a evidência do usuário estiver ausente:
- 10.000.000 linhas armazenadas.
- 100.000 linhas correspondentes.
- 100 requisições interativas concorrentes.
- Tamanho de página 100, máximo rígido 200.
- 100.000 linhas lógicas de tabela com linhas DOM limitadas.
- 1.000.000 linhas de exportação ou lote.
- Crescimento de 10x.
3. Rastrear o caminho dos dados
Rastreie:
Fonte de dados -> consulta/acesso a dados -> serviço/job -> API/serialização -> gerenciamento de estado -> página/tabela/exportação
Declare quais camadas são suportadas por evidências.
4. Revisar cada camada
Use references/review-checklist.md para a revisão entre pilhas.
Carregue references/vue2-axios-vxe-table.md apenas quando o caminho contiver Vue, axios, vxe-table, estado do navegador ou renderização de tabela com muitos dados.
Carregue references/dotnet-webapi-efcore.md apenas quando o caminho contiver ASP.NET WebAPI, EF Core, LINQ, controladores, serviços, repositórios, exportações ou jobs em segundo plano.
Não carregue todas as referências por padrão.
Verifique escopo de armazenamento/consulta, materialização, projeção, índices, paginação estável, tamanho da carga útil, cancelamento, timeouts, concorrência limitada, contrapressão, idempotência, tentativas, cópias de estado, trabalho computado, tamanho do DOM, estados de carregamento e degradação.
5. Validar achados candidatos
Para cada candidato:
- Identifique a entrada ou dimensão de concorrência que cresce.
- Confirme onde ocorre filtragem, projeção, paginação, buffer ou renderização.
- Verifique limites rígidos existentes e se eles são testados.
- Rastreie propagação de cancelamento, timeout, tentativa e erro.
- Registre evidências exatas de arquivo e linha quando o código estiver disponível.
- Rejeite o candidato se o contexto provar que o caminho é limitado.
6. Classificar evidência e gravidade
Estados da evidência:
- Confirmado: evidência direta de código, SQL, configuração, teste, runtime ou design.
- Provável: evidência forte de caminho com um artefato ausente a montante ou a jusante.
- Não Verificado: material necessário não está disponível.
Gravidades:
- P0: dano confirmado a dados, indisponibilidade de produção ou exaustão descontrolada de recursos em um caminho atingível.
- P1: provável timeout, OOM, sobrecarga de banco de dados, falha grave de interação ou resultados incorretos em escala conhecida ou diagnóstica.
- P2: degradação significativa à medida que volume ou concorrência cresce, com margem atual ou um caminho alternativo.
- P3: limites, observabilidade, testes ou evidências de capacidade de manutenção ausentes, sem uma falha grave demonstrada.
Não atribua P0 ou P1 apenas com base em suposições diagnósticas. Coloque riscos graves, mas não suportados, sob verificação de alta prioridade.
7. Escrever o relatório
Carregue references/output-contract.md e siga exatamente.
Cada achado deve incluir:
- Gravidade e estado da evidência.
- Camada e código de causa raiz estável.
- Localização da evidência.
- Escala de acionamento.
- Impacto.
- Remediação mínima.
- Método de verificação.
Liste caminhos seguros confirmados apenas quando evidências os suportarem.
Limites de Repositório e Saída
- Enumere no máximo 100.000 caminhos como metadados; estreite por diretório e extensão acima disso.
- Digitalize no máximo 20.000 arquivos fonte ou 500 MiB de texto por passada de conteúdo, o que ocorrer primeiro.
- Retenha no máximo 500 correspondências candidatas; agregue o restante e registre a contagem truncada.
- Leia profundamente no máximo 200 arquivos candidatos por passada.
- Use um timeout de comando padrão de 60 segundos; estreite o escopo após um timeout.
- Expanda no máximo 50 achados e 5 locais de evidência representativos por causa raiz.
- Pule dependências, saída gerada, arquivos mortos, binários, diretórios de build e arquivos grandes minificados.
- Reporte toda exclusão e truncamento com contagem original, contagem retida e motivo.
Evidências Ausentes e Falhas
- Apenas frontend: revise o frontend e produza um contrato de backend/API/banco de dados Não Verificado.
- Apenas backend: revise o backend e marque a renderização e interação do consumidor como Não Verificado.
- Repositório superdimensionado: estreite a partir do diff, rotas, clientes, consultas, exportações e pontos de entrada de renderização.
- Timeout de comando: reduza o lote ou escopo do caminho em vez de aumentar repetidamente o timeout.
- Conflitos de documentação com código: prefira código, testes, planos de consulta e evidências de runtime; relate desvio de documentação.
- Material sensível: não repita segredos ou registros; use uma descrição de localização editada.