VEX e CSAF: evidência auditável de vulnerabilidades

O aviso das 07:40 que transforma uma SBOM num problema para o conselho de administração

Às 07:40 de uma terça-feira de manhã, no início de 2026, Anya, a CISO de uma plataforma FinTech em rápido crescimento, recebe um aviso crítico de fornecedor em formato CSAF. Foi identificada uma vulnerabilidade de execução remota de código numa biblioteca de código aberto amplamente utilizada. A sua lista de materiais de software (SBOM) confirma que a biblioteca está incorporada na aplicação principal de processamento de pagamentos, em dois serviços internos e num componente de analítica subcontratado.

Às 08:10, o telefone começa a tocar sem parar. A engenharia quer saber se a função vulnerável é alcançável. A conformidade quer saber se isto afeta a ISO/IEC 27001:2022, a NIS2 ou o DORA. A equipa jurídica pergunta se o Regulamento da Ciber-Resiliência pode exigir comunicação a clientes ou autoridades. Um membro do conselho de administração, recentemente formado em responsabilização da gestão no âmbito da NIS2, coloca a pergunta que todos têm em mente:

Estamos afetados?

A primeira resposta da engenharia é tecnicamente honesta: o pacote existe, mas a função vulnerável pode não ser chamada em produção. Em 2026, essa resposta não chega.

O conselho de administração quer evidência. Os clientes querem uma resposta clara. As compras querem saber se o fornecedor cumpriu as obrigações contratuais de divulgação. O Encarregado da Proteção de Dados (DPO) quer saber se dados pessoais podem estar expostos. Um auditor ISO 27001 não aceitará “foi o programador que disse” como evidência retida. Um auditor DORA esperará que a vulnerabilidade esteja ligada a ativos de TIC, funções críticas e dependências de terceiros.

É aqui que VEX e CSAF deixam de ser formatos técnicos e passam a ser infraestrutura de governação.

CSAF, o Common Security Advisory Framework, estrutura avisos de vulnerabilidades para que pessoas e máquinas possam processar produtos afetados, versões, orientação de remediação, referências e informação de estado. VEX, o Vulnerability Exploitability eXchange, fornece a camada de decisão. Indica às partes interessadas se uma vulnerabilidade conhecida é efetivamente explorável num produto, serviço ou ambiente específico.

Os estados práticos em VEX são simples: afetado, não afetado, corrigido e em investigação. A governação por trás deles não é simples. Cada estado exige evidência, responsável, justificação, aprovação e gatilho de revisão.

A lacuna de conformidade já não é a ausência de SBOM. Muitas organizações já têm SBOM. A lacuna está em demonstrar como cada aviso de vulnerabilidade foi triado, quem aprovou a decisão de estado, que evidência sustentou uma conclusão de “não afetado”, como a remediação foi priorizada quando o produto estava “afetado” e como a organização preservou esse trilho para auditores, reguladores, clientes e gestão.

A Clarysec trata VEX e CSAF como parte do modelo operacional do SGSI. Em Zenith Blueprint: roteiro de 30 etapas para auditores, isto enquadra-se nas fases de gestão de riscos, segurança de fornecedores, controlos tecnológicos e evidência. Em Zenith Controls: o guia de conformidade cruzada, o mesmo tema liga controlos da ISO/IEC 27001:2022 à segurança da cadeia de fornecimento de TIC, gestão de vulnerabilidades, tratamento de evidência, NIS2, DORA, GDPR e expectativas do NIST.

Porque as SBOM criam sinais, mas VEX cria evidência

Uma SBOM é uma lista de ingredientes. Diz o que existe dentro de um produto ou serviço. Quando uma CVE aparece num desses ingredientes, a SBOM indica que pode existir impacto.

Esse sinal é valioso, mas não é uma conclusão.

Um ambiente de software maduro pode gerar milhares de correspondências de vulnerabilidades em SBOM. Muitas representam riscos reais. Muitas não são exploráveis porque o código vulnerável não é distribuído, não é importado, não é alcançável, não está configurado, não está exposto a entradas não confiáveis ou está mitigado por controlos compensatórios. Sem um processo formal para registar a investigação, as equipas tendem a cair num de dois padrões negativos.

