A CNCF publicou, em 7 de setembro de 2026, um cartão de orientação intitulado «Lidando com relatos de vulnerabilidades» (Handling vulnerability reports: Recipe card), destinado a projetos de código aberto pequenos e médios que não têm como foco principal a segurança. O material foi elaborado por Marina Moore, da Edera, que é copresidente do TAG Security, e por Sherine Khoury, da Red Hat, que é líder do TAG Security.
A ideia central do guia é reduzir o trabalho adicional para mantenedores e usuários, impedindo que o relato de segurança se transforme em uma discussão pública antes de a correção estar pronta. A CNCF explica que uma vulnerabilidade de segurança é uma falha que pode ser explorada para afetar a confidencialidade, a integridade ou a disponibilidade do sistema, mas nem toda falha de software é explorável ou classificada como vulnerabilidade.
Comece com um canal de denúncia claro e privado
As orientações recomendam que o arquivo README.md contenha uma seção de segurança clara e fácil de encontrar, com as instruções diretamente no arquivo ou uma referência ao arquivo SECURITY.md na raiz do repositório. O objetivo é direcionar os pesquisadores para um caminho privado, em vez de publicar os detalhes do problema em uma issue pública que todos possam ler.
As instruções de denúncia devem esclarecer vários elementos, entre eles o modelo de ameaça ou o mínimo necessário para que o relato seja considerado uma vulnerabilidade, o local de envio, o formato do relato, o prazo esperado até a análise e o prazo aproximado até a divulgação. Pode-se usar o mecanismo privado de denúncia de vulnerabilidades do GitHub ou uma lista de e-mails privada. Já um programa de recompensas não é obrigatório para projetos pequenos e médios se eles não tiverem capacidade para operá-lo.
Verifique a natureza do relato antes de tratá-lo como vulnerabilidade
Após o recebimento do relato, deve-se determinar primeiro se ele realmente indica uma vulnerabilidade explorável ou se se trata de uma falha não explorável, de um mal-entendido sobre o comportamento esperado ou de um erro na documentação. A CNCF sugere discutir o relato com seu autor e com os especialistas adequados do projeto, mantendo o número de participantes limitado e exigindo que todos preservem a confidencialidade até que o relato se torne público.
Entre as perguntas práticas que podem ser feitas estão: existe algum mecanismo de mitigação disponível para os usuários? A falha pode levar a uma invasão, ao vazamento de dados ou a outra atividade maliciosa? O problema está apenas na documentação? Se ficar constatado que o relato não é uma vulnerabilidade, seu autor pode ser orientado a criar uma issue pública, usando-se os procedimentos de publicação adequados para informar os usuários quando necessário.
Em caso de incerteza, as orientações indicam que é possível solicitar orientação ao TAG Security and Compliance ou à equipe da CNCF, mantendo os detalhes do relato fora dos canais públicos. Também se deve escolher cuidadosamente os participantes durante o período de embargo de confidencialidade e envolver apenas aqueles que realmente precisam ajudar na solução, para que a informação não vaze para invasores antes que a correção seja disponibilizada.
Desenvolva a correção e teste-a longe do público
A CNCF alerta que publicar ou discutir a correção em um pull request público pode revelar a natureza da vulnerabilidade antes que os usuários tenham a oportunidade de atualizar. Se for usado o mecanismo privado de denúncia do GitHub, pode-se criar um branch privado a partir do relato. Caso contrário, a correção pode ser desenvolvida e revisada por meio de um canal privado.
A correção deve ser testada, mesmo que o ambiente habitual de integração contínua não funcione com branches privados. Nesse caso, os testes podem ser realizados localmente, de acordo com o julgamento dos mantenedores e o escopo da alteração. Depois de confirmar que a correção resolve o problema e que os testes são suficientes, as orientações recomendam integrá-la rapidamente e envolver um número suficiente de mantenedores em sua criação e seus testes. Antes da publicação geral, o código deve ser revisado novamente, e deve-se confirmar que a vulnerabilidade foi realmente eliminada.
Coordene a versão com a divulgação do CVE
Após a conclusão da correção, a CNCF considera uma prática comum divulgá-la dentro de 90 dias após o recebimento do relato. Se seus recursos permitirem, o projeto pode avisar previamente uma lista privada de usuários, mas manter uma lista de contatos atualizada representa um fardo que a maioria dos projetos pequenos não consegue suportar.
Por isso, o cartão propõe uma abordagem mais simples: disponibilizar a versão que contém a correção e anunciar a vulnerabilidade ao mesmo tempo, para que os usuários obtenham a correção quando o problema for anunciado. Isso exige criar uma nova versão assim que a correção for incorporada e, em seguida, publicar o CVE. Se o mecanismo privado do GitHub for usado, isso pode ser feito pela interface do GitHub.
Um número CVE deve ser atribuído por uma CNA, ou seja, uma autoridade de numeração de CVE. O GitHub é uma dessas autoridades e pode executar o processo; o projeto e o pesquisador também podem entrar em contato diretamente com uma das autoridades CNA listadas. Já a gravidade do CVE é determinada por meio de um conjunto de perguntas, e o projeto deve trabalhar com o pesquisador para garantir a precisão das respostas e concordar com a pontuação atribuída.
Por que essas orientações são importantes?
Na prática, o cartão transfere a responsabilidade pela gestão da vulnerabilidade de uma reação aleatória para um processo executável: canal privado, verificação limitada, correção não divulgada e, depois, publicação e divulgação coordenadas. Após a publicação do CVE, as informações aparecem no OSV e em outros bancos de dados de vulnerabilidades, ajudando as ferramentas de análise dos usuários a detectar a necessidade de atualização.
Mas o escopo da receita é claramente limitado: ela é destinada a projetos pequenos e médios não especializados em segurança e não substitui um programa mais complexo para projetos de alto risco ou sensíveis do ponto de vista da segurança. A CNCF também sugere considerar a publicação de uma prova de conceito algum tempo depois que a correção estiver disponível, para dar aos usuários uma oportunidade adicional de atualização, reconhecendo que isso pode ser difícil quando se usa a denúncia privada.