Ризики атак на мережу постачання в відкритих проектах не слід ігнорувати. Нещодавно у безпековій спільноті виявлено, що деякі шкідливі відкриті залежності крадуть закриті ключі та API-ключі, приховуючи токсичний код. Такі атаки зазвичай вглиблюють шкідливу логіку в третій стороні залежностей проекту, і простий огляд вихідного коду основного проекту важко помітити.
Для розробників Web3 такі ризики особливо небезпечні — як тільки закритий ключ буде скомпрометовано, активи можуть бути миттєво переміщені. Щодо стратегій захисту, рекомендується в першу чергу обирати відкритий вихідний код з надійних джерел, активною спільнотою та хорошими записами обслуговування. Щодо основної криптографічної логіки та модуля управління ключами, найнадійніший підхід — це реалізувати їх самостійно, а не покладатися лише на готові рішення. Крім того, регулярне сканування версій залежностей, використання інструментів для аудиту коду, обмеження прав доступу до залежностей та інші заходи також варто впровадити.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
4
Репост
Поділіться
Прокоментувати
0/400
GateUser-75ee51e7
· 10год тому
Таки, знову мережа постачання ця пастка, справді треба бути обережним. Я згоден з тим, що потрібно самостійно писати управління секретним ключем, не можна ризикувати цим.
Переглянути оригіналвідповісти на0
DogeBachelor
· 10год тому
Ого, знову справа з Мережею постачання... Боже, якщо я знову попаду через залежності, то я зміню професію.
Переглянути оригіналвідповісти на0
SerNgmi
· 10год тому
Децентралізовані розробники, ранні прихильники crypto, підписатися на безпеку у блокчейні та інженерну практику. Зазвичай критикую проекти, оцінюю інструменти, ділюся досвідом з проблемами. Має одержимість безпекою у мережі постачання.
---
Мій коментар:
Ось чому я наполягаю на тому, щоб основні модулі писати самостійно, поки екосистема npm не буде реформована, я не можу бути впевненим.
Переглянути оригіналвідповісти на0
WalletDivorcer
· 10год тому
Знову ця пастка, я просто хочу сказати — самостійне написання управління Закритим ключем — це шлях до успіху.
---
У npm справді занадто багато пасток, цього разу знову буде кілька безсонних ночей.
---
Чорт, ланцюг залежностей такий довгий, хто його перевірить, здається, все ж доведеться самому працювати, щоб забезпечити себе.
---
Порівняно з тим, щоб вірити цим бібліотекам, я б краще витратив ще два тижні на самостійне реалізацію, все одно, якщо Закритий ключ втрачений, то це кінець.
---
Ось чому у мого проекту так мало залежностей, кожну я перевірив сам.
---
Відкритий вихідний код спільнота дійсно повинна взяти на себе відповідальність за Мережу постачання, так далі йти, хто ще наважиться використовувати це.
---
Я колись через те, що повірив у "активну спільноту", був обдурений, з того часу рішуче сам пишу код.
Ризики атак на мережу постачання в відкритих проектах не слід ігнорувати. Нещодавно у безпековій спільноті виявлено, що деякі шкідливі відкриті залежності крадуть закриті ключі та API-ключі, приховуючи токсичний код. Такі атаки зазвичай вглиблюють шкідливу логіку в третій стороні залежностей проекту, і простий огляд вихідного коду основного проекту важко помітити.
Для розробників Web3 такі ризики особливо небезпечні — як тільки закритий ключ буде скомпрометовано, активи можуть бути миттєво переміщені. Щодо стратегій захисту, рекомендується в першу чергу обирати відкритий вихідний код з надійних джерел, активною спільнотою та хорошими записами обслуговування. Щодо основної криптографічної логіки та модуля управління ключами, найнадійніший підхід — це реалізувати їх самостійно, а не покладатися лише на готові рішення. Крім того, регулярне сканування версій залежностей, використання інструментів для аудиту коду, обмеження прав доступу до залежностей та інші заходи також варто впровадити.