O primeiro é a exaustão da triagem. Os engenheiros perseguem cada correspondência de vulnerabilidade com a mesma urgência, mesmo quando o componente é uma dependência apenas de compilação, um caminho de código inativo ou uma funcionalidade apenas interna protegida por controlos em camadas.

O segundo é a aceitação do risco sem documentação. As equipas fecham tickets com comentários curtos como “não aplicável” ou “falso positivo”. Pode parecer eficiente, mas para um auditor é uma decisão não controlada. Para um regulador, pode parecer uma vulnerabilidade não gerida.

VEX e CSAF resolvem isto ao transformar ruído de vulnerabilidades em evidência de vulnerabilidades estruturada e auditável.

Um processo defensável de governação VEX e CSAF responde a cinco perguntas:

1. Recebemos ou identificámos o aviso?
2. Mapeámo-lo para produtos, ativos, fornecedores, clientes e fluxos de dados pessoais?
3. Determinámos o estado da vulnerabilidade com base em critérios definidos?
4. Documentámos a decisão, a evidência, o responsável, a aprovação e o gatilho de revisão?
5. Remediámos, divulgámos, monitorizámos ou preservámos evidência com base no risco?

A diferença entre “não afetado” e “ignorado” é a evidência.

Um estado VEX “não afetado” deve ser suportado por uma justificação, por exemplo: o componente vulnerável não está presente, a versão vulnerável não está implementada, o caminho de código vulnerável não é executado, a configuração vulnerável está desativada ou um controlo compensatório impede a exploração. “Em investigação” deve ter seguimento com prazo definido, não tornar-se um cemitério de backlog. “Corrigido” deve apontar para um patch, mitigação, atualização de versão, resultado de teste e registo de implementação. “Afetado” deve entrar em tratamento de riscos, planeamento de remediação, notificação de fornecedor, comunicação a clientes e, quando relevante, fluxos de avaliação de incidente ou violação de dados.

O modelo de governação da Clarysec para decisões de estado VEX

Cada aviso CSAF e cada declaração VEX deve ser tratado como um registo controlado dentro do SGSI, não como um artefacto isolado de engenharia. O fluxo de trabalho pode estar numa plataforma GRC, numa ferramenta de gestão de vulnerabilidades, num sistema de tickets, num fluxo de controlo de código-fonte ou num livro de evidências da Clarysec. O ponto essencial é que estado, evidência, aprovação e tratamento de riscos permaneçam ligados.

Esta tabela parece simples, mas altera o ambiente de controlo. Uma declaração “não afetado” torna-se uma pequena decisão de risco para um produto e ambiente específicos. Um estado “corrigido” liga a gestão de vulnerabilidades à gestão de alterações e aos testes. Um estado “afetado” aciona tratamento, escalonamento e possível divulgação. Um estado “em investigação” dá à gestão um risco visível e limitado no tempo.

Zenith Blueprint reforça esta abordagem na Etapa 13, sobre planeamento do tratamento de riscos e Declaração de Aplicabilidade. Explica que as decisões de controlo devem ser justificadas por tratamento de riscos, requisitos legais ou contratuais, relevância do âmbito e contexto organizacional:

“Na folha da SoA, marque cada controlo como ‘Sim’ (aplicável) ou ‘Não’ (não aplicável). Forneça uma Justificação/Notas.”

Para VEX, “não afetado” segue a mesma disciplina. Não é um encerramento casual de ticket. É uma decisão justificada que deve resistir a revisão.

A Etapa 19 do Zenith Blueprint aborda a gestão técnica de vulnerabilidades:

“Mantenha-se informado sobre novas falhas de segurança (através de alertas de fornecedores, feeds CVE, etc.) relativas ao seu software e hardware. Avalie quais são relevantes (utilizamos este software? quão crítica é a falha?) e aplique prontamente correções ou mitigações.”

CSAF ajuda a receber avisos estruturados. SBOM ajuda a determinar a presença de componentes. VEX ajuda a documentar a explorabilidade e o estado. O SGSI governa a decisão.

Evidência de política antes da chegada do aviso crítico

Um programa VEX falha quando o primeiro aviso crítico chega antes de existirem funções, critérios e requisitos de evidência. As políticas devem definir previamente a receção de vulnerabilidades, o escalonamento, o registo, as obrigações de fornecedores, o tratamento de exceções e a preservação de evidência.

