Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Principais conclusões
- As correções do SecureChain estarão disponíveis no JFrog Zero-Touch Remediation e serão aplicadas sem alteração de versão.
- A detecção nunca foi a parte difícil; o que sempre foi difícil foi produzir e implementar uma correção que não causasse falhas.
- A cobertura continua mesmo depois que os mantenedores originais deixam de disponibilizar correções de segurança para um pacote.
- Cada correção aplicada é certificada pelo JFrog AppTrust, de modo que as evidências de auditoria são geradas diretamente no pipeline.
Uma vulnerabilidade CVE crítica é detectada em um pacote localizado três níveis abaixo na árvore de dependências. O scanner a detecta no mesmo dia, o que é a parte fácil. Em seguida, descobre-se que a correção só está disponível em uma versão principal; essa versão altera uma API que dois dos seus serviços utilizam; e o pacote que a incorporou está fixado por um SDK de fornecedor que ninguém da equipe controla. Duas semanas depois, o ticket está aberto e a vulnerabilidade ainda consta no relatório.
Encontrar um pacote de código aberto vulnerável raramente é a parte difícil. Incorporar a correção adequada à compilação correta, sem criar um segundo problema no processo, é que torna a correção complicada.
Essa é a lacuna que a nova parceria busca preencher. A TuxCare passou a integrar o Ecossistema de Segurança da Cadeia de Suprimentos de Software com Autocorreção da JFrog como parceira fundadora, e o SecureChain se integrará ao JFrog Zero-Touch Remediation como fonte de correções para pacotes de código aberto vulneráveis.
Onde a correção de vulnerabilidades em software de código aberto realmente fica estagnada
A cobertura dos scanners já é boa o suficiente para que a maioria das equipes saiba quais são suas dependências vulneráveis bem antes que alguém tenha um plano para lidar com elas. O que elas recebem é uma fila.
Um pacote de terceiros vulnerável deixa três opções reais: atualizar para a versão corrigida, fazer você mesmo o backport da correção ou aceitar o risco e registrar isso. A primeira é a que todas as ferramentas recomendam e, muitas vezes, a menos prática, pois os aumentos de versão nas dependências transitivas se propagam de maneiras que ninguém consegue prever a partir do manifesto. Às vezes, a versão afetada já está no fim do ciclo de vida, então não há mais nenhuma atualização disponível. A segunda opção significa manter um fork de código que você não escreveu, em uma base de código que você não consegue testar adequadamente. A terceira é o que geralmente acontece.
Imagine uma equipe de plataforma de 30 pessoas administrando uma dúzia de serviços Java, metade dos quais está presa a uma versão mais antiga do Jackson devido a um SDK que eles licenciam, em vez de possuírem. A atualização é um projeto que se estende por vários sprints, sem nenhum novo recurso associado a ele. Os desenvolvedores perdem dias comparando opções de correção antes de encontrar uma que possa ser implantada com segurança. De qualquer forma, as mesmas conclusões aparecem no relatório semanal, e a data da auditoria não muda.
O que o SecureChain oferece
Os pacotes do SecureChain são recompilados a partir do código-fonte, passam por uma verificação contra malware antes de serem publicados e recebem correções para vulnerabilidades conhecidas, sem alterar a versão declarada no manifesto.
Dois aspectos são importantes para essa integração. A correção mantém o mesmo número de versão, portanto, nada no gráfico de dependências precisa ser alterado. E a cobertura não termina quando a manutenção do desenvolvedor original cessa, pois o Suporte de Ciclo de Vida Ilimitado continua lançando correções para essa linha de versão mesmo depois que os mantenedores param.
É nessa segunda categoria que se encontram muitas descobertas de longa duração. Um pacote que não recebe um commit há três anos não receberá uma correção de CVE de seu mantenedor, independentemente de quantos tickets o mencionem.
Atualmente, a cobertura do SecureChain abrange o npm, o PyPI e o Maven, com Go, Rust e PHP previstos no plano de desenvolvimento.
O que acontece dentro do duto
O Artifactory é de onde as compilações obtêm seus arquivos, o que faz dele o único lugar onde uma correção pode ser substituída sem que seja necessário pedir a nenhum desenvolvedor para alterar nada.
A correção “Zero-Touch” associa um componente vulnerável à melhor correção disponível de um parceiro, de acordo com sua política, aplica-a por meio do pipeline que você já executa e registra um atestado assinado para a ação por meio do JFrog AppTrust. Quando sua política prioriza um pacote recompilado a partir do código-fonte e atualizado continuamente, é a versão do SecureChain que é fornecida. A compilação solicita o mesmo pacote que solicitou ontem e recebe um pacote atualizado.
Sem ticket. Sem precisar procurar uma versão compatível. Sem precisar negociar com a equipe responsável pelo serviço.
A parte relativa à certificação tem mais valor do que parece. A maioria das equipes consegue, eventualmente, comprovar que um pacote recebeu uma correção. Muito menos conseguem comprovar quando a correção foi aplicada, em relação a qual CVE e por meio de qual processo, de uma forma que um auditor aceite sem a necessidade de um tópico de acompanhamento.
Onde isso traz resultados mais cedo
Os casos mais evidentes são pacotes cujo suporte do desenvolvedor original foi encerrado, dependências transitivas que sua equipe nunca escolheu e não consegue substituir facilmente, e qualquer ambiente em que os SLAs de correção sejam contratuais, e não meramente aspiracionais.
Se você já utiliza o Artifactory com o Xray ou o Advanced Security, adicionar o SecureChain como fonte de correção é uma decisão de política, e não uma migração. Se suas compilações forem obtidas de outro lugar que não seja o JFrog, o SecureChain ainda funciona como um registro independente e verificado, e a integração estará disponível quando você precisar.
De qualquer forma, a mudança que merece atenção não é o fato de que já existem correções. Elas já existiam antes. É o fato de que uma correção pode chegar a uma versão em execução sem que alguém precise aplicá-la manualmente, o que transforma a correção de um projeto em uma parte rotineira do processo de lançamento de software.
Mais informações sobre a correção sem intervenção manual do JFrog: jfrog.com/zero-touch-remediation
Mais informações sobre o TuxCare SecureChain: tuxcare.com/securechain-for-oss
