ESPAÇO PUBLICITÁRIO DISPONÍVEL · FALE CONOSCO
Português
English简体中文繁體中文日本語EspañolPortuguês한국어DeutschFrançais
Todos os sites

Configurando Extensões de Regra no Snyk Code para Mapear Sanitizadores Customizados e Eliminar Falsos Positivos

Guia
365Finds Editorial
11.430 artigos Wiki catalogados

Use o 365 Wiki com sua IA

Copie o prompt abaixo, cole na IA que você já usa e faça sua pergunta.

Baixar o Skill completo

Experimente primeiro com o prompt. Se você usa o 365 Wiki com frequência, instale o Skill completo do 365Wiki para não precisar colá-lo novamente. Se não usa uma IA específica, as versões web do Gemini ou Microsoft Copilot também servem.

365Wiki Skill

Baixar o Skill completo
Equipes de segurança de aplicações (AppSec) e arquitetos corporativos que implementam o Snyk Code frequentemente enfrentam um gargalo operacional crítico: a fadiga de alertas causada por falsos positivos originados em bibliotecas internas. O Snyk Code utiliza um mecanismo de análise semântica baseado em inteligência artificial e execução simbólica (DeepCode) para rastrear o fluxo de dados não confiáveis desde os pontos de entrada (sources ou origens) até operações críticas de execução (sinks ou coletores). No entanto, quando os desenvolvedores passam esses dados por métodos internos de validação, classes utilitárias de escape ou wrappers de segurança proprietários, o analisador estático não consegue deduzir nativamente se essas funções neutralizam o perigo.


O resultado é a geração em massa de alertas de severidade alta para injeção de SQL, Cross-Site Scripting (XSS) e Path Traversal em pull requests perfeitamente seguros. Tratar esses alertas de forma reativa — seja ignorando apontamentos na interface web ou espalhando arquivos .snyk individuais pelos repositórios — gera um custo de governança inviável e eleva o risco de mascarar vulnerabilidades reais. Para resolver essa dor, o Snyk oferece nos planos Enterprise o recurso de Extensões de Regra (Rule Extensions). Com ele, o time de AppSec pode registrar centralmente o Nome Totalmente Qualificado (Fully Qualified Name ou FQN) de funções proprietárias, associá-las a regras de segurança específicas e selecionar a semântica de sanitização adequada, eliminando falsos positivos em toda a organização de forma sustentável.




Análise de Taint e a Causa Raiz dos Falsos Positivos


Para configurar sanitizadores customizados com precisão, é indispensável compreender o modelo de análise de fluxo de dados (taint analysis) do Snyk Code:


[Origem (Source): Entrada externa não confiável]
       │
       ▼
[Validador interno proprietário] ──► (Opaco para o motor padrão sem Rule Extension)
       │
       ▼ (A flag de taint continua ativa)
[Coletor (Sink): Operação sensível] ──► Alerta falso positivo (False Positive)



    

  1. Origem (Source): Ponto de entrada de dados não confiáveis na aplicação, como parâmetros de requisição HTTP, headers, uploads ou mensagens de mensageria.
    2. 

  2. Caminho de propagação: Rota percorrida pelo dado por meio de atribuições de variáveis, chamadas de métodos e transformações em múltiplos arquivos.
    3. 

  3. Sanitizador (Sanitizer): Função ou barreira lógica que codifica, filtra ou valida o dado, assegurando que ele se torne inofensivo.
    4. 

  4. Coletor (Sink): Ponto de execução sensível que, se receber dados contaminados, resulta em falha de segurança (consultas a banco de dados, renderização DOM, escrita em disco).
    5. 



Os analisadores SAST convencionais trazem modelos prontos apenas para bibliotecas padrão de linguagens e frameworks open-source consolidados. Quando o dado atravessa uma classe proprietária da organização (por exemplo, MyOrg.Security.Encoder.CleanHtml ou PathValidator.assertSafePath), o analisador considera a função como um mero intermediário que repassa o dado contaminado, acionando o alerta no coletor.


Limitações dos métodos tradicionais de supressão



As Extensões de Regra solucionam a causa raiz: ao ensinar o analisador semântico a reconhecer a função como um sanitizador verificado, o vínculo de contaminação é rompido automaticamente em todos os repositórios cobertos.




Os Quatro Modelos Semânticos de Sanitização