Para PME, a Política de Gestão de Vulnerabilidades e Patches - PME estabelece a obrigação de monitorização:

“Monitoriza sistemas quanto a vulnerabilidades e patches disponíveis, utilizando alertas de fornecedores, avisos de inteligência de ameaças e notificações do sistema operativo”

Esta cláusula, da secção Funções e responsabilidades, cláusula 4.2.1 da política, aplica-se diretamente à receção CSAF. Os avisos CSAF são avisos de vulnerabilidades de fornecedores ou ecossistemas que devem ser monitorizados, correlacionados e triados.

A mesma política para PME define expectativas de preparação para auditoria:

“Manter registos exatos dos patches aplicados, questões pendentes e exceções, para assegurar preparação para auditoria”

A partir dos Objetivos, cláusula 3.4 da política, é aqui que VEX se torna mais do que um ficheiro técnico. Se uma equipa não aplica patches porque um produto está “não afetado”, essa exceção precisa de evidência, aprovação e rastreabilidade.

Para ambientes empresariais, a Política de Gestão de Vulnerabilidades e Patches é explícita:

“Monitorizar avisos de ameaça (por exemplo, CVE, CISA KEV, boletins de fornecedores) e escalar vulnerabilidades críticas.”

A partir da secção Funções e responsabilidades, cláusula 4.5.1 da política, esta cláusula suporta um canal estruturado de receção para CSAF, CVE, boletins de fornecedores e inteligência sobre exploração. Também exige escalonamento quando um estado VEX é “afetado” ou “em investigação” para um produto crítico.

A política empresarial também declara:

“Todas as vulnerabilidades críticas e de alto risco devem ser registadas no Registo de Riscos do SGSI e monitorizadas até serem remediadas ou cobertas por uma exceção aprovada.”

Esta cláusula, dos Requisitos de governação, cláusula 5.3 da política, é a âncora de conformidade. Uma declaração VEX “não afetado” para uma CVE crítica só é defensável quando é tratada como uma exceção aprovada com evidência. Uma declaração VEX “corrigido” só fecha o ciclo quando a remediação é verificada.

A pontuação de risco também precisa de contexto. A mesma política refere:

“Avaliação de riscos (baseada em CVSS, criticidade do ativo, inteligência de ameaças)”

A partir da secção Tratamento do risco e exceções, cláusula 7.2.2 da política, isto suporta um modelo de triagem combinado. O CVSS, isoladamente, não é suficiente. Uma vulnerabilidade de severidade média explorada ativamente num componente crítico de identidade pode ser mais urgente do que uma questão CVSS crítica em código inacessível.

As políticas de aplicações e de desenvolvimento seguro estendem a mesma disciplina à engenharia e aos fornecedores. A Política de Requisitos de Segurança das Aplicações - PME exige que as equipas acompanhem:

“vulnerabilidades conhecidas e estado da remediação.”

A partir dos Requisitos de implementação da política, cláusula 6.4.2.3, isto mapeia diretamente para os estados VEX. A mesma política exige que os acordos:

“especifiquem obrigações de divulgação de vulnerabilidades, tempos de resposta e aplicação de patches.”

A partir dos Requisitos de governação, cláusula 5.3.2 da política, isto torna-se uma cláusula prática para fornecedores: fornecer avisos tempestivos, identificar versões afetadas, emitir estado VEX sempre que possível, definir prazos de remediação e apoiar a divulgação a clientes.

Para desenvolvimento seguro empresarial, a Política de Desenvolvimento Seguro prevê:

“Análise de vulnerabilidades conhecidas (CVE, OSS Index, etc.)”

A partir dos Requisitos de governação, cláusula 5.4.3 da política, isto dá à engenharia um mecanismo definido para correlacionar avisos com componentes e acionar a análise VEX.

Quando uma vulnerabilidade se transforma num incidente ou numa potencial matéria jurídica, a disciplina de evidência torna-se essencial. A Política de Recolha de Evidência e Análise Forense - PME declara:

“Deve ser mantido um registo simples de cadeia de custódia (por exemplo, ficheiro Excel ou documento modelo) para cada incidente.”

