SecureCode AI
Você quer saber se o código que está entrando em produção carrega credencial exposta ou injeção — sem mandar seu código-fonte para fora sem autorização.
O SecureCode revisa um diff de código por segurança e devolve achados com CWE, referência OWASP, severidade, explicação e sugestão de correção em português. Você conecta o repositório (GitHub, GitLab ou manual), guarda segredo de webhook e token cifrados, e decide por repositório se aquele código pode ou não ser enviado a um modelo de IA. Essa decisão é por repositório, não uma chave global.
A revisão sempre entrega a camada determinística. O parser lê o unified diff, isola só as linhas adicionadas e roda sete regras ancoradas em CWE/OWASP: credencial embutida (CWE-798), SQL injection por concatenação (CWE-89), command/code injection (CWE-78), hash fraco MD5/SHA-1 (CWE-327), desserialização insegura (CWE-502), SSRF por URL dinâmica (CWE-918) e verificação de TLS desabilitada (CWE-295). O trecho citado sai truncado em 256 caracteres e com o valor do segredo mascarado — o segredo detectado nunca é copiado para o achado.
A camada de IA é fail-closed. Código-fonte pode carregar segredo, então a task é SENSITIVE e o gateway barra o envio salvo aprovação explícita daquele repositório. Sem aprovação, a revisão entrega os achados determinísticos e o resumo marca que a IA foi bloqueada — nada é inventado no lugar. Achados da IA e do SAST são unidos por uma impressão digital estável (arquivo, regra, linha), o que torna a re-execução idempotente: rodar o mesmo review de novo não duplica achado. Achados de severidade média ou acima são promovidos automaticamente ao Vuln Tracker, e o crédito reservado é capturado no sucesso e devolvido em qualquer falha.
Capacidades em operação
Cada item corresponde a funcionalidade que existe no código e é alcançável por um usuário com o escopo correto.
-
Repositórios com segredo cifrado
Cadastro de repo GitHub, GitLab ou manual. Segredo de webhook e token são cifrados na gravação; a leitura devolve apenas indicadores booleanos de presença, nunca o valor.
-
Revisão sob demanda com preço por tamanho
POST /securecode/reviews recebe o diff, exige Idempotency-Key, aplica rate-limit e reserva crédito pelo bucket do diff (até 200 linhas = 4, até 1500 = 8, acima = 16). Responde 202 e o trabalho pesado roda no worker.
-
SAST determinístico sem rede e sem IA
Sete regras ancoradas em CWE/OWASP aplicadas às linhas adicionadas do diff. Parser tolerante: hunk malformado é ignorado, snippet solto sem estrutura de diff é revisado linha a linha, diff sem adição devolve zero achados em vez de erro.
-
Segredo mascarado no achado
Achado sem cópia do código — O achado gravado aponta arquivo, linha, CWE, referência OWASP, severidade, título e explicação; ele não carrega uma cópia da linha de código. O motor trunca em 256 caracteres e mascara valores longos depois de = ou : ao montar o achado cru, mas esse trecho não é persistido nem devolvido pela API — a credencial detectada não é republicada em lugar nenhum.
-
Revisão por IA com egress fail-closed por repo
A task securecode_review é SENSITIVE; o diff só chega ao provedor se aquele repositório estiver com ai_egress aprovado. O diff entra embrulhado como dado não confiável. Sem aprovação, entrega-se o SAST determinístico e o resumo registra ai_blocked.
-
Merge idempotente por impressão digital
Fingerprint sha256(arquivo|regra|linha) truncado em 32 caracteres, usado como chave do upsert (ON CONFLICT em tenant + review + fingerprint): a reentrega da mesma tarefa não duplica achado dentro do review. Os achados da IA entram com a regra literal 'ai' no fingerprint, então nunca colidem com os do SAST — as duas camadas convivem como linhas separadas, sem enriquecimento cruzado: o achado determinístico sai sempre sem correção sugerida, e a mesma falha vista pelas duas camadas aparece duas vezes na lista.
-
Promoção automática ao Vuln Tracker
Achado novo com severidade média, alta ou crítica vira registro em portal_vulnerabilities com source='import', de forma idempotente. Achados none e low não promovem.
-
Crédito devolvido em qualquer falha
Crédito capturado no sucesso, devolvido na falha de persistência e no timeout — Capture só quando o review chega a 'completed'. Se a persistência falhar, o review vira 'failed' e a reserva é liberada; o beat securecode.reap faz o mesmo com review preso em 'running' por mais de 15 minutos. Uma falha interna do SAST ou da IA não derruba o review: ela é registrada no log, a camada que falhou entrega zero achado e o review completa — e cobra — assim mesmo. Review disparado por PR não tem hold (fica em assinatura).
-
Triagem do achado
PATCH no achado move entre open, accepted, resolved e false_positive, com resolved e false_positive terminais, sob Idempotency-Key e com auditoria.
-
Webhook com HMAC verificado
A assinatura do provedor é validada em tempo constante: X-Hub-Signature-256 no GitHub, X-Gitlab-Token no GitLab. Segredo indecifrável, ausente ou assinatura divergente resultam em 401. Eventos que não são PR/MR são aceitos e ignorados sem criar review.
Entregáveis
- Tela de repositórios conectados em /app/securecode, com a política de envio de código à IA visível por repo
- Lista de revisões em /app/securecode/revisoes com status, modelo usado e resumo do resultado
- Lista de achados em /app/securecode/achados com CWE, referência OWASP, severidade, arquivo:linha, explicação e correção sugerida em português
- Achados de severidade média ou acima já dentro do Vuln Tracker (portal_vulnerabilities, source='import')
- Trilha de auditoria em audit_log e movimentação de crédito rastreável (hold, capture, release)
O que este módulo não faz
A revisão analisa o diff que você ENVIA no corpo da requisição. O produto não clona repositório, não busca arquivo e não lê a árvore do projeto: o token do provedor é guardado cifrado, mas nenhum código o usa para buscar código. A consequência é direta e está documentada no próprio serviço: uma revisão disparada por webhook de PR entra com diff vazio e termina com zero achados. Além disso, a rota POST /securecode/webhook/{repo_id} depende de CurrentContext, ou seja, exige um JWT válido além do HMAC do provedor — GitHub e GitLab não enviam esse cabeçalho, então o gatilho por pull request não é utilizável por um provedor real hoje. O produto também não escreve de volta no provedor: não comenta no PR, não cria check nem status de commit. O SAST determinístico são sete regras de expressão regular aplicadas linha a linha: não há AST, não há análise de fluxo de dados, não há SCA/análise de dependências, não há varredura de infraestrutura como código nem de histórico do repositório. A revisão humana obrigatória nos achados críticos é descrita na documentação do módulo mas não é imposta pelo código: a triagem do achado é livre e nada bloqueia a promoção de um crítico. A flag JC_SECURECODE_ENABLED está declarada na configuração mas nenhum código do módulo ou do worker a lê — o controle de acesso real é o escopo RBAC, não uma chave de desligamento.
Declaramos o limite porque software de segurança que promete tudo não é auditável. Se o que falta aqui é o que você precisa, o serviço consultivo cobre — ou dizemos que não cobre.
Conecta com
- Gateway de IA da plataforma (task securecode_review, classe SENSITIVE)
- Outbox transacional + worker Celery (securecode.review.requested → securecode.review, fila default)
- Vuln Tracker do portal (portal_vulnerabilities) pela promoção automática
- Carteira de créditos da plataforma (hold, capture, release)
- Cifragem de segredos da plataforma (pii_encrypt/pii_decrypt), RBAC, RLS FORCE, audit_log e Idempotency-Key
Controle de acesso
O acesso é concedido por escopo, não por perfil genérico. Quem só precisa ler não recebe permissão de escrita, e a barreira é o banco de dados, não a interface.
- securecode:repo:read
- securecode:repo:write
- securecode:review:read
- securecode:review:write
- securecode:finding:read
- securecode:finding:write
Quer ver funcionando?
Demonstração com dado do seu ambiente, não com base de exemplo. É a única forma de saber se serve.