Uma ponte permanece em serviço durante cinquenta anos, seguindo um calendário de inspeções fixo, sendo submetida a ensaios de carga e mantida ao longo de todo esse período. Um motor a jato com o mesmo projeto voa durante décadas sob supervisão regulamentar contínua. Na maioria das disciplinas de engenharia, o objetivo é um projeto estável e comprovado, aliado a uma manutenção ativa. Os projetos mais recentes são alvo de um escrutínio muito maior, porque nunca foram verdadeiramente testados.
Mas, por alguma razão, na engenharia de software, acontece precisamente o contrário. A versão mais recente é considerada a mais segura. E esse instinto já teve consequências muito negativas no passado. Uma porta traseira estava presente em duas versões específicas de xz-utils, versões 5.6.0 e 5.6.1, implantadas por um infiltrado que passou dois a três anos a planear a obtenção de autorização para a sua divulgação. Quem ainda utilizava a linha mais antiga 5.4 x nunca ficou exposto, mas quem tivesse instalado a versão mais recente — algo que as equipas de segurança costumam ser instruídas a fazer — estava a utilizar um canal SSH com porta traseira. A orientação posterior da própria CISA foi a de reverter para uma versão anterior, e não atualizar.
Já defendemos anteriormente, naquilo a que chamamos «a armadilha da atualização», que aplicar a correção assim que surge um CVE é uma falsa economia; está a escolher entre congelar o sistema e aceitar quaisquer alterações que venham com a correção. xz-utils mostra-nos o outro lado da mesma moeda. Ficar onde estávamos era a opção segura, e o lançamento mais recente era a armadilha.
Uma forma de testar isto é perguntar a uma equipa de segurança qual é o número de CVE em aberto; eles conseguiriam responder rapidamente. Mas se perguntares por que razão um pacote específico ou uma imagem d container está a utilizar a versão que está a utilizar, é muito provável que recebas um «não sei». É assim mesmo, não é? Normalmente, baseia-se no que estava disponível quando o projeto começou, e a atualização parecia dar mais trabalho do que valia a pena. Indo um pouco mais longe, se pedires um registo dessa decisão por escrito, é provável que recebas uma resposta mais severa do tipo«por que é que teríamos de fazer isso?».
Então, onde é que isto corre mal?
Muitas vezes, os engenheiros são levados a acreditar que uma imagem ou um pacote do container se torna mais arriscado à medida que o número da versão fica desatualizado. Mas o xz-utils Este exemplo prova que isso não é verdade; a versão mais antiga era segura porque ainda não tinha sido alvo de nenhum ataque malicioso e as equipas que a utilizavam não se apressaram a adotar a versão mais recente assim que esta foi lançada. É claro que existe a possibilidade de muitas equipas simplesmente não terem tido tempo para a atualizar, embora tivessem essa intenção. Mesmo assim, isso é melhor do que não saber qual a versão que se está a utilizar, ou porquê, o que constitui, na verdade, a verdadeira falha neste caso.
Em vez disso, as equipas têm de ter em conta que, se dispõem de uma versão de uma biblioteca que foi testada, compreendida e que inspira confiança, há um valor genuíno em mantê-la estável. A monitorização começa no momento em que um programador, um agente ou um pipeline de compilação solicita uma imagem base do « container » ou um pacote de código aberto, avaliando-o antes de este entrar no ambiente. É a primeira decisão de uma cadeia de decisões que são tomadas.
Uma atualização também é uma decisão
Em algum momento, será lançada uma nova versão, mas corrigir uma vulnerabilidade CVE significa aceitar também tudo o resto que foi incluído nessa versão. Isso inclui aspetos como dependências transitivas, valores predefinidos alterados e percursos de código que ninguém na equipa leu. Na maioria das vezes, esse risco passa despercebido e nada corre mal. Mas, e este é um grande «mas», as coisas podem correr mal. lodash passou uma parte de 2026 com uma vulnerabilidade de injeção de código arbitrário divulgada, que afetava todas as versões publicadas. Quando a correção foi finalmente lançada na versão 4.18.0, deixou de funcionar imediatamente, porque o patch substituiu uma função interna diferente que nunca tinha sido importada, o que fez com que projetos reais deixassem de funcionar no espaço de um dia.
O npm considerou a versão totalmente obsoleta e aconselhou os utilizadores a voltarem à lodash 4.17.21 Em vez disso. A alteração que causou incompatibilidade não teve nada a ver com a própria vulnerabilidade; tratou-se de um erro de empacotamento que veio incluído na correção de segurança. A correção propriamente dita foi lançada na versão 4.18.1.
Nenhuma das opções em consideração era, na verdade, segura. A atualização para a versão 4.18.0 danificou imediatamente as compilações. Manter a versão 4.17.21 deixava a vulnerabilidade exposta, enquanto todas as versões anteriores à 4.18.0 continuavam suscetíveis a exploração. Algumas equipas reverteram para a versão 4.17.x especificamente para « escape » a compilação danificada, trocando uma compilação funcional por uma via de injeção de código ativa, sem necessariamente se aperceberem de que era essa a troca que tinham feito.
Neste caso, as equipas que se encontravam em melhor posição eram aquelas que sabiam se a sua própria aplicação chegava a chamar a função afetada _.template caminho com entradas não confiáveis, e poderiam ponderar essa exposição real em relação à alternativa defeituosa, em vez de optarem automaticamente por qualquer uma das opções sem saberem qual seria, de facto, o custo para eles.
Corrigir a vulnerabilidade sem substituir tudo à sua volta
O backporting muda a equação. Consiste em pegar na correção específica para uma vulnerabilidade específica e aplicá-la à versão já em execução, em vez de incorporar tudo o resto que foi lançado em conjunto com ela a montante. Ao aplicá-la a uma imagem do container , a vulnerabilidade CVE é corrigida sem obrigar à utilização de uma nova imagem base. Ao aplicá-la a um pacote, a mesma correção é efetuada sem uma mudança forçada para a versão mais recente — precisamente a mudança que causou falhas em projetos reais em execução lodash 4.18.0. É possível resolver o problema de segurança sem alterar tudo à sua volta.
Um « SBOM » deve merecer o seu lugar, não basta apenas existir
Um SBOM, tal como tantos outros documentos relacionados com a conformidade, é frequentemente consultado uma única vez e arquivado. Isso indica-lhe o que se encontrava no sistema no dia em que alguém gerou o relatório. Mas o SBOM pode fazer muito mais pela vossa postura de segurança do que isso. Pode servir de referência de software fiável e ajudar-vos a gerir continuamente essa referência. Para tal, basta garantir que se mantém atualizado e que é verificado em relação a novas divulgações à medida que estas surgem. Para mim, esse é o sinal mais claro de que uma organização continua a acompanhar o software que utiliza, em vez de se contentar com o que já existe.
Queremos que o « SBOM » não se torne apenas um inventário ou um elemento de conformidade. Deve ser uma superfície regulamentada e mantida ativamente.
Então, o que é que tem de mudar?
Todas estas são decisões que têm de ser tomadas. Algumas dizem respeito a um componente de software específico num determinado momento, como avaliar um pedido, fixar a versão e fazer o backporting em vez de forçar uma atualização. Outras, como a decisão de manter ou não um SBOM atualizado, dizem respeito aos processos que tem em vigor. Cada uma delas é, na verdade, uma decisão sobre em que confiar.
O mais fácil é simplesmente deixar as coisas como estão, porque «funciona». Mas «funciona» não é bem verdade, pois não? Só porque algo funciona, não significa que vá funcionar sempre, nem que seja a forma mais segura de fazer as coisas, nem que seja a melhor forma de operar.
Na nossa perspetiva, a abordagem mais proativa e consciente em termos de segurança seria controlar as alterações no ponto de entrada — avaliar os pacotes antes de um programador, agente ou sistema de compilação os utilizar. A partir daí, deve ter a liberdade de decidir proativamente o que entra, fixar aquilo em que confia, mantê-lo e só o alterar quando houver um motivo para tal.
Manter-se numa versão não deve significar permanecer exposto. Aikido As bibliotecas faz o backport da correção para a versão que já está a utilizar, sem atualizações forçadas, sem migrações forçadas. Comece a aplicar as correções aqui.