A partir dos Requisitos de governação, cláusula 5.3.1 da política, esta é a fronteira entre a triagem VEX de rotina e o tratamento de evidência com nível de incidente. Se houver suspeita de exploração, logs, registos de avisos, notas de análise, comunicações e artefactos forenses precisam de rastreabilidade.

Mapeamento de VEX e CSAF para ISO 27001, NIS2, DORA, GDPR e CRA

Os programas VEX mais robustos não são projetos autónomos de engenharia de segurança. São mapeados para o sistema de controlos que a organização já utiliza.

Ao abrigo da ISO/IEC 27001:2022, o SGSI deve considerar partes interessadas, obrigações legais e contratuais, interfaces e dependências com outras organizações. Essa lógica de âmbito é essencial para VEX, porque avisos de fornecedores, compromissos com clientes, componentes de código aberto e serviços subcontratados afetam decisões sobre vulnerabilidades.

Os controlos mais relevantes do Anexo A incluem 5.19 Segurança da informação nas relações com fornecedores, 5.20 Tratamento da segurança da informação em acordos com fornecedores, 5.21 Gestão da segurança da informação na cadeia de fornecimento de TIC, 5.22 Monitorização, revisão e gestão de alterações dos serviços de fornecedores, 5.28 Recolha de evidência e 8.8 Gestão de vulnerabilidades técnicas. Os controlos de desenvolvimento seguro 8.25 a 8.29 também são relevantes quando a organização cria software ou produtos digitais.

A NIS2 aumenta a pressão de governação. Article 21 exige medidas técnicas, operacionais e organizacionais adequadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição, desenvolvimento e manutenção seguros, tratamento e divulgação de vulnerabilidades, eficácia dos controlos, higiene de cibersegurança, criptografia, segurança de RH, controlo de acesso, gestão de ativos e autenticação. Article 20 exige que os órgãos de gestão aprovem e supervisionem medidas de gestão de riscos de cibersegurança. Isto torna as métricas VEX adequadas para reporte ao conselho de administração.

O DORA aplica-se desde 17 de janeiro de 2025 às entidades financeiras abrangidas. Exige um quadro de gestão do risco das TIC, identificação e classificação de ativos de TIC, vulnerabilidades, dependências e serviços de terceiros de TIC, gestão de incidentes, testes de resiliência, gestão de risco de terceiros e supervisão pela gestão. Para entidades financeiras, os registos VEX são especialmente úteis quando um aviso de fornecedor tem de ser ligado a funções críticas ou importantes, obrigações contratuais e classificação de incidentes.

O GDPR entra em jogo quando a exploração pode afetar dados pessoais. Uma API, biblioteca ou serviço vulnerável que possa expor registos de clientes exige avaliação face a critérios de confidencialidade, integridade, disponibilidade e notificação de violação de dados. Uma conclusão VEX “não afetado” pode suportar uma decisão de não notificar, mas apenas se a organização conseguir demonstrar por que motivo não ocorreu uma violação de dados pessoais.

O Cyber Resilience Act acrescenta governação de produto. À medida que as obrigações do CRA entram em vigor, fabricantes e outros operadores económicos precisam de processos repetíveis de tratamento de vulnerabilidades, atualizações de segurança, divulgação coordenada e evidência. CSAF pode estruturar avisos. VEX pode clarificar que produtos e versões estão afetados, corrigidos ou não afetados.

O que o guia de conformidade cruzada da Clarysec acrescenta

Zenith Controls é valioso porque mapeia trabalho técnico para expectativas de auditoria e referenciais sobrepostos. Para VEX e CSAF, três áreas são mais relevantes: segurança da cadeia de fornecimento de TIC, gestão técnica de vulnerabilidades e recolha de evidência.

Para segurança da cadeia de fornecimento de TIC, Zenith Controls identifica o controlo 5.21 da ISO/IEC 27002:2022 como “Gestão da segurança da informação na cadeia de fornecimento de TIC”. Explica que 5.21 estende os controlos de relações com fornecedores 5.19 e 5.20 aos riscos específicos de TIC, incluindo componentes de software inseguros e bibliotecas de terceiros ou de código aberto. Liga-se a engenharia segura, programação segura, testes de segurança, controlo de acesso, recolha de evidência, ciclo de vida de desenvolvimento seguro e desenvolvimento subcontratado.

