Uma auditoria que pode entregar a um regulador
Lemos a sua aplicação como a leria um atacante, linha a linha, e medimo-la contra um referencial normativo que declaramos à partida. Cada falha é depois entregue a um segundo revisor, que não vê como se chegou a ela e cuja instrução é refutá-la. O que resiste entra no relatório, com pontuação, evidência e a ligação às obrigações regulatórias pelas quais tem de responder.
É revisão manual do código fonte, não uma corrida de scanner com um logótipo na capa. As ferramentas localizam candidatos; a conclusão vem sempre de ler o ficheiro e seguir a cadeia de chamadas. Uma falha que não foi confirmada pela leitura não entra no relatório.
Contra o que medimos
O referencial é declarado antes de a auditoria começar, e a versão de cada norma é reconfirmada no início e registada no cabeçalho do relatório. As normas mudam, e um relatório que cita uma edição revogada perde a autoridade.
OWASP ASVS 5.0.0
Norma de verificação. Nível 2 por omissão, nível 3 nos módulos que o justifiquem. Cada falha cita o requisito que não cumpre.
OWASP Top 10:2025
Categorização do risco aplicacional, pela edição em vigor e não pela que toda a gente ainda cita.
OWASP API Security Top 10 2023
Uma passagem dedicada, com o seu próprio mapa de cobertura, quando a aplicação expõe serviços.
OWASP Top 10 for LLM Applications 2025
Uma lente condicional, aplicada quando a aplicação integra um modelo.
CWE e CWE Top 25 (2025)
Identificação da fraqueza. O Top 25 orienta a priorização, não a substitui.
CVSS v4.0
Pontuação e vetor completo por falha, calculados de forma determinística e não estimados.
EPSS e CISA KEV
Priorização das dependências, onde a exploração conhecida pesa mais do que uma pontuação teórica.
CycloneDX 1.6 ou SPDX 3.0.1
Lista de componentes de software (SBOM), no mínimo na versão exigida pela BSI TR-03183-2.
Ligada às obrigações pelas quais responde
Uma falha técnica raramente chega sozinha a uma administração. Cada uma fica ligada ao identificador da medida de cibersegurança que toca, o que transforma o relatório de um argumento técnico num argumento de conformidade. É nessa forma que ele circula de facto.
Na União Europeia, disposição a disposição
O artigo 21.º da NIS2 e o seu Regulamento de Execução (UE) 2024/2690, com o DORA para o setor financeiro.
| Disposição | O que exige | O que a auditoria entrega |
|---|---|---|
| §6.10Reg. (UE) 2024/2690 | Obter informação sobre vulnerabilidades técnicas, avaliar a exposição a elas e geri-las. | O relatório é o registo documentado das vulnerabilidades encontradas, cada uma com a sua exposição e severidade. |
| §6.5Reg. (UE) 2024/2690 | Testes de segurança segundo uma metodologia documentada, com registo do tipo, âmbito, data e resultados, e a criticidade e a ação de mitigação de cada falha. | Uma metodologia declarada, uma tabela de cobertura, e a severidade e a correção recomendada de cada falha: esse registo, pronto a arquivar. |
| §6.2Reg. (UE) 2024/2690 | Regras de desenvolvimento seguro, aplicadas internamente e quando o desenvolvimento é subcontratado, em todas as fases até aos testes. | Um teste independente de que essas regras se cumpriram, lido no próprio código. |
| Art. 21.º, n.º 2, al. d), e n.º 3NIS2 | Segurança da cadeia de abastecimento, tendo em conta as práticas de cibersegurança e os procedimentos de desenvolvimento seguro de cada fornecedor. | Uma auditoria ao código que o fornecedor entrega é a evidência por trás dessa avaliação. |
| Art. 21.º, n.º 2, al. f)NIS2 | Políticas e procedimentos para avaliar a eficácia das medidas de gestão dos riscos de cibersegurança. | Uma auditoria externa é essa avaliação, feita sobre o código e não sobre o papel. |
| Art. 25.º, n.º 1DORA | Um programa de testes de resiliência operacional digital que inclua revisões do código fonte quando tal for exequível. | Uma revisão do código fonte, numa forma que o programa de testes pode arquivar. |
| §12.2Reg. (UE) 2024/2690 | Tratamento dos ativos até à sua eliminação, incluindo o apagamento irrecuperável e a destruição da informação. | No appliance, um certificado de eliminação segura no fim do trabalho, assinado pelas duas partes. |
O Regulamento de Execução (UE) 2024/2690 vincula diretamente os prestadores de infraestruturas digitais, de serviços de TIC e de serviços digitais, e para todos os outros setores é a leitura mais detalhada do artigo 21.º.
A par da NIS2
RGPD, artigos 9.º e 32.º
Categorias especiais de dados e segurança do tratamento, quando a aplicação os trata.
Regulamento Ciber-Resiliência
Quando um componente vem de um fornecedor externo, o relatório assinala o que o regulamento lhe vai exigir.
Transposições nacionais da NIS2
Quando um Estado-membro publica o seu próprio catálogo de medidas, cada falha leva também esse código. Em Portugal é o Regime Jurídico da Cibersegurança (RJC), Decreto-Lei n.º 125/2025, em vigor desde 3 de abril de 2026, com o Regulamento n.º 756/2026 do CNCS, cujo Anexo IV fixa as medidas de cibersegurança mínimas por grupo de entidades.
Em Portugal, as entidades públicas e as restantes entidades abrangidas registam-se junto do CNCS na plataforma MyCiber, e as medidas de cibersegurança mínimas aplicam-se a partir de 22 de junho de 2028, 24 meses após o Regulamento n.º 756/2026. Uma auditoria face ao Anexo III, ou ao Anexo IV no caso das entidades públicas, diz-lhe onde está enquanto ainda há tempo para agir sobre a resposta.
Cada falha é atacada antes de a ver
Cada falha vai para um segundo revisor, que recebe apenas o ficheiro, as linhas citadas, a afirmação e a descrição da exposição. Não vê como o primeiro revisor lá chegou, e a instrução que tem é refutá-la. O que é refutado cai; o que resiste com uma severidade diferente segue para reconciliação.
Isto existe porque o autor de uma falha é o pior juiz da sua própria linha de código, e num relatório que vai ser lido por uma parte externa uma cadeia de chamadas inventada custa muito mais do que a falha vale. A refutação cumpre o mesmo critério: um revisor que descarta uma falha por não ter encontrado alguma coisa tem de mostrar como procurou.
Duas afirmações, não uma
A auditoria diz o que está mal e diz também o que foi examinado e está correto, com o padrão de pesquisa à vista. Sem a segunda metade, ninguém distingue "isto não existe" de "ninguém viu", e a auditoria seguinte volta a pagar terreno já coberto.
A mesma disciplina produz a tabela de cobertura do ASVS, capítulo a capítulo de V1 a V17, com o que foi verificado, o que passou, o que falhou e o que não pôde ser confirmado, e porquê. É essa tabela que sustenta qualquer afirmação de que a auditoria foi completa, e é a primeira coisa que uma nova auditoria consulta.
Como corre a auditoria
Revisão manual do código fonte, não uma corrida de scanner: as ferramentas localizam candidatos, as conclusões vêm de ler o ficheiro e seguir a cadeia de chamadas
Verificação adversarial às cegas de cada falha, por um segundo revisor instruído a refutá-la, para que falhas plausíveis mas erradas nunca lhe cheguem
Duas afirmações, não uma: o que está mal, e o que foi examinado e está correto, com o padrão de pesquisa à vista
Uma tabela de cobertura do ASVS, capítulo a capítulo de V1 a V17, com o que foi verificado, o que passou, o que falhou e o que não pôde ser confirmado
Falhas ligadas às medidas de cibersegurança pelas quais responde, que é a forma que o argumento tem de ter para chegar a uma administração
Uma folha de rotação de credenciais com ordem, responsável, dependências e janela sugerida, para que o relatório seja trabalho que se executa
Só leitura, do princípio ao fim: nada no seu repositório é alterado, criado ou apagado, e não se executa nenhum build
Anatomia de uma falha
Cada entrada do relatório responde às mesmas perguntas: o que é, onde está, o que implica e como se corrige.
Onde está
src/auth/session.py, linhas 118 a 142, e o pedido de saída na camada web.
Severidade
Alta, em CVSS v4.0, com o vetor completo registado e a pontuação calculada a partir dele.
O que acontece
Sair apaga o cookie no browser, mas o servidor continua a aceitar o identificador até este expirar.
Correção recomendada
Invalidar a sessão no servidor no momento do pedido, e não apenas no browser. Conforme o âmbito contratado.
Impacto
Um identificador copiado antes da saída continua a dar acesso à conta, mesmo depois de o utilizador julgar que saiu.
Conformidade
O requisito de gestão de sessões do OWASP ASVS 5.0, e a medida NIS2 que toca, nas regras nacionais que se lhe aplicam.
Exemplo ilustrativo.
O que recebe
Três documentos, porque três pessoas diferentes têm de agir sobre isto e não podem ler todas o mesmo.
O relatório para a administração é escrito de raiz e não leva credenciais, caminhos de ficheiros nem código. O relatório técnico leva tudo, incluindo os segredos por inteiro, porque a folha de rotação de credenciais precisa deles e mascarar um segredo já exposto não protege nada e dificulta a correção. Circula com acesso restrito. A estimativa do esforço de correção destina-se a quem decide a contratação, e declara os seus pressupostos e o que fica fora do âmbito.
Faça-a por si: a auditoria como software
As mesmas lentes, o mesmo processo de verificação e o mesmo motor de relatórios, numa aplicação.
O Goshawk é esta auditoria transformada em produto. Cria uma auditoria sobre os seus repositórios, escolhe o perfil de conformidade e corre a análise automática quando quiser, com a sua limitação declarada por escrito no próprio relatório, ou encomenda o nível completo, em que os nossos revisores seniores conduzem a verificação e o relatório tem um SLA. Uma análise self-service nunca se apresenta como equivalente a uma auditoria revista; essa honestidade é a primeira funcionalidade do produto.
Que auditoria
Quatro formas de auditar o seu código, e quando serve cada uma.
| Opção | O que revê | Quem verifica | O que recebe | Escolha-a quando |
|---|---|---|---|---|
| Auditoria de segurançaesta página | As aplicações que indicar, segundo o OWASP ASVS 5.0, nível 2 por omissão. | Os nossos revisores, com uma segunda revisão às cegas que tenta refutar cada falha. | Três documentos: para a administração, o relatório técnico completo e a estimativa do esforço de correção. | Um regulador, um auditor ou uma administração tem de aceitar o resultado, e há pessoas que respondem por ele. |
| Goshawkanálise automática | Os seus repositórios, quando quiser e as vezes que quiser. | Só a aplicação: as mesmas lentes e a mesma etapa de refutação, sem revisão humana. | Um relatório que declara por escrito o que uma análise não revista pode e não pode afirmar. | Quer a varredura sistemática em horas, entre auditorias ou a cada versão. |
| Goshawkauditoria completa | Os seus repositórios. | Os nossos revisores seniores conduzem a fila de verificação e reconciliam as falhas contestadas. | O relatório revisto, com um SLA em dias. | Quer o rigor da auditoria no seu calendário, através da aplicação. |
| Ibexpilar de código | Os repositórios Git da rede onde o Ibex está, como uma cópia imutável, sem ligação ao exterior. | O appliance, no seu hardware; o código nunca sai dele. | Falhas em SARIF, ligadas ao host onde o código corre. | O código não pode sair do edifício e o Ibex já vigia essa rede. |
Quando o código não pode sair do edifício
Quando a sensibilidade dos dados o justifica, a auditoria corre inteiramente dentro do seu perímetro, em hardware que levamos ou em hardware que já tem, com modelos de pesos abertos e sem caminho para qualquer serviço externo. Nada do seu código, da sua configuração ou das suas falhas sai do ambiente. Corre no appliance Ibex, a mesma disciplina de contenção do Marmot, aplicada à própria auditoria.
Dizemos-lhe também o que o perímetro fechado custa em capacidade de auditoria, porque isso importa mais do que a tranquilidade. A leitura sistemática aguenta-se bem em modelos locais: reconhecer padrões num código extenso é aquilo em que são bons. O que se degrada primeiro é o juízo, e é no juízo que está o valor: calibrar a severidade face à exposição real, recusar uma cadeia de ataque atraente porque o código não sustenta um dos elos, perceber que as vulnerabilidades conhecidas de uma dependência não são alcançáveis nesta aplicação em vez de as somar à contagem. Para trabalho que vai ser contestado por um fornecedor, dizemo-lo com clareza e acordamos consigo a divisão à partida, em vez de a descobrir no relatório.
Três formas de a correr
As mesmas lentes, a mesma verificação e o mesmo relatório, onde quer que a auditoria corra. O que muda é onde está o seu código e que modelos o leem.
Appliance air-gapped
Uma caixa selada, em hardware próprio, dentro do seu perímetro. Todos os modelos correm no appliance, e a única coisa que sai é o relatório, nos seus suportes. Para código que não pode sair do edifício.
Instância na cloud
Uma instância só sua, operada por nós, uma por cliente e nunca partilhada. Nada a instalar e nenhum hardware no local, com todas as etapas da auditoria em modelos de fronteira. Para equipas que querem a auditoria a pedido.
Híbrida
Uma instância na cloud em que as lentes leem todo o código num modelo alojado por nós, e só a verificação e a redação seguem para um modelo de fronteira, que vê cada afirmação e as linhas que cita, e não o repositório.
O appliance nunca funciona em modo híbrido, e nenhuma definição o permite. Todo o seu argumento é que o código fica na caixa, e um argumento que uma definição desfaz é apenas uma definição.
Como corre o trabalho no local
Em modo air-gapped, o appliance chega, trabalha nas suas instalações e sai sem levar nada consigo.
Início
- Um disco de dados novo, instalado na presença da sua equipa de segurança.
- Cifrado com uma frase-passe escrita pela sua equipa.
- Código copiado do repositório, ou de um suporte amovível montado só em leitura.
- O identificador da versão, ou um hash do conteúdo, registado perante a sua equipa.
Durante
- Uma auditoria autónoma, operada apenas a partir do ecrã e do teclado locais.
- Nada do trabalho é escrito no disco de sistema.
- Um registo de auditoria encadeado por hash, no disco de dados.
- Enviado para o seu SIEM, quando há rede e assim o pede.
Fim
- O relatório entregue nos seus suportes, com o hash no registo de entrega.
- O disco de dados, a chave de cifra e o registo de auditoria ficam consigo.
- O disco de sistema apagado de forma segura perante a sua equipa, com um certificado NIST SP 800-88 Rev. 2 assinado pelas duas partes.
- O appliance sai com esse disco vazio, ou sem disco nenhum se preferir ficar com ele depois de apagado.
Onde se aplica
Entidades públicas a posicionarem-se face às medidas de cibersegurança mínimas do regime nacional
Organizações reguladas que precisam de um registo de auditoria aceite por um auditor externo ou pelo supervisor
Due diligence a uma aplicação entregue por um fornecedor, antes da aceitação ou da renovação
Ambientes classificados ou sensíveis, onde a auditoria tem de correr dentro do perímetro
O software por trás da auditoria
O Goshawk corre a própria auditoria. O Ibex e o Marmot são as plataformas para os ambientes onde nada pode tocar na internet.
Goshawk
Só sai o que resiste à refutação
Auditorias de segurança aos seus repositórios, como aplicação: análise automática com os limites declarados por escrito, e um nível completo com verificação humana sénior.
Saber mais sobre Goshawk
Ibex
Segurança para as redes onde a cloud não chega
Gestão da superfície de ataque em air-gapped (rede isolada): rede, código, IA e bases de dados avaliados a partir de um appliance selado dentro do seu perímetro, com cada falha ligada ao host onde corre.
Saber mais sobre Ibex
Marmot
IA soberana, com uma porta de controlo
IA nas suas instalações, com uma porta que decide, pedido a pedido, o que pode chegar a um modelo na cloud e o que nunca sai do edifício.
Saber mais sobre Marmot