.
Opinião Bibliotecas. Templos silenciosos ao poder civilizador do conhecimento ou plataformas de lançamento da destruição global? Sim, outra palavra que a tecnologia emprestou e desvalorizou. Bibliotecas de código são essenciais para adicionar a funcionalidade testada padrão correta a um projeto. Eles também são um lar natural para ataques à cadeia de suprimentos que materializam malware no coração da empresa, como tropas de choque de Klingons chegando por meio de um raio transportador.
Semana passada vi uma beleza. Polyfill.io, que atende mais de 100.000 sites com melhorias de JavaScript para navegadores mais antigos, foi subitamente acusado de envenenar suas funções com malware e, assim, atacar todos os usuários desses sites. Nem mesmo se acreditava que fosse o hack padrão da cadeia de suprimentos, onde os bandidos entram em um vendedor de middleware desavisado e plantam os patógenos. A rede alegada era que polyfill.io havia sido comprado no início deste ano e os próprios novos proprietários eram os responsáveis. A chamada foi feita para interromper o uso do polyfill.io imediatamente, com a rede de distribuição de conteúdo Cloudflare redirecionando as chamadas para o site para proxies higienizados.
A primeira reação do Polyfill.io foi acusar a mídia e a Cloudflare de calúnia. Talvez uma posição melhor a ser tomada fosse professar inocência, dizer que você está levando a situação a sério e que está trabalhando em estreita colaboração com a Cloudflare para entender o assunto com urgência. Acusações furiosas de conspiração da mídia podem ser muito típicas dos anos 2020, mas colocam você em companhia questionável. Em qualquer caso, o próprio conceito de ataques à cadeia de abastecimento por parte dos proprietários de um fornecedor é um caso especial que merece inspeção, um caso que necessitará das suas próprias regras de envolvimento para ser controlado. Acontece que, neste momento, essas regras são difíceis de discernir.
Não há nada de novo em empresas que compram um produto de software estabelecido e depois o enchem de bobagens, como diz a alegação contra o Polyfill.io. Na época em que o shareware de código fechado de repositórios centralizados era o playground preferido dos nerds do PC – não, Steve Jobs não inventou a loja de aplicativos – os favoritos familiares podiam estragar da noite para o dia. O aplicativo reprodutor de MP3 WinAmp da Nullsoft foi vendido para a AOL e imediatamente começou a instalar o software de desktop da AOL por padrão. Um produto popular com acesso íntimo aos sistemas dos usuários sempre será um alvo tentador, e o middleware está enfaticamente na lista. Embora os piores excessos dos repositórios de aplicativos para PC da virada do século tenham sido em grande parte, mas não totalmente, restringidos pela loja de aplicativos moderna, não existe tal proteção com curadoria para as empresas.
Também não há nada de novo em ter funcionalidade dinamicamente servida por um terceiro. A especificação WWW original de Tim Berners-Lee era toda sobre misturar perfeitamente vários servidores independentes em uma única página. Naqueles dias idealistas, o fato de que isso transferia a responsabilidade de saber em que confiar do usuário para o proprietário do site não parecia importar. Nestes dias de tecnologia de anúncios, rastreadores e mineração de dados secreta, isso importa muito. Essa responsabilidade definitivamente inclui JavaScript de terceiros servido ao vivo de outro lugar, especialmente se você escolher usá-lo.
Também é um duplo refém da fortuna. Um ataque à cadeia de suprimentos em um pacote de biblioteca que você compila com seu código é desagradável o suficiente, mas você pode voltar para a última versão boa e voltar ao ar com um grau de agilidade. Se sua biblioteca vive nas masmorras de um terceiro que deu errado, não só é improvável que eles ofereçam uma regressão à segurança, como você não poderia confiar neles se o fizessem. Isso pode exigir algum conserto. O desvio de chamadas polyfill.io da Cloudflare para um lugar seguro é uma dádiva de Deus, mas os deuses são caprichosos, não uma estratégia confiável. Além disso, se o problema original não começou com o polyfill.io, afinal, a legalidade de sequestrar seu tráfego pode ser difícil de defender. Nem todos com a chance de fazer isso podem ser ousados o suficiente.
O aspecto especial final deste incidente é a tirania das métricas – ou, para ser mais saudável, o desejo de inclusão. O produto polyfill.io é popular porque permite o fornecimento de serviços para navegadores mais antigos que não têm recursos modernos. Esses usuários terão uma boa experiência, enquanto você consegue produzir um site moderno sem o trabalho sisífico de manter acesso especial para aqueles que não podem ou não querem usar o programa. O aspecto tácito disso é que você não criou apenas um novo vetor de ataque para todos os usuários, independentemente de quão à la mode seus navegadores sejam. Você encorajou tacitamente os resistentes a continuarem vagando pela web com código vulnerável e sem patches em seus sistemas. Isso estava na equação de segurança do seu produto? Está agora.
A responsabilidade é, infelizmente, tão divertida quanto ficar com um cacto. Quando se trata de segurança do usuário, isso é um saguaro. Todo mundo quer um ajuste e esqueça, faça isso e você ficará bem com uma correção que nos absolva, mas a segurança não funciona dessa maneira. Especialmente não funciona dessa maneira se um fornecedor de componentes anteriormente confiável se tornar desonesto. Não haverá uma única resposta, dadas as realidades de nossa maquinaria de conexão. Da mesma forma que as lojas de aplicativos com curadoria se livraram da maior parte da anarquia, e os certificados digitais mantiveram a maior parte da confiança e liberdade online, as mitigações evoluirão. Talvez.
Até esse dia, mesmo depois, existe um estado de espírito que ajudará mais do que qualquer coisa. Quando algo dá errado em algo que você ajudou a criar, mesmo como resultado de má conduta no outro lado do mundo, assuma um pouco de responsabilidade. Pergunte a si mesmo se você teria feito algo diferente se soubesse então o que sabe agora. Todos que criam códigos que se conectam à nossa humanidade conectada têm aquele pequeno chip de responsabilidade em relação a tudo isso. Pode não estar nas especificações do seu trabalho, pode não surgir em uma conversa, mas merece fazer parte do seu kit de ferramentas mentais. Ao contrário de uma biblioteca sequestrada, ela sempre lhe servirá bem. ®
.