É exatamente aí que CSAF e VEX atuam. Um aviso de fornecedor não é apenas uma mensagem de um fornecedor. É evidência da prática de cibersegurança do fornecedor. Uma declaração VEX de fornecedor não é apenas uma conveniência. Pode suportar aquisição, diligência prévia, monitorização e decisões de risco de clientes.

Para gestão técnica de vulnerabilidades, Zenith Controls identifica o controlo 8.8 como “Gestão de vulnerabilidades técnicas”. Classifica o controlo como preventivo, suportando confidencialidade, integridade e disponibilidade, e ligado à gestão de ameaças e vulnerabilidades. Também observa que a gestão de vulnerabilidades se liga à proteção contra malware, gestão da configuração, gestão de alterações, inteligência de ameaças e monitorização.

Uma passagem particularmente útil de Zenith Controls para a governação VEX é:

“Uma gestão eficaz de vulnerabilidades prioriza com base em ameaças do mundo real. A inteligência de ameaças indica que vulnerabilidades estão a ser exploradas ativamente, orientando a priorização de patches.”

Essa é a diferença entre correspondência bruta de SBOM e triagem VEX baseada no risco. A presença, por si só, não basta. Explorabilidade, criticidade do ativo, exposição e atividade de ameaça devem moldar a decisão.

Para evidência, Zenith Controls identifica o controlo 5.28, “Recolha de evidência”, como corretivo e ligado a detetar e responder. Liga 5.28 à resposta a incidentes, registo, monitorização e reporte de eventos. Também mapeia o tratamento de evidência para a ISO/IEC 27037:2012, relativa à identificação, recolha, aquisição e preservação de evidência digital.

Quando uma vulnerabilidade é apenas teórica, registos VEX de rotina podem ser suficientes. Quando há suspeita de exploração, a organização deve passar para tratamento de evidência de incidente. Logs, comunicações de fornecedores, notificações a clientes, registos de patches e artefactos forenses precisam de integridade, preservação e rastreabilidade.

Um pacote prático de evidência VEX, do alerta ao encerramento

Regressemos à plataforma FinTech da Anya. Chega um aviso CSAF relativo a uma vulnerabilidade crítica em lib-common-utils, que aparece na SBOM do gateway de pagamentos. Uma resposta disciplinada criaria um único pacote de evidência, não mensagens de Slack e capturas de ecrã dispersas.

Etapa 1: Criar o registo de receção do aviso

Abra um caso de vulnerabilidade no rastreador de evidência do SGSI. Anexe o aviso CSAF, a referência CVE, o boletim do fornecedor, a correspondência de SBOM e a lista de ativos afetados. Atribua um responsável pela vulnerabilidade e um responsável pelo sistema de negócio. Ligue o serviço de pagamentos ao impacto em clientes, dados pessoais, processamento financeiro e criticidade operacional.

Base de política: a Política de Gestão de Vulnerabilidades e Patches exige monitorização de avisos e escalonamento de vulnerabilidades críticas. Base ISO: controlo 8.8 do Anexo A. Base NIS2: tratamento de vulnerabilidades e manutenção segura. Base DORA: identificação de vulnerabilidades de TIC e preparação para incidentes.

Etapa 2: Definir o estado preliminar como em investigação

O estado inicial deve frequentemente ser “em investigação”, especialmente para avisos críticos. Defina um prazo de decisão, por exemplo 24 horas para serviços críticos ou expostos externamente. Registe controlos interinos, como monitorização reforçada, restrições temporárias de funcionalidades ou regras WAF. Isto impede que um aviso crítico desapareça num backlog não gerido.

Etapa 3: Realizar a análise de explorabilidade

A engenharia deve responder a perguntas práticas:

• A versão vulnerável está presente em produção?
• A função vulnerável é importada, chamada ou alcançável?
• A configuração vulnerável está ativada?
• O componente está exposto a entradas não confiáveis?
• É exigida autenticação antes de o caminho vulnerável poder ser alcançado?
• Os controlos compensatórios são eficazes?
• Existe exploração ativa ou inteligência de ameaças credível?
• A exploração poderia afetar dados pessoais, transações financeiras ou disponibilidade do serviço?

