Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Grande parte do software que move o mundo é mantida no tempo livre de alguém. Uma biblioteca que acaba sendo utilizada em milhares de sistemas de produção pode ter apenas um ou dois mantenedores por trás, muitas vezes não remunerados, que conciliam esse trabalho com seu emprego diurno. Esse modelo levou o código aberto muito longe, mas chega ao limite justamente no momento em que a segurança mais depende dele: quando uma vulnerabilidade precisa ser relatada, receber um CVE, ser coordenada e divulgada dentro de um prazo determinado.
Conduzir um processo coordenado de divulgação e atribuição de CVEs dá muito trabalho. Isso significa classificar relatórios, reservar um identificador, redigir um registro justificável, coordenar um embargo e publicar dentro do prazo. Para um mantenedor que já está sobrecarregado, esse processo pode ficar para trás; e, no caso de softwares que chegaram ao fim da vida útil, pode nem haver um processo ativo. O resultado é uma lacuna que toda a comunidade a jusante acaba arcando: existe uma vulnerabilidade, mas a referência compartilhada na qual todos confiam para rastreá-la e priorizá-la aparece com atraso ou nem chega a aparecer. Isso não é uma falha dos mantenedores. É um descompasso estrutural entre a ampla utilização do código aberto e a escassez de recursos com que grande parte dele conta.
A TuxCare está agora preparada para assumir parte dessa carga.
O Anúncio
O Programa CVE autorizou a TuxCare como Autoridade de Numeração CVE (CNA). Isso significa que a TuxCare pode atribuir IDs CVE e publicar registros CVE para vulnerabilidades nos produtos que mantém e distribui — incluindo o Endless Lifecycle Support (ELS) e o SecureChain para OSS. Os detalhes completos estão em nosso comunicado à imprensa.
O que um auxiliar de enfermagem realmente faz
Uma Autoridade de Numeração CVE é uma organização autorizada pelo Programa CVE a atribuir IDs CVE e publicar os registros associados dentro de um escopo definido. A Lista CVE, à qual esses registros contribuem, é uma infraestrutura compartilhada: scanners, SIEMs, feeds de inteligência de ameaças e alertas de fornecedores utilizam os IDs CVE como referência comum para discutir a mesma vulnerabilidade.
Um registro CVE não representa a história completa de uma vulnerabilidade. Ele é o ponto de coordenação. A CNA pode atribuir uma pontuação de gravidade e uma classificação de vulnerabilidade no próprio registro — a TuxCare fará isso —, enquanto sistemas a jusante, como o National Vulnerability Database, acrescentam mais informações, status de exploração e detalhes de correção, todos vinculados a esse ID de CVE. Portanto, o momento em que o ID é atribuído e publicado é importante, pois é nesse momento que todos os sistemas a jusante podem começar a acompanhar o problema de maneira coordenada.
Quando nenhuma CNA abrange um determinado software, um relator deve recorrer à CNA de Último Recurso (CNA-LR) do Programa CVE. Esse procedimento funciona, mas acrescenta uma etapa de transferência entre as pessoas responsáveis pela correção da vulnerabilidade e as responsáveis pela publicação do registro, e etapas extras significam espera adicional. Para softwares dos quais muitas pessoas dependem, esse atraso é o problema.
O que muda para os usuários deste software
Para vulnerabilidades em produtos dentro do escopo do CNA da TuxCare, a atribuição, a documentação e a correção agora ocorrem por meio de um único processo coordenado, tendo a TuxCare como fonte oficial de registro. Uma vulnerabilidade confirmada dentro do escopo recebe um ID CVE em 24 horas após a triagem, um registro publicado e um patch correspondente a ela – sem envolvimento de filas de terceiros.
Vale a pena destacar especificamente o software em fim de vida útil. Quando um projeto chega ao fim de sua vida útil, o processo de divulgação do mantenedor geralmente vai diminuindo, mas o software continua em operação por anos. As CNAs podem incluir versões em fim de vida útil em seu escopo e atribuir CVEs a elas, em vez de deixá-las seguir o caminho de fallback — e o escopo da TuxCare faz exatamente isso por meio do ELS. Para organizações que ainda utilizam esse software, essa é a diferença entre uma vulnerabilidade rastreada, documentada e corrigível e uma que permanece sem gerenciamento.
Como isso se encaixa no que a TuxCare já faz
A TuxCare já aplica correções a esse software. O SecureChain recompila e aplica correções a pacotes de código aberto mantidos ativamente em registros públicos; o Endless Lifecycle Support oferece suporte a sistemas operacionais, bibliotecas e ambientes de execução de linguagens que chegaram ao fim de vida útil. Ambos se baseiam na mesma premissa: o software de código aberto do qual as pessoas dependem deve permanecer seguro, independentemente de seus mantenedores estarem acompanhando as atualizações ou terem deixado o projeto.
A função da CNA está diretamente ligada a isso. A TuxCare já distribui a correção; agora, ela também pode assumir a responsabilidade pelo registro da vulnerabilidade que a correção resolve. A atribuição e a correção deixam de ser duas etapas separadas, tratadas por duas partes diferentes em dois prazos distintos. Elas se tornam um único processo, coordenado pela mesma organização que já é responsável pelo patch.
O que vem a seguir
A questão mais ampla é simples. O código aberto impulsiona o setor, e grande parte dele é mantida por pessoas que nunca se comprometeram a conduzir uma operação de divulgação de vulnerabilidades de segurança. Aliviar parte desse fardo de coordenação para o software que a TuxCare oferece suporte é uma pequena solução estrutural para um problema estrutural. É o tipo de contribuição que se encaixa em uma organização cujo trabalho sempre começou onde a manutenção do código aberto chega ao fim.
