Gestão de vulnerabilidades open source: o que podes pôr a funcionar por tua conta antes de uma auditoria SOC 2 ou ISO 27001

O que é a gestão de vulnerabilidades open source?

A gestão de vulnerabilidades é o ciclo que corre depois da deteção: juntar os achados de todos os scanners, eliminar duplicados, priorizá-los, dar a cada um um responsável e um prazo, corrigi-lo ou aceitá-lo, e guardar a prova. A versão open source monta esse ciclo com ferramentas gratuitas que alojas tu, em vez de uma plataforma comercial.

Os scanners são a parte fácil, e já os testámos: ferramentas SCA open source num mesmo repositório e scanners de segredos open source lado a lado. O que não te dão é memória. A 3 de novembro de 2026 corremos o Trivy, o Gitleaks e o Opengrep sobre o OWASP Juice Shop para o nosso guia de scans para o SOC 2: 383 achados em quatro ficheiros JSON, e nenhum trazia um commit, um responsável, um prazo ou um estado. É essa lacuna que a camada de gestão preenche.

O que pedem o SOC 2 e a ISO 27001?

Nenhum dos dois referenciais nomeia uma ferramenta. O critério CC7.1 do SOC 2 pede que detetes as vulnerabilidades novas e a tua exposição às que acabam de ser descobertas. O controlo A.8.8 da ISO 27001:2022 pede que obtenhas informação sobre as vulnerabilidades técnicas, avalies a tua exposição e ajas. Ambos deixam os prazos à tua política, e depois verificam se os cumpriste.

A redação do SOC 2, tal como as empresas de auditoria a reproduzem, pede procedimentos de deteção e monitorização para identificar, por um lado, as alterações de configuração que introduzem vulnerabilidades novas e, por outro, a exposição a vulnerabilidades acabadas de descobrir. O Anexo A 8.8 da ISO 27001, Gestão de vulnerabilidades técnicas, começa por dizer que deve ser obtida informação sobre as vulnerabilidades técnicas dos sistemas de informação em uso, e depois pede uma avaliação da exposição e as medidas adequadas. A HighTable, uma consultora de ISO 27001, nota que a norma não impõe um número de horas: os prazos de correção vêm de um acordo de nível de serviço que defines tu por severidade.

Por isso, o auditor lê primeiro a tua política, depois escolhe uma amostra de achados e confronta cada um com ela. O nosso guia sobre o que os auditores de ISO 27001 e SOC 2 pedem quando são agentes de IA a escrever o código cobre os controlos de desenvolvimento seguro à volta, do A.8.25 ao A.8.29.

Que ferramenta open source cobre cada parte?

Cada ferramenta abaixo cobre uma parte do ciclo, e o registo ao centro é a peça mais fácil de saltar.

O Dependency-Track responde a «quais das nossas aplicações levam um componente que acabou de ficar vulnerável?», e um registo responde a «em que estado está cada achado, de cada ferramenta, e ainda está dentro do prazo?». O DefectDojo é um registo que alimentas com a exportação de cada scanner, enquanto o CybeDefend Open Source corre ele próprio os scanners e enche a sua fila em cada execução, sem exportações nem importações pelo meio.

DefectDojo não faz scans: importa o que as outras ferramentas exportam, elimina duplicados e acompanha o estado de cada achado. Tem uma Community Edition gratuita para alojares por tua conta, sob a licença BSD-3-Clause, e uma edição Pro paga, e o seu repositório inclui parsers para o Trivy, o Grype, o OSV-Scanner, o Gitleaks, o Semgrep, o SARIF e o Dependency-Track, entre outros.

OWASP Dependency-Track define-se como uma plataforma inteligente de análise de componentes. Monitoriza a utilização de componentes em todas as versões de cada aplicação do seu portefólio, consome e produz SBOM e VEX CycloneDX, e vai buscar dados de vulnerabilidades à NVD, às GitHub Advisories, ao OSV e a outras fontes. A versão 5.2.1 saiu a 25 de outubro de 2026.

OpenCVE cobre uma lacuna que as outras deixam. Permite-te monitorizar os teus fabricantes e produtos e receber os alertas de CVE relevantes, encaminhados para email, Slack ou webhooks segundo regras que tu defines, com o contexto CVSS, EPSS e KEV combinado em sinais de risco claros. Não é um scanner SCA e não lê os teus lockfiles. O seu lugar é a vigilância entre dois scans, e o software que fica fora dos teus repositórios: o motor de base de dados, a VPN, o runner de CI. O OpenCVE funciona como serviço na cloud com um plano gratuito, ou nos teus próprios servidores nos termos da sua licença, que exigem uma licença comercial para uso comercial on-premise.

Que achados escolhe o auditor para a amostra?

O auditor escolhe achados do período e segue cada um: quando foi encontrado, em que commit ou ativo, quem era o responsável, que prazo a tua política fixava para a severidade dele e como fechou. Uma correção precisa da alteração que a fez. Um risco aceite precisa de um motivo, de um aprovador e de uma data de expiração.

Ao longo de um período SOC 2 Type II, ou entre duas auditorias de acompanhamento da ISO 27001, esse rasto tem de existir durante meses, e não só na semana antes da auditoria. Três registos sustentam esse rasto:

• A política: severidades, prazos por severidade, quem pode aceitar um risco e por quanto tempo.
• O registo: cada achado com as suas datas, o responsável, o estado e a ligação ao scan que o produziu.
• As exceções: cada risco aceite com o seu âmbito, a justificação, o aprovador e a data de expiração.

Quanto custa realmente fazê-lo por tua conta?

