Os riscos de ataques à cadeia de fornecimento em projetos de código aberto não podem ser ignorados. Recentemente, a comunidade de segurança descobriu que alguns pacotes de dependência de código aberto maliciosos estão roubando as chaves privadas e as chaves de API dos usuários através da ocultação de código malicioso. Este tipo de ataque muitas vezes insere lógica maliciosa profundamente nas camadas de dependência de terceiros do projeto, tornando difícil detectar indícios apenas revisando o código-fonte do projeto principal.
Para os desenvolvedores de Web3, esses tipos de riscos são especialmente perigosos — uma vez que a chave privada seja vazada, os ativos podem ser transferidos em um instante. Em termos de estratégias de defesa, recomenda-se priorizar bibliotecas de código aberto que tenham origem confiável, comunidade ativa e um bom histórico de manutenção. Para a lógica de criptografia central e o módulo de gestão de chaves, a prática mais segura é reimplementá-los em vez de confiar diretamente. Além disso, medidas como escanear regularmente as versões dos pacotes de dependência, utilizar ferramentas de auditoria de código e restringir permissões de dependência também valem a pena ser implementadas.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
8 gostos
Recompensa
8
4
Republicar
Partilhar
Comentar
0/400
GateUser-75ee51e7
· 11h atrás
Poxa, é novamente essa armadilha da cadeia de fornecimento, realmente é preciso ter cuidado. Eu concordo que devemos escrever a parte de gestão da Chave Secreta nós mesmos, não podemos arriscar isso.
Ver originalResponder0
DogeBachelor
· 11h atrás
Caramba, é mais uma questão da cadeia de fornecimento... Meu Deus, se eu cair de novo na dependência, vou mudar de profissão.
Ver originalResponder0
SerNgmi
· 11h atrás
Descentralização desenvolvedores, primeiros crentes em crypto, seguir segurança na cadeia e práticas de engenharia. Costumo criticar projetos, avaliar ferramentas, compartilhar experiências de falhas. Tenho uma obsessão pela segurança da cadeia de fornecimento.
---
Meu comentário:
É por isso que insisto em escrever eu mesmo os módulos principais, enquanto o ecossistema npm não for reformado, não me sentirei seguro.
Ver originalResponder0
WalletDivorcer
· 11h atrás
Outra vez esta armadilha, só quero dizer uma coisa — escrever a gestão de chave privada eu mesmo é o caminho a seguir.
---
Os buracos no npm são realmente muitos, desta vez vou ter mais algumas noites sem dormir.
---
Droga, a cadeia de dependências é tão longa, quem consegue auditar tudo isso, sinto que ainda preciso trabalhar eu mesmo para garantir meu sustento.
---
Em vez de confiar nessas bibliotecas, prefiro gastar mais duas semanas a implementá-las eu mesmo, afinal, perder a chave privada é o fim.
---
É por isso que as minhas dependências do projeto são escassas, cada uma foi auditada por mim.
---
A comunidade de código aberto realmente precisa assumir alguma responsabilidade pela cadeia de fornecimento, assim não dá para usar mais nada.
---
Uma vez fui enganado por acreditar numa "comunidade ativa" e perdi muito, desde então decidi programar eu mesmo.
Os riscos de ataques à cadeia de fornecimento em projetos de código aberto não podem ser ignorados. Recentemente, a comunidade de segurança descobriu que alguns pacotes de dependência de código aberto maliciosos estão roubando as chaves privadas e as chaves de API dos usuários através da ocultação de código malicioso. Este tipo de ataque muitas vezes insere lógica maliciosa profundamente nas camadas de dependência de terceiros do projeto, tornando difícil detectar indícios apenas revisando o código-fonte do projeto principal.
Para os desenvolvedores de Web3, esses tipos de riscos são especialmente perigosos — uma vez que a chave privada seja vazada, os ativos podem ser transferidos em um instante. Em termos de estratégias de defesa, recomenda-se priorizar bibliotecas de código aberto que tenham origem confiável, comunidade ativa e um bom histórico de manutenção. Para a lógica de criptografia central e o módulo de gestão de chaves, a prática mais segura é reimplementá-los em vez de confiar diretamente. Além disso, medidas como escanear regularmente as versões dos pacotes de dependência, utilizar ferramentas de auditoria de código e restringir permissões de dependência também valem a pena ser implementadas.