Funções de segurança operam sob diferentes padrões arquiteturais. O Snyk Code oferece quatro tipos de sanitização (extension_type na API REST):





































Tipo de sanitizadorAPI extension_typeComportamento semântico no motorCenários típicos de aplicação
Fluxo direto (Flow Through)flows_through_sanitizerSanitiza todos os dados que fluem através da função. O valor retornado é considerado seguro, independentemente do estado da entrada.Codificação HTML, escape de URLs, métodos utilitários que retornam strings sanitizadas.
Se verdadeiro (If True)if_true_sanitizerO argumento é considerado seguro somente dentro de blocos condicionais onde a função retorna true.Validadores booleanos, checagens de regex por lista branca (ex.: isAlphaNumeric).
Se falso (If False)if_false_sanitizerO argumento é considerado seguro somente dentro de blocos condicionais onde a função retorna false.Detectores de listas negras ou protocolos perigosos (ex.: containsJavascriptProtocol).
Qualquer uso (Any Usage)any_usage_sanitizerO argumento é considerado seguro logo após a conclusão da chamada do método. Aplica-se a rotinas que lançam exceções ou alteram o objeto em memória.Métodos de asserção que interrompem o fluxo com exceções caso o dado seja inválido.


1. Fluxo direto (Flow Through)


Ideal para métodos transformadores que recebem um dado bruto e produzem um retorno limpo:


package com.company.utils;

public class SecurityUtils {
    public static String escapeHtml(String data) {
        if (data == null) return "";
        return data.replace("<", "&lt;").replace(">", "&gt;");
    }
}



Configurado como flows_through_sanitizer para a regra de XSS, qualquer valor oriundo desse método que atinja um ponto de saída HTTP deixará de ser sinalizado como vulnerável.


2. Se verdadeiro (If True)


Apropriado para funções de validação booleana:


package com.company.utils;

public class SecurityUtils {
    public static boolean isAlphaNumeric(String data) {
        return data != null && data.matches("^[a-zA-Z0-9]*$");
    }
}



Na lógica da aplicação:


if (SecurityUtils.isAlphaNumeric(username)) {
    // A contaminação é eliminada aqui; o acesso a arquivos é considerado seguro
    File userProfile = new File("/data/profiles/" + username);
} else {
    // A contaminação persiste no bloco else
    response.sendError(400, "Invalid username");
}



3. Se falso (If False)


Apropriado para checagens de sentinela negativa:


package com.company.utils;

public class SecurityUtils {
    public static boolean containsJavascriptProtocol(String data) {
        if (data == null) return false;
        return data.toLowerCase().trim().startsWith("javascript:");
    }
}



Na aplicação:


if (!SecurityUtils.containsJavascriptProtocol(redirectUrl)) {
    // A contaminação é eliminada quando retorna false; redirecionamento seguro
    response.sendRedirect(redirectUrl);
} else {
    response.sendError(400, "Invalid redirect URL");
}



4. Qualquer uso (Any Usage)


Apropriado para métodos que interrompem a execução com exceções em caso de inconsistência:


package com.company.utils;

public class SecurityUtils {
    public static void validateFileId(String fileId) {
        if (fileId == null || !fileId.matches("^[a-zA-Z0-9_-]+$")) {
            throw new IllegalArgumentException("Invalid File ID format");
        }
    }
}



Na aplicação:


// Lança exceção e interrompe o fluxo se inválido
SecurityUtils.validateFileId(fileId);

// A partir desta linha, o argumento fileId é tratado como seguro
File file = new File("/data/uploads/" + fileId);





Alerta de Segurança: Utilizar any_usage_sanitizer em funções comuns que não lançam exceções nem realizam mutação in-place causa falsos negativos severos. O analisador assumirá que qualquer dado é seguro, ignorando falhas reais no código.






Formatação do Nome Totalmente Qualificado (FQN)


O motor do Snyk Code exige o Fully Qualified Name (FQN) exato da função. Nomes parciais (PQN) e expressões regulares não são suportados. As convenções por linguagem incluem:





Configuração na Interface Web e via REST API


As Extensões de Regra podem ser gerenciadas tanto pela interface do Snyk quanto via API pública.


