Ganhos:
- Capacidade de usar inteligência artificial como um segundo olho e sinalizar vulnerabilidades da classe OWASP (injeção, segredo rígido, controle de acesso) no código, fornecendo contexto
- Capacidade de eliminar falsos positivos produzidos pela inteligência artificial com contexto e evitar tratar cada descoberta como uma vulnerabilidade real sem validá-la
- Capacidade de reconhecer que a correção sugerida pela inteligência artificial pode introduzir novas vulnerabilidades/bugs e passar cada patch pelo portão de revisão e teste
As vulnerabilidades no software estão entre as vulnerabilidades mais caras porque estão incorporadas no produto desde o início e distribuídas para milhões de usuários. A revisão segura do código é o processo de leitura do código-fonte linha por linha e detecção de vulnerabilidades – injeção de SQL, vulnerabilidade de autenticação, senha codificada, autorização incorreta – antes de entrarem em produção. Quando feito manualmente, é lento e cansativo; É fácil não perceber uma vulnerabilidade em uma grande base de código.
A IA é poderosa na revisão de código por dois motivos: o código também é uma linguagem e a IA é boa no reconhecimento de padrões. A IA pode sinalizar rapidamente padrões perigosos em um trecho de código (colocar a entrada do usuário diretamente na consulta, armazenamento de dados não criptografados, falta de validação de entrada), explicar por que cada um é arriscado e sugerir uma correção. Mas a IA não vê todo o contexto operacional do código (a entrada pode estar sendo limpa em outra camada), pode inventar uma vulnerabilidade que não existe (falso positivo) ou perder uma vulnerabilidade real (falso negativo) e, o mais importante, a “correção” que ela propõe pode introduzir uma nova vulnerabilidade ou bug. A IA é um segundo olho e um indicador na revisão de código; O desenvolvedor e o especialista em segurança decidem se uma descoberta é uma vulnerabilidade real e se a correção é correta e segura.
Etapas da revisão de código
- Dê escopo e contexto. Qual linguagem, qual framework, onde esse código recebe a entrada, onde ele fornece a saída, em qual camada ele funciona? A revisão de código sem contexto produz falsos positivos.
- Procure padrões perigosos. Pesquise classes conhecidas de vulnerabilidade de IA (como OWASP Top 10): injeção, autenticação, divulgação de dados confidenciais, controle de acesso.
- Faça com que cada descoberta seja justificada. Para cada flag: qual linha, qual classe de vulnerabilidade, como pode ser explorada, quais são as evidências. Uma conclusão injustificada não é levada a sério.
- Elimine falsos positivos. A entrada está realmente sendo limpa, esse caminho é realmente acessível - verifique com o contexto.
- Verifique a correção. Confirme se o patch recomendado pela IA realmente fecha a vulnerabilidade, não introduz novas vulnerabilidades/bugs e passou nos testes.
- Aprovação humana. Desenvolvedor + especialista em segurança analisa a descoberta e a correção; É assim que entra no repositório de código.
Termos: SAST (Static Application Security Testing — teste de segurança estático que analisa o código-fonte sem executá-lo). DAST (Dinâmico — teste dinâmico que testa externamente o aplicativo em execução). OWASP Top 10 é a lista padrão das vulnerabilidades mais comuns de aplicativos da web. A injeção é uma vulnerabilidade causada pela interpretação da entrada do usuário como um comando/consulta (por exemplo, injeção de SQL). A consulta parametrizada é o método correto que evita a injeção separando a entrada do código.
Tabela de classes de vulnerabilidade comuns
Classe de vulnerabilidade
Sintoma (no código)
solução certa
Armadilha da IA
Injeção SQL
Unindo entrada na consulta
Consulta parametrizada
Pode ignorar a higienização
segredo codificado
Senha/digite o código
Cofre secreto (cofre), ambiente
Falso positivo (amostra/teste)
Autenticação fraca
Controle ausente/incorreto
Controle poderoso e centralizado
perde o contexto
Controle de acesso defeituoso
Nenhuma verificação de autorização
Autorização do lado do servidor
Não entende fluxo complexo
Divulgação de dados confidenciais
Armazenamento/registro sem senha
Criptografia, mascaramento
Não posso saber a criticidade
Serialização insegura
Desserializar dados não confiáveis
Análise segura
Perde padrão raro
três mini cases
Caso 1 — Capturando a injeção propriamente dita. Um desenvolvedor faz com que a IA examine uma função de acesso a dados. A IA marca a linha onde o valor userId do usuário é concatenado diretamente no texto SQL e diz “isso é injeção SQL clássica, transforme-a em uma consulta parametrizada”; Fornece correção de amostra. O desenvolvedor confirma que a entrada não foi higienizada em outro lugar, verifica se é uma vulnerabilidade real, implementa a consulta parametrizada sugerida e escreve um teste. A IA destacou a vulnerabilidade; os testes de verificação e correção vieram do desenvolvedor.
Caso 2 — Segredo fixo falso positivo. A IA vê a linha password = "test1234" em um arquivo e diz "critical: hardcoded password". O desenvolvedor verifica o contexto: este é um arquivo de teste de unidade, dados de teste fictícios, não lançados em produção e não portados para um sistema real. A descoberta é um falso positivo. O desenvolvedor documenta isso, mas não toma nenhuma atitude porque não é um segredo real. Lição: O sinal de “segredo difícil” da IA deve ser eliminado pelo contexto; Nem toda string é um segredo.
Caso 3 — Nova correção de vulnerabilidade. AI propõe uma correção para uma vulnerabilidade XSS (cross-site scripting); mas o código que ele sugere limpa a entrada no lugar errado e ignora a codificação da saída em outra área; Como resultado, a lacuna não fecha completamente. O especialista em segurança analisa a correção, percebe a falta de codificação e a corrige na camada correta. Lição: O patch recomendado pela IA não é automaticamente seguro; Cada correção é revisada e testada.
Alerta fraco / Alerta forte
Alerta fraco:
Existe uma lacuna neste código, corrija-a: [código]
Este prompt não fornece contexto (linguagem, estrutura, fonte de entrada), não pede justificativa, não questiona o falso positivo e está aberto a aceitar cegamente a correção produzida pela IA. A IA mistura sinais de vulnerabilidade real e inexistente.
Alerta poderoso:
Sua função: assistente que é o SEGUNDO OLHO do desenvolvedor na revisão segura do código.Tomada de decisões; considere a correção aplicada diretamente. Código: [especificar idioma/estrutura].Contexto: esta função [fonte de entrada: por exemplo. recebe [solicitação HTTP externa], grava em [destino de saída]. Sua tarefa: (1) sinalizar possíveis vulnerabilidades com a classe OWASP, fornecer o número da linha + por que é arriscado + como explorar + evidências para cada uma, (2) escrever pelo menos 1 cenário de falso positivo para cada descoberta (por exemplo, se a entrada for higienizada em outra camada), (3) sugerir uma correção, mas com o sinal "[revisão + gravação de teste]"; Avalie também se a correção introduz novas vulnerabilidades/bugs. Adicionando uma vulnerabilidade falsa.[código]
A solicitação forte fornece contexto, solicita classe e evidências do OWASP, questiona falsos positivos e riscos de remediação, força a revisão humana.
Modelos de prompt copiáveis
MODELO DE VERIFICAÇÃO DE VULNERABILIDADE Examine o código [linguagem/estrutura] do OWASP Top 10. Para cada descoberta possível: número da linha, classe de vulnerabilidade, por que é arriscado, amostra de exploração, força da evidência (certa/provável/fraca). Contexto: entrada [fonte], saída [destino]. Adicionando descobertas fabricadas; Se não tiver certeza, digite "[deve ser verificado]". Código: [colar]
PADRÃO DE ELIMINAÇÃO FALSO POSITIVO Para a descoberta de código a seguir, liste os cenários em que NÃO há uma vulnerabilidade real: a entrada poderia ser limpa em outra camada, este caminho está acessível, este valor é um teste/amostra, a estrutura está automaticamente protegida. Escreva como confirmar para cada um. Descoberta: [colar]
MODELO DE AVALIAÇÃO DE CORREÇÃORecomende uma correção para a seguinte vulnerabilidade; em seguida, critique sua própria correção: (1) ela realmente fecha a vulnerabilidade, (2) introduz uma nova vulnerabilidade/bug, (3) que teste devo escrever (caso positivo e negativo), (4) impacto no desempenho/funcionalidade. Vou revisar e testar a correção. Vulnerabilidade + código: [colar]
MODELO DE ENSINO DE PADRÃO SEGURO para classe de vulnerabilidade [por exemplo, Injeção de SQL] mostram comparativamente o padrão de digitação seguro e os padrões errôneos comuns nesta linguagem/estrutura. Regra geral + dar exemplo de código; mas quero que você pergunte o contexto antes de implementá-lo no meu código. Linguagem/estrutura: [escrever]
Erros comuns
- Revise sem contexto. Sem linguagem, estrutura e contexto de entrada/saída, a IA confunde descobertas reais e espúrias; Certifique-se de fornecer contexto.
- Confundindo cada sinal com fraqueza real. A IA produz falsos positivos (dados de teste, entrada limpa em outra camada); Peneire cada descoberta com contexto.
- Aplicando cegamente a correção da IA. O patch recomendado pode introduzir novas vulnerabilidades/bugs; revisar e escrever testes.
- Confiando no falso negativo. Mesmo que a IA diga “sem vulnerabilidades”, examine você mesmo os caminhos críticos; A verificação estática não detecta todas as vulnerabilidades.
- Fornecendo o código/segredo à ferramenta externa. Código privado e segredos reais (chave, senha) são propriedade intelectual e vulnerabilidade; anonimizar ou usar ferramentas corporativas e isoladas.
Dica: Ao ter o código de revisão da IA, o filtro mais eficiente é perguntar pela “força da evidência” (certa/provável/fraca) para cada descoberta. A maioria dos resultados marcados como “fracos” são falsos positivos; você aloca sua energia para os “certos”.
Cuidado: a correção de segurança proposta pela IA não deve entrar no armazém sem ser testada. Uma “correção” incorreta pode deixar a vulnerabilidade aberta e levar a um erro funcional na produção; Cada patch passa pelo portão de revisão e teste.
Resumindo
A revisão segura do código é a maneira mais barata de detectar vulnerabilidades antes que elas entrem em produção e, como o código é uma linguagem, a IA se torna um poderoso segundo olho aqui: sinaliza padrões perigosos, explica riscos, sugere soluções. Mas a IA não vê todo o contexto operacional, produz falsos positivos e falsos negativos, e o patch que recomenda pode introduzir novas vulnerabilidades. Portanto, a revisão tem seis etapas (contexto, triagem, justificativa, eliminação de falsos positivos, verificação de correção, aprovação humana) e a decisão cabe ao desenvolvedor e ao especialista em segurança. Três princípios: nenhuma descoberta é interpretada sem contexto, cada sinal é eliminado com contexto, nenhuma correção vai para o armazenamento sem ser testada. E o código/segredo nunca é fornecido a uma ferramenta externa sem anonimato.
Tarefa de aplicativo
Pegue um trecho de código de amostra (removendo partes confidenciais de seu próprio código ou um código de amostra com vulnerabilidades). Faça com que a IA o examine com o modelo “Verificação de vulnerabilidades”; Aplique o modelo de “Eliminação de Falso Positivo” para cada descoberta e elimine as reais. Faça a correção da descoberta mais séria com o modelo "Avaliação de Remediação", revise você mesmo e escreva um caso de teste positivo + um negativo. Observe quantas descobertas foram falsos positivos.
lista de verificação
- [] Forneci a linguagem, a estrutura e o contexto de entrada/saída antes de revisar o código.
- [] Solicitei o número da linha, classe de vulnerabilidade, caminho de exploração e evidências para cada descoberta.
- [] Eu examinei cada descoberta em busca de falsos positivos com contexto.
- [] Não apliquei cegamente a correção da IA; Eu revisei e escrevi um teste.
- [] Apesar da saída "Sem vulnerabilidades", eu mesmo examinei os caminhos críticos.
- [ ] Anonimizei o código/segredos ou usei ferramentas corporativas isoladas.
- [] Passei na descoberta e correção por meio da aprovação do desenvolvedor + segurança.