As ferramentas são gratuitas. O trabalho não é: alojar e atualizar o registo, manter os parsers alinhados com o output dos scanners, fazer corresponder as severidades aos teus prazos e fazer a triagem todas as semanas para que o registo continue fiel à realidade. Cada scanner e o registo lançam as suas próprias versões, e alguém da tua equipa tem de as ir aplicando.

Essa troca compensa muitas vezes numa equipa com um platform engineer e poucos repositórios. Fica mais difícil quando o número de repositórios e o ritmo das alterações aumentam, porque o registo só vale o que vale a última triagem.

O que muda quando são agentes de IA a escrever o código?

Agentes de programação como o Claude Code, o Cursor, o GitHub Copilot e o OpenAI Codex aumentam o número de alterações por semana, por isso os achados chegam mais depressa e o registo tem de acompanhar. Dois registos passam a pesar mais: o scan de cada alteração antes do merge, e a pessoa que aprovou a alteração escrita por um agente.

O agente que escreve o código também pode correr a auditoria. Com o CybeDefend Open Source, o /cybedefend corre os scanners AppSec a partir do agente de programação em cada alteração, depois manda esse mesmo agente procurar as falhas que eles não veem e faz com que prove cada uma com um exploit escrito como teste. Cada achado entra na fila com o scan que o produziu, e o registo acompanha o ritmo dos agentes. O agente também pode propor a correção, e mesmo assim o registo deve mostrar quem a reviu e fez o merge, porque o que o auditor põe na amostra é a aprovação, e não o patch. O nosso guia SOC 2 sobre scans e testes de intrusão mostra como um achado passa do scan de uma alteração para o relatório do período.

Onde entra a CybeDefend?

O CybeDefend Open Source chega em breve, e foi feito para o ciclo que este guia descreve. Um comando no teu agente de programação, /cybedefend, faz uma auditoria completa em duas camadas. Primeiro os scanners AppSec, open source, com um docker compose up, entre eles o Opengrep, o Trivy, o Gitleaks e o zizmor, para o código, as dependências, os segredos, a infraestrutura como código, o CI/CD e os contentores. Ficas com os que quiseres e acrescentas os teus. Depois, o scanner de IA, executado pelo teu agente de programação. Os scanners procuram padrões. O scanner de IA lê o que o teu código devia fazer e encontra onde falha, na lógica de negócio, nos direitos de acesso e nas falhas que só aparecem quando o código corre, e prova cada falha com um exploit escrito como teste.

Por baixo das duas camadas está toda a nossa plataforma, um ASPM agêntico, a mesma que já alojamos como CybeDefend Cloud. É ela que mantém o registo: os achados de todos os scanners numa única fila sem duplicados, e uma política de segurança escrita como código que bloqueia o merge perante um achado crítico, com cada exceção delimitada, datada, justificada e aprovada por nome. Os relatórios de segurança fazem corresponder os achados ao OWASP Top 10 e ao CWE Top 25, e exportam-se em PDF para o auditor ou em JSON para uma ferramenta de GRC. Também estamos a passar por este exercício: a nossa auditoria SOC 2 Type II está em curso. Se estás a preparar a tua, podemos percorrê-la contigo. Para correres a auditoria no teu próprio código assim que abrir, entra na lista de espera do CybeDefend Open Source.

Perguntas frequentes

O DefectDojo é gratuito?

A Community Edition do DefectDojo é open source, sob a licença BSD-3-Clause, e podes alojá-la gratuitamente. O DefectDojo também vende uma edição Pro, na cloud ou on-premise. A Community Edition importa achados, elimina duplicados e acompanha estados; antes de planeares à volta dela, confirma na página das edições as funcionalidades de que precisas.

Qual é a melhor ferramenta open source de gestão de vulnerabilidades?

Depende do trabalho. O Dependency-Track vigia componentes através de SBOM. O DefectDojo mantém um registo de achados importados de muitos scanners. O OpenVAS analisa hosts e redes. O CybeDefend Open Source encadeia os scanners AppSec e um scanner de IA executado pelo teu agente de programação, e mantém uma única fila sujeita às tuas políticas. Para uma auditoria, uma montagem comum junta um conjunto de scanners e um único registo.

A ISO 27001 obriga a fazer scans de vulnerabilidades?

O controlo A.8.8 não fala em scans. Pede que obtenhas informação sobre as vulnerabilidades técnicas, avalies a tua exposição e tomes as medidas adequadas. Os scans regulares são a forma habitual de mostrar as duas primeiras, e é a tua política que define a frequência.

Que prazos de correção de vulnerabilidades se usam na ISO 27001?

A norma não define nenhum. Defines tu os prazos na tua política, por severidade, e o auditor verifica se os cumpriste. A HighTable indica um calendário que, segundo ela, os auditores aceitam de forma generalizada: 48 horas para as críticas, 7 dias para as altas, 30 dias para as médias e 90 dias para as baixas.

O OpenCVE serve para procurar vulnerabilidades no meu código?

Não. O OpenCVE monitoriza a publicação de CVE dos fabricantes e produtos que segues e avisa-te por email, Slack ou webhook, com o contexto CVSS, EPSS e KEV. Não lê o teu código nem os teus lockfiles, por isso funciona ao lado de um scanner SCA e não o substitui.

Existe uma versão open source da CybeDefend?

A sua edição open source, o CybeDefend Open Source, chega em breve: toda a nossa plataforma, um ASPM agêntico, gratuita nos teus próprios servidores. O comando /cybedefend encadeia os scanners AppSec open source e um scanner de IA executado pelo teu agente de programação, e põe cada achado numa única fila sujeita às tuas políticas. Até lá, o CybeDefend Cloud é a mesma plataforma, alojada por nós. Entra na lista de espera do CybeDefend Open Source.