No caso da Anya, a análise estática confirma que o componente está presente, mas a função vulnerável não é invocada pelo gateway de pagamentos. Não existe caminho de execução em produção. A equipa prepara uma declaração VEX “não afetado” com evidência de suporte.

Se a análise tivesse demonstrado que uma tarefa administrativa autenticada podia alcançar a função vulnerável, o estado correto seria “afetado”, não “não afetado”. A equipa criaria então um plano de tratamento de riscos, abriria um ticket de alteração, aplicaria patch ou mitigação e só atualizaria o estado para “corrigido” após verificação.

Etapa 4: Ligar o caso ao Registo de Riscos e ao registo de fornecedores

Casos críticos e de alto risco devem ser inseridos no Registo de Riscos do SGSI, salvo se forem encerrados por uma exceção aprovada e suportada por evidência. Avisos de fornecedores também devem ser ligados ao registo de fornecedores, obrigações contratuais e registos de monitorização.

Isto suporta a Etapa 23 do Zenith Blueprint, que instrui as organizações a compilar fornecedores, classificá-los por acesso e controlo operacional, incorporar expectativas de segurança em contratos e definir procedimentos de monitorização para alterações de fornecedores.

Etapa 5: Validar a correção ou aprovar a exceção

Para “corrigido”, anexe a versão do patch, o registo de alteração, o resultado da pipeline de CI/CD, a análise de dependências, o digest da imagem de contentor, a evidência de implementação e o teste de regressão. Para “não afetado”, anexe análise do caminho de código, evidência de configuração, evidência de versão, evidência de controlo compensatório e aprovação.

Se os clientes utilizarem versões autoalojadas ou se a vulnerabilidade puder afetar utilizadores externos, coordene a comunicação. A Política de Divulgação Coordenada de Vulnerabilidades fornece o modelo:

“Quando uma vulnerabilidade confirmada puder afetar clientes ou utilizadores do serviço, a equipa de Comunicações, sob a direção da VRT, deve preparar um aviso de segurança. O aviso deve incluir uma visão geral da questão, sem divulgar detalhes de exploração, os produtos ou versões afetados, orientação de mitigação ou instruções de transferência de patches, e informação de contacto de suporte.”

A partir dos Requisitos de implementação, cláusula 6.8 da política, isto mapeia diretamente para a disciplina de publicação CSAF.

Etapa 6: Preservar evidência se houver suspeita de exploração

Se os logs mostrarem tentativas de exploração, passe do tratamento de vulnerabilidades para resposta a incidentes e recolha de evidência. Inicie um registo de cadeia de custódia, preserve logs, registe consultas SIEM, exporte eventos relevantes, crie snapshots dos sistemas afetados se necessário e documente quem tratou cada artefacto. Ligue o caso de incidente ao registo VEX.

O que auditores e reguladores vão pedir

Nem todos os auditores testam a governação VEX e CSAF da mesma forma. Um único pacote de evidência deve satisfazer várias perspetivas.

Zenith Controls inclui orientação metodológica de auditoria que se ajusta a esta tabela. Para segurança da cadeia de fornecimento de TIC, auditores que utilizam ISO/IEC 19011 e ISO/IEC 27007 examinarão políticas de aquisição, modelos de RFP e processos de gestão de fornecedores para verificar requisitos de segurança específicos de TIC. Farão amostragem de contratos para cláusulas de desenvolvimento seguro, divulgação de vulnerabilidades e autenticidade de software.

Para gestão técnica de vulnerabilidades, os auditores revêm a política de gestão de vulnerabilidades, frequência de análises, cobertura de ativos, priorização baseada no risco, prazos de remediação e responsabilidades. Para recolha de evidência, testam se a cadeia de custódia, o armazenamento seguro e a preservação foram seguidos em incidentes reais.

É por isso que a governação VEX nunca deve terminar no rótulo de estado. O rótulo é o resumo. O trilho de evidência é o controlo.

Métricas de gestão que tornam VEX adequado ao conselho de administração

A ISO/IEC 27001:2022 exige avaliação de desempenho, auditoria interna e revisão pela gestão. A NIS2 exige supervisão pela gestão. O DORA exige governação sobre risco de TIC. VEX e CSAF criam métricas que traduzem trabalho de engenharia em visibilidade executiva do risco.

Métricas úteis para revisão pela gestão incluem:

