O que é esse linter de segurança para IA

Assistentes de IA como GitHub Copilot, ChatGPT e Cursor aceleram muito o desenvolvimento. Mas existe um problema que pouca gente fala abertamente: eles repetem os mesmos padrões inseguros o tempo todo.

Um desenvolvedor percebeu esse padrão e criou um linter open source especificamente para detectar os bugs de segurança que ferramentas de IA costumam introduzir. A ideia é simples - se a IA sempre comete os mesmos erros, é possível automatizar a detecção deles.

O projeto surgiu da frustração com code reviews que sempre encontravam as mesmas categorias de problemas em código gerado por IA: SQL injection, XSS, secrets hardcoded, validação insuficiente de entrada. São falhas antigas que todo curso de segurança ensina, mas que os modelos de linguagem continuam repetindo.

Como funciona

O linter analisa o código estaticamente, procurando padrões que correspondem a falhas de segurança conhecidas. Diferente de um scanner genérico, ele foi treinado observando especificamente o output de assistentes de IA em situações comuns de desenvolvimento.

O mecanismo é baseado em regras AST (Abstract Syntax Tree). Ele percorre a estrutura do código e identifica combinações perigosas: concatenação de string em queries SQL, uso de innerHTML com variáveis externas, uso de eval() com dados do usuário, entre outros.

A grande diferença em relação a linters tradicionais como ESLint ou Bandit é o foco no contexto de IA. As regras foram escritas observando o que os assistentes de IA geram quando solicitados a criar endpoints, formulários e queries - não apenas o que é teoricamente possível ser inseguro.

💡
Dica

Rode o linter especificamente nos arquivos que você gerou com IA antes de abrir o PR. É nesses arquivos que a probabilidade de encontrar algo é mais alta.

Principais recursos

As detecções do linter cobrem as categorias mais comuns de falhas introduzidas por IA:

  • SQL Injection: detecta concatenação de string em queries, inclusive em ORMs quando a parametrização é ignorada
  • XSS: identifica innerHTML, document.write e outras formas de inserir HTML sem sanitização
  • Secrets hardcoded: tokens, senhas e chaves de API escritas diretamente no código
  • Validação insuficiente: entradas de usuário usadas sem verificação de tipo, tamanho ou formato
  • Path traversal: uso de caminhos de arquivo construídos com input do usuário
  • Deserialização insegura: uso de pickle, eval ou funções similares com dados externos

Cada regra vem com explicação do risco, exemplo inseguro e versão corrigida. Isso torna o linter educativo, não só punitivo.

⚠️
Atenção

O linter não substitui um pentest ou auditoria de segurança. Ele pega os erros mais comuns, mas falhas de lógica de negócio ou problemas de autenticação complexos ainda precisam de revisão humana.

Como começar: instalação passo a passo

A instalação varia conforme a linguagem do seu projeto. Para projetos Python, o processo é direto:

pip install ai-security-linter
# Verificar instalação
ai-sec --version

Para projetos JavaScript e TypeScript, instale como devDependency:

npm install --save-dev ai-security-linter
# Adicionar no package.json
"scripts": {
  "lint:security": "ai-sec ./src"
}

Para integrar no CI/CD, adicione um step no seu pipeline. Exemplo para GitHub Actions:

- name: Security lint
  run: |
    pip install ai-security-linter
    ai-sec ./src --fail-on-error

Exemplo prático

Imagine que você pediu ao Copilot para criar um endpoint de busca. O código gerado frequentemente tem algo assim:

# Código gerado por IA - INSEGURO
@app.route('/search')
def search():
    query = request.args.get('q')
    results = db.execute(f"SELECT * FROM products WHERE name LIKE '%{query}%'")
    return jsonify(results)

O linter identifica isso imediatamente: SQL injection na linha 4, f-string interpolada diretamente na query. A saída seria algo como:

ERRO [SQL-INJ-001] search.py:4
  Interpolação direta de variável em query SQL.
  Use parametrização: db.execute("SELECT...", (f"%{query}%",))
  Risco: HIGH

A versão corrigida usa parametrização, que é o padrão seguro para qualquer banco de dados:

