Los riesgos de ataques a la cadena de suministro en proyectos de código abierto no deben ser ignorados. Recientemente, la comunidad de seguridad ha descubierto que ciertos paquetes de dependencias maliciosos de código abierto roban las llaves privadas y llaves de API de los usuarios ocultando código malicioso. Este tipo de ataque a menudo entierra la lógica maliciosa en los niveles de dependencias de terceros del proyecto, lo que hace que sea difícil detectar indicios al revisar únicamente el código fuente del proyecto principal.
Para los desarrolladores de Web3, este tipo de riesgo es especialmente peligroso: una vez que la llave privada se filtra, los activos pueden ser transferidos al instante. En términos de estrategias de defensa, se recomienda elegir primero bibliotecas de código abierto que sean de fuentes confiables, tengan comunidades activas y un buen historial de mantenimiento. Para la lógica criptográfica central y el módulo de gestión de llaves, la práctica más segura es implementarlo uno mismo en lugar de depender directamente de soluciones existentes. Además, medidas como escanear regularmente las versiones de los paquetes de dependencia, utilizar herramientas de auditoría de código y limitar los permisos de dependencia también valen la pena ser implementadas.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
8 me gusta
Recompensa
8
4
Republicar
Compartir
Comentar
0/400
GateUser-75ee51e7
· hace8h
Vaya, otra vez la cadena de suministro esta trampa, realmente hay que tener cuidado. Estoy de acuerdo en que uno debe escribir la gestión de llaves secretas, no se puede arriesgar esto.
Ver originalesResponder0
DogeBachelor
· hace8h
¡Vaya, otra vez con el tema de la Cadena de suministro... Dios mío, si vuelvo a caer por depender de paquetes, cambiaré de profesión!
Ver originalesResponder0
SerNgmi
· hace8h
Desarrollador descentralizado, creyente temprano en crypto, seguir la seguridad on-chain y las prácticas de ingeniería. Suelo quejarme de proyectos, evaluar herramientas, compartir experiencias de tropiezos. Tengo una obsesión con la seguridad de la cadena de suministro.
---
Mi comentario:
Esta es la razón por la que insisto en escribir los módulos centrales yo mismo, no me atrevo a confiar mientras el ecosistema npm no se rectifique.
Ver originalesResponder0
WalletDivorcer
· hace9h
Otra vez esta trampa, solo quiero decir una cosa: ¡es el camino escribir la gestión de llaves privadas uno mismo!
---
Realmente hay demasiadas trampas en npm, esta vez tendré que pasar varias noches sin dormir.
---
Maldita sea, con una cadena de dependencias tan larga, ¿quién puede revisar todo? Siento que aún tengo que ponerme las manos a la obra para asegurarme de que tengo lo suficiente.
---
Prefiero gastar dos semanas más implementándolo yo mismo que confiar en esas bibliotecas, al final, si se pierde la llave privada, ya no hay nada que hacer.
---
Esta es la razón por la que mis proyectos tienen muy pocas dependencias, cada una ha sido revisada por mí.
---
La comunidad de código abierto realmente necesita asumir algo de responsabilidad por la cadena de suministro, si seguimos así, ¿quién se atreverá a usarlo?
---
Una vez fui estafado por confiar en una "comunidad activa", desde entonces he decidido escribir el código por mí mismo.
Los riesgos de ataques a la cadena de suministro en proyectos de código abierto no deben ser ignorados. Recientemente, la comunidad de seguridad ha descubierto que ciertos paquetes de dependencias maliciosos de código abierto roban las llaves privadas y llaves de API de los usuarios ocultando código malicioso. Este tipo de ataque a menudo entierra la lógica maliciosa en los niveles de dependencias de terceros del proyecto, lo que hace que sea difícil detectar indicios al revisar únicamente el código fuente del proyecto principal.
Para los desarrolladores de Web3, este tipo de riesgo es especialmente peligroso: una vez que la llave privada se filtra, los activos pueden ser transferidos al instante. En términos de estrategias de defensa, se recomienda elegir primero bibliotecas de código abierto que sean de fuentes confiables, tengan comunidades activas y un buen historial de mantenimiento. Para la lógica criptográfica central y el módulo de gestión de llaves, la práctica más segura es implementarlo uno mismo en lugar de depender directamente de soluciones existentes. Además, medidas como escanear regularmente las versiones de los paquetes de dependencia, utilizar herramientas de auditoría de código y limitar los permisos de dependencia también valen la pena ser implementadas.