• Número de avisos CSAF críticos recebidos no trimestre
• Percentagem com correspondência a componentes SBOM
• Número e antiguidade dos estados VEX por afetado, não afetado, corrigido e em investigação
• Casos “em investigação” vencidos
• Avisos de fornecedores sem dados suficientes sobre versões afetadas
• Vulnerabilidades críticas aceites como exceções aprovadas
• Tempo desde a receção do aviso até à decisão VEX
• Tempo desde a decisão de afetado até à remediação
• Número de casos com potencial impacto em dados pessoais
• Número de avisos a clientes emitidos

Estas métricas ajudam a gestão a formular melhores perguntas. Que fornecedores não fornecem dados de vulnerabilidade acionáveis? Que produtos têm os tempos de remediação mais longos? Que equipas deixam investigações em aberto? Que vulnerabilidades podem afetar dados pessoais ou funções críticas?

Padrões comuns de falha a eliminar

A primeira falha é tratar a correspondência de SBOM como análise de explorabilidade. Uma correspondência de componente é um sinal, não uma conclusão.

A segunda falha é usar “não afetado” sem justificação. Os auditores perguntarão porquê. O caminho de código era inacessível? A funcionalidade vulnerável estava desativada? A versão era diferente? O componente era usado apenas em tempo de compilação? A conclusão foi aprovada pela segurança do produto?

A terceira falha é deixar “em investigação” permanecer aberto. Este estado só é útil com responsável, prazo e controlos interinos.

A quarta falha é separar a governação de fornecedores da governação de vulnerabilidades. Os contratos com fornecedores devem exigir divulgação tempestiva de vulnerabilidades, tempos de resposta, obrigações de aplicação de patches, conteúdo de avisos e suporte de evidência.

A quinta falha é ignorar dados pessoais e comunicação a clientes. Uma vulnerabilidade que possa expor dados pessoais precisa de avaliação GDPR. Uma vulnerabilidade de produto confirmada que possa afetar clientes precisa de disciplina de divulgação coordenada. Uma dependência de serviço financeiro pode exigir análise de incidente DORA.

A sexta falha é uma preservação fraca de evidência. O Zenith Blueprint alerta na Etapa 23, controlo 5.28, que a evidência é frequentemente negligenciada:

“aquilo que consegue provar é tão importante como aquilo que realmente aconteceu”

Esta frase resume a realidade de 2026. As equipas de segurança não estão apenas a corrigir vulnerabilidades. Estão a demonstrar que as decisões foram tempestivas, baseadas no risco e controladas.

Próximos passos para evidência auditável de vulnerabilidades

Se a sua organização já tem SBOM, o próximo passo de maturidade não é outra folha de cálculo de inventário. É a governação sobre estados de vulnerabilidade, avisos de fornecedores e evidência de divulgação.

Comece com quatro ações:

1. Acrescente a receção CSAF e VEX ao seu procedimento de gestão de vulnerabilidades.
2. Defina critérios de aprovação para afetado, não afetado, corrigido e em investigação.
3. Ligue os registos VEX ao seu Registo de Riscos do SGSI, registo de fornecedores, inventário de ativos, repositório SBOM e processo de incidentes.
4. Teste o processo com um aviso crítico recente e produza um pacote de evidência pronto para auditoria.

A Clarysec pode ajudá-lo a implementar isto rapidamente com Zenith Blueprint, Zenith Controls e o conjunto de políticas relevante, incluindo a Política de Gestão de Vulnerabilidades e Patches, Política de Gestão de Vulnerabilidades e Patches - PME, Política de Requisitos de Segurança das Aplicações - PME, Política de Desenvolvimento Seguro, Política de Recolha de Evidência e Análise Forense - PME e Política de Divulgação Coordenada de Vulnerabilidades.

A pergunta decisiva em 2026 não é “Temos uma SBOM?” É “Conseguimos demonstrar, para cada aviso grave, exatamente como determinámos o estado da vulnerabilidade, tratámos o risco e comunicámos o resultado?”

Agende uma avaliação Clarysec ou solicite o toolkit de políticas relevante para transformar VEX e CSAF em evidência de vulnerabilidades pronta para auditoria antes que o próximo aviso crítico chegue ao seu conselho de administração.