Auditoria de código-fonte
Ler o código como um atacante, antes de ele o fazer.
Revemos o código-fonte das suas aplicações à procura de falhas de segurança: com ferramentas de análise, com apoio de inteligência artificial e, sobretudo, com pessoas que desenvolvem e mantêm sistemas e confirmam cada achado antes de o reportar.
- PHP, Python, JS/TS, Java e C#
- Cada achado confirmado por uma pessoa
- Código tratado na UE
Para decisores
O que é uma auditoria de código, em linguagem simples.
Um teste de penetração ataca a aplicação por fora. Uma auditoria lê-a por dentro, linha a linha nos pontos críticos, e encontra falhas que nenhum ataque externo chegaria a revelar.
- Encontra a causa, não só o sintoma. Cada achado indica o ficheiro, a linha e a correção.
- Vê o que não está exposto. Funcionalidades internas, permissões e integrações também são revistas.
- Acontece antes do problema. Pode ser feita antes de a aplicação entrar em produção.
- Deixa a equipa mais forte. Os achados explicam o padrão a evitar, não apenas o caso.
Por dentro
Lemos o código, as dependências e a configuração.
Sem falsos alarmes
Só reportamos o que confirmámos.
Com correção
Cada falha vem com a forma de a fechar.
Com reteste
Confirmamos que a correção resolveu o problema.
O que procuramos
As falhas que mais vezes abrem a porta.
Seguimos as categorias do OWASP Top 10 e verificamos os requisitos do OWASP ASVS adequados a cada aplicação.
-
Autenticação e sessões
Palavras-passe, recuperação de conta, autenticação multifator e gestão de sessões.
-
Autorização
Se cada utilizador só acede aos seus dados e às funções que lhe cabem.
-
Injeção e validação
Dados vindos de fora que chegam a consultas, comandos ou páginas sem validação.
-
Segredos no código
Chaves, palavras-passe e credenciais de acesso esquecidas no código ou no histórico.
-
Criptografia
Algoritmos fracos, chaves mal guardadas e dados sensíveis sem cifra.
-
Envio de ficheiros
Ficheiros carregados que podem ser executados, sobrepor outros ou esgotar recursos.
-
Registos e erros
Erros que revelam informação interna e ações importantes que não ficam registadas.
-
Dependências
Bibliotecas e componentes com falhas conhecidas, como o caso PHP2Shell.
Como trabalhamos
Das ferramentas às pessoas, em seis passos.
-
Preparação
Acesso ao repositório, arquitetura e identificação dos fluxos críticos com a sua equipa.
-
Análise automática
Análise estática e das dependências, para cobrir todo o código e encontrar falhas conhecidas.
-
Análise com IA
Ferramentas de IA seguem os dados desde a entrada até às operações sensíveis e sinalizam candidatos.
-
Revisão manual
Autenticação, permissões, pagamentos e dados pessoais revistos à mão por quem conhece o padrão.
-
Confirmação
Cada candidato é reproduzido num ambiente de teste; o que não se confirma não entra no relatório.
-
Relatório e apresentação
Achados por gravidade, com correção proposta, apresentados à equipa técnica e à direção.
Exemplo ilustrativo
Um achado, do problema à correção.
Cada achado do relatório explica o que está errado, onde, porque importa e como se corrige. Veja como é um relatório completo.
- Descrição clara do problema, para quem programa e para quem decide.
- Localização exata: ficheiro, linha e funcionalidade afetada.
- Prova de que a falha existe, reproduzida num ambiente de teste.
- Impacto no serviço e nos dados, e gravidade medida com CVSS 4.0.
- Correção proposta, com o código antes e depois.
- Estado do reteste, atualizado quando a correção é aplicada.
// Achado A-03 · Gravidade: alta
// Ficheiro: pedidos/ver.php, linha 18
// Problema: o identificador vem do pedido sem validação
// e não se verifica a quem pertence o registo.
$sql = "SELECT * FROM pedidos WHERE id = " . $_GET['id'];
$pedido = $db->query($sql)->fetch();
// Correção: consulta parametrizada e verificação do dono.
$stmt = $db->prepare(
'SELECT * FROM pedidos WHERE id = ? AND utente_id = ?'
);
$stmt->execute([$_GET['id'], $utilizador->id]);
$pedido = $stmt->fetch();Linguagens e ferramentas
As tecnologias com que trabalhamos todos os dias.
Auditamos as linguagens e os frameworks que também usamos para desenvolver e manter sistemas.
- PHP, incluindo Laravel, Symfony e WordPress.
- Python, incluindo Django, Flask e FastAPI.
- JavaScript e TypeScript, no servidor com Node.js e nas aplicações web.
- Java, incluindo Spring.
- C#, incluindo .NET.
Semgrep
Análise estática do código, com regras públicas e regras próprias.
OWASP Dependency-Check
Dependências com vulnerabilidades conhecidas e publicadas.
Trivy
Dependências, contentores e ficheiros de configuração.
IA com revisão humana
Caminhos de dados suspeitos, sempre confirmados por uma pessoa.
Quando faz sentido
Os momentos certos para uma auditoria.
-
Antes de entrar em produção
Corrigir uma falha antes do lançamento custa muito menos do que depois de ser explorada.
-
Ao receber um sistema
Antes de assumir a manutenção de uma aplicação desenvolvida por outro fornecedor.
-
Depois de uma grande alteração
Uma nova integração, um novo módulo ou uma mudança de framework.
-
Na cadeia de fornecimento
Para avaliar a segurança do software dos fornecedores, como pede a NIS2.
O que recebe
Um relatório útil para quem decide e para quem corrige.
A auditoria só termina quando as falhas importantes ficam fechadas.
- Resumo executivo para a direção, com o nível de risco e as prioridades.
- Relatório técnico com todos os achados, provas e correções propostas.
- Reunião de apresentação com a equipa técnica ou com o seu fornecedor.
- Correções feitas por nós ou pela sua equipa, à sua escolha.
- Reteste e relatório final com o estado de cada achado.
Perguntas frequentes
Sobre a auditoria de código-fonte.
Precisam de acesso a todo o código?
Precisamos de acesso ao código da aplicação a auditar e das suas configurações, de preferência ao repositório com o histórico. O histórico ajuda a encontrar segredos que foram apagados do código mas continuam guardados.
O nosso código sai das nossas instalações?
Só se concordar. O código é tratado na União Europeia, através dos nossos parceiros, ou nas suas instalações, apagado no fim do trabalho e nunca usado para treinar modelos de IA.
Quanto tempo demora uma auditoria?
Depende da dimensão e da complexidade da aplicação. Uma aplicação de dimensão média demora normalmente entre duas e três semanas, do acesso ao código ao relatório.
Auditam código desenvolvido por outro fornecedor?
Sim, com a autorização do dono do sistema. Podemos apresentar os achados ao fornecedor e apoiá-lo nas correções, ou fazer nós as correções quando o contrato e a licença o permitem.
A auditoria substitui um teste de penetração?
Não, complementam-se. A auditoria encontra falhas no código; o teste de penetração confirma o que um atacante consegue explorar na aplicação em funcionamento, incluindo a configuração do servidor.
Quer saber o que o seu código esconde?
Conte-nos que aplicação quer auditar e propomos um âmbito e um preço fechados.