insecure-defaults

Visão geral da skill insecure-defaults

O que a insecure-defaults faz

A skill insecure-defaults ajuda você a identificar padrões de configuração que “falham aberto”, permitindo que o software continue rodando com configurações inseguras em vez de interromper a execução. Ela é especialmente útil em uma Auditoria de Segurança de código de produção, configs de deploy e lógica de tratamento de segredos, quando variáveis de ambiente ausentes devem ser tratadas como defeito, e não toleradas silenciosamente.

Quem deve usar

Use a skill insecure-defaults se você revisa código de autenticação, criptografia, chaves de API ou infraestrutura e precisa separar comportamento seguro de fail-secure de comportamentos de fallback arriscados. Ela é uma boa opção para revisores, equipes de AppSec e agentes que verificam se um serviço consegue subir com credenciais fracas, defaults permissivos ou segredos de placeholder.

O que a torna diferente

A skill não é um prompt genérico de “encontrar bugs de segurança”. Ela foca em uma decisão específica: a ausência de configuração faz o sistema falhar de forma segura ou continuar de maneira insegura? Esse escopo estreito torna a insecure-defaults útil para pegar problemas como segredos padrão, senhas de fallback e tratamento permissivo de variáveis de ambiente que passam despercebidos em uma auditoria ampla.

Como usar a skill insecure-defaults

Instale e abra os arquivos certos

Para insecure-defaults install, adicione a skill com npx skills add trailofbits/skills --skill insecure-defaults. Depois, leia primeiro SKILL.md e, em seguida, references/examples.md para ver os padrões reportados e os que não devem ser reportados. Se você estiver adaptando a skill para outro repo, também inspecione quaisquer arquivos de configuração, deploy ou relacionados a segredos em que defaults possam importar.

Dê à skill um alvo concreto de auditoria

O melhor uso de insecure-defaults usage começa com uma pergunta específica, não com um pedido vago. Bons inputs nomeiam o serviço, a superfície de configuração e o limite de risco:

• “Revise este serviço de autenticação em busca de insecure-defaults no tratamento de variáveis de ambiente e carregamento de segredos.”
• “Verifique arquivos de Docker e IaC para credenciais de fallback ou defaults permissivos.”
• “Audite estes fluxos de inicialização para confirmar que a falta de configuração falha de forma segura, e não aberta.”

Use a skill como fluxo de triagem

Um insecure-defaults guide prático é: identificar onde a configuração é lida, verificar se valores ausentes causam crash ou fallback e confirmar se o default é seguro em produção. Os exemplos do repositório mostram a distinção principal: env['KEY'] ou validação explícita geralmente é seguro, enquanto env.get('KEY') or 'default' é um problema reportável quando o valor controla o comportamento de segurança.

Melhore a qualidade da saída com contexto delimitado

Forneça os arquivos exatos, a stack e o contexto de deploy que o agente deve examinar. Por exemplo, mencione src/auth/, config/, docker-compose.yml ou helm/ se esses caminhos existirem. Também diga se fixtures de teste, arquivos de exemplo ou configs usadas só em desenvolvimento devem ser excluídos; a skill trata esses casos como não-achados, a menos que afetem o comportamento em produção.

Perguntas frequentes da skill insecure-defaults

A insecure-defaults é só para código de aplicação?

Não. A skill insecure-defaults também se aplica a manifests de deploy, IaC, configuração de containers e lógica de variáveis de ambiente. Se um segredo ou senha ausente faz o app rodar com um default fraco, esse é exatamente o tipo de problema que ela foi criada para detectar.

Em que ela difere de um prompt comum?

Um prompt comum costuma gerar conselhos amplos de segurança. A skill insecure-defaults é mais estreita e orientada a decisão: ela verifica se uma configuração ausente leva a uma falha segura ou a um fallback perigoso. Esse foco reduz falsos positivos e torna a revisão mais consistente entre codebases.

Quando eu não devo usá-la?

Não use a insecure-defaults para fixtures de teste, arquivos .example ou .template, trechos de documentação ou scripts usados só em desenvolvimento, a menos que eles sejam realmente usados em produção. Ela também é a ferramenta errada quando o sistema deve encerrar se a configuração estiver ausente; esse comportamento fail-secure é um acerto, não um achado.

Ela é amigável para iniciantes?

Sim, se você consegue identificar onde um sistema lê segredos ou configuração. O guia da skill insecure-defaults é fácil de aplicar porque depende de uma pergunta simples: “O que acontece quando o valor está ausente?” A nuance está em saber quais arquivos são entradas reais de runtime e quais são apenas placeholders.

Como melhorar a skill insecure-defaults

Dê evidências mais fortes no prompt

A melhor forma de melhorar os resultados da insecure-defaults é incluir a variável ou o caminho de arquivo exato e sensível para a segurança. Por exemplo, “Verifique se SECRET_KEY, DB_PASSWORD ou JWT_SECRET tem algum fallback no código de inicialização em produção” é muito melhor do que “encontre problemas de segurança”. Entradas específicas ajudam a skill a focar em defaults exploráveis, e não em configurações de conveniência inofensivas.

Separe produção de não produção

Um modo comum de falha é reportar em excesso defaults em arquivos locais, de teste ou de exemplo. Diga à skill quais diretórios são implantáveis e quais não são. Se um fallback é intencional em dev, mas não é permitido em prod, diga isso explicitamente para que a revisão possa avaliar se essa fronteira está realmente sendo imposta.

Peça raciocínio, não só achados

Ao iterar, solicite o caminho exato do código e por que o default é perigoso. Por exemplo: “Mostre se o app ainda inicia com um segredo ausente e explique o impacto se esse segredo assina sessões ou tokens.” Isso torna a insecure-defaults mais útil para uma Auditoria de Segurança, porque conecta cada achado à explorabilidade.

Refine depois da primeira passada

Se a primeira saída vier ampla demais, rode de novo com escopo menor: um serviço, uma classe de configuração ou um conjunto de manifests de deploy. Se você precisar de mais precisão, peça para a skill priorizar apenas casos fail-open que afetem autenticação, criptografia ou controle de acesso, e ignorar defaults inofensivos que não mudam a postura de segurança.