# Versão corrigida
@app.route('/search')
def search():
    query = request.args.get('q', '')
    results = db.execute(
        "SELECT * FROM products WHERE name LIKE ?",
        (f"%{query}%",)
    )
    return jsonify(results)

Comparação com alternativas

Já existem linters de segurança consolidados: Bandit para Python, ESLint com plugins de segurança para JS, Semgrep para múltiplas linguagens. Por que usar mais um?

A diferença está no foco. Bandit e Semgrep são excelentes para cobertura ampla, mas as regras são genéricas. Este linter foi construído observando especificamente o padrão de erros que aparecem em código gerado por IA - o que muda a distribuição de falsos positivos e negativos.

Em termos práticos: use Semgrep ou Bandit para auditoria completa do codebase. Use este linter como primeira linha no fluxo de review do código gerado por IA. Eles são complementares, não concorrentes.

🚀
Pro tip

Configure o linter como pre-commit hook. Ele roda em segundos em arquivos individuais e impede que código inseguro entre no repositório antes de qualquer review.

Pontos positivos e limitações

O que funciona bem: velocidade de detecção, foco nos padrões mais comuns de IA, feedback educativo que explica o risco e mostra como corrigir. A integração com CI/CD é direta e o modo --fail-on-error é útil em pipelines.

As limitações são reais. O linter não entende contexto de negócio. Uma query SQL parametrizada mas com lógica de autorização incorreta passa sem alertas. Falhas em nível de arquitetura, como expor dados que não deveriam ser expostos, também ficam fora do escopo.

Outra limitação: cobertura de linguagens. Python e JavaScript têm suporte completo. Outras linguagens têm cobertura parcial ou dependem de plugins da comunidade. Verifique no repositório quais regras estão disponíveis para a sua stack antes de adotar.

Casos de uso reais

Time de produto que usa Copilot intensamente: integra o linter no pre-commit e no CI. Qualquer código gerado por IA passa pela verificação automática antes de entrar no repositório. Reduz o tempo de code review focado em segurança.

Dev solo em projeto SaaS: usa o linter antes de cada PR para garantir que o código de endpoints e autenticação não tenha falhas óbvias. Compensa a falta de um time de segurança dedicado.

Tech lead revisando PRs: roda o linter nos arquivos do PR como primeiro passo. Se passar sem erros, foca o review em lógica de negócio e arquitetura - as coisas que linter não consegue verificar.

Professor de segurança: usa o linter como ferramenta didática. Mostra código inseguro gerado por IA, roda o linter, discute os alertas. Conecta teoria com exemplos reais do cotidiano dos alunos.

Dicas e boas práticas

💡
Dica

Configure o arquivo .ai-sec.yaml na raiz do projeto para ignorar falsos positivos conhecidos. Sem isso, regras muito genéricas vão gerar ruído nos arquivos de teste.

💡
Dica

Use o modo --explain para ver não só o erro mas o CVE relacionado e exemplos de exploração. Isso ajuda o time a entender o risco real, não só obedecer a uma regra.

🔴
Cuidado

Não configure o linter para bloquear deploys em produção sem um período de adaptação. Habilite no modo warning primeiro, observe o volume de alertas por uma semana, depois mude para erro bloqueante.

🚀
Pro tip

Combine com revisão manual focada em lógica de autorização. O linter pega injeção e XSS. Você como dev precisa verificar: esse usuário deveria ter acesso a esses dados?

Vale a pena?

Para quem usa IA para gerar código regularmente, sim, vale a pena. O custo de configuração é baixo - menos de uma hora para integrar no CI/CD. O benefício é ter uma camada automática de verificação específica para os padrões que ferramentas de IA costumam errar.

Para quem já tem Semgrep ou outra ferramenta de SAST configurada e funcionando bem, o ganho marginal pode ser pequeno. Vale conferir se as regras específicas para código de IA já estão cobertas na sua configuração atual.

O próximo passo é simples: instale, rode nos arquivos gerados por IA no seu projeto atual e veja o que aparece. Se encontrar algo real na primeira rodada, você tem a resposta.