Passo a passo na Interface Web


    

  1. Acesse o console do Snyk e selecione o Grupo (Group) corporativo.
    2. 

  2. Navegue até Group settings -> Snyk Code -> Rule Extensions.
    3. 

  3. Clique em Create sanitizer e preencha as propriedades essenciais:

      

    • Sanitizer: Insira o FQN exato (ex.: com.company.utils.SecurityUtils.escapeHtml).
      • 

    • Rule key: Escolha a regra de segurança correspondente (ex.: XSS, Sqli, PT, CommandInjection, OR, LogForging).
      • 

    • Sanitization type: Selecione um dos quatro tipos semânticos.
      • 

    

    4. 

  4. Defina os atributos de escopo e ciclo de vida:

      

    • Scope: Aplique a todo o Grupo ou restrinja a Organizações específicas.
      • 

    • Description: Adicione justificativas internas, links de tickets ou equipes responsáveis.
      • 

    • Status: Escolha entre Draft (Rascunho) ou Published (Publicado).
      • 

    

    5. 

  5. Clique em Save.
    6. 



Mantenha novas regras inicialmente como Draft para realizar testes de impacto antes de colocá-las em produção.




Validação Preventiva com Testes de Impacto (Impact Testing)


Publicar uma extensão de regra sem validação prévia traz riscos de efeito nulo (por erro de digitação no FQN) ou supressão indevida de alertas legítimos. O recurso de Impact Testing permite simular o impacto exato da nova regra no histórico de achados de um projeto específico.


Fluxo de Teste Automatizado via API


Passo 1: Disparar o Teste de Impacto


Envie uma requisição POST para /rest/groups/{group_id}/sast/rule_extensions/tests:


POST /rest/groups/b1d4c802-9a3e-4b62-9e81-2c1a84f5093e/sast/rule_extensions/tests HTTP/1.1
Host: api.snyk.io
Authorization: token YOUR_API_TOKEN
Content-Type: application/json

{
  "data": {
    "type": "tests",
    "attributes": {
      "project_id": "a3b8d4e1-7f1c-4a09-8b7e-2c6f5d1a0b3f",
      "org_id": "123e4567-e89b-12d3-a456-426614174000",
      "fully_qualified_name": "com.company.utils.SecurityUtils.escapeHtml",
      "rule_keys": ["XSS"],
      "extension_type": "flows_through_sanitizer"
    }
  }
}



A API responderá com 202 Accepted e o identificador test_id.


Passo 2: Monitorar o Status do Processamento


Envie requisições periódicas GET para /rest/groups/{group_id}/sast/rule_extensions/tests/{test_id} até que o status passe de STARTED para COMPLETED.


Passo 3: Consultar os Resultados Comparativos


Consulte /rest/groups/{group_id}/sast/rule_extensions/tests/{test_id}/results:


{
  "data": {
    "attributes": {
      "total_count": 4,
      "removed_findings": {
        "count": 4,
        "changes": [
          {
            "rule_id": "java/XSS",
            "rule_name": "Cross-site Scripting (XSS)",
            "file_path": "src/main/java/com/company/web/UserController.java",
            "severity": "high",
            "priority_score": 710
          }
        ]
      },
      "added_findings": {
        "count": 0,
        "changes": []
      }
    }
  }
}



Análise dos Indicadores





Melhores Práticas Operacionais em AppSec


    

  1. Padronização em Bibliotecas de Segurança Compartilhadas: Evite que times criem utilitários isolados. Centralize as lógicas de validação em SDKs corporativos consolidados e vincule as Extensões de Regra apenas a esses pontos centrais.
    2. 

  2. Incentivo a Importações Explícitas: Estabeleça boas práticas que desencorajem importações com curingas ou reflexão dinâmica nos pontos de validação de dados.
    3. 

  3. Auditoria de Ciclo de Vida: Sempre que houver refatorações ou mudanças de pacotes nas bibliotecas internas, atualize de imediato os FQNs correspondentes no Snyk Code para evitar o retorno dos alertas.
    4. 

  4. Implantação Gradual: Siga sempre o fluxo: Criação em Rascunho ➔ Teste de Impacto ➔ Piloto em Organização Específica ➔ Publicação no Nível de Grupo.
    5. 



Adotando essa disciplina operacional, times de AppSec restauram a produtividade dos desenvolvedores e mantêm a integridade da análise estática em escala corporativa.




Referências


Produtos abordados
Snyk DeepCode AI