Команда JavaScript for Devs подготовила перевод статьи о том, почему JavaScript-сообщество снова проигнорирует шанс исправить фундаментальные проблемы своей экосистемы после крупнейшей атаки на цепочку поставок. Автор предлагает здравый план — от стандартной библиотеки до новых практик управления зависимостями, — но считает, что индустрия снова ограничится символическими жестами.
После крупнейшей в истории атаки на цепочку поставок JavaScript-сообщество могло бы прийти в себя и решить: никогда больше. Когда паника и стыд улягутся, когда скомпрометированные разработчики закончат перенастраивать свои рабочие станции и менять ключи, экосистема, возможно, переориентируется на устранение фундаментальных недостатков, которые позволили этому произойти.
В конце концов, люди годами били тревогу, что такой подход к управлению зависимостями безрассуден, опасен и изначально ущербен. Возможно, это тот момент, когда экосистема JavaScript начнет осознавать важность и срочность этой проблемы и начнет корректировать свой курс. Она могла бы оставить позади свои разрастающиеся деревья зависимостей, полные микробиблиотек, наладить распространение программного обеспечения на основе доверительных отношений и включить в себя десятилетия исследований и инноваций, созданных более серьезными системами управления зависимостями.
Возможно, Google и Mozilla, лидеры в стандартах и реализациях JavaScript, начнут разрабатывать реальную стандартную библиотеку для JavaScript, которая сделает микрозависимости, такие как left-pad, пережитком прошлого. Это можно было бы сочетать с консолидацией усилий, объединением микробиблиотек в более крупные пакеты с более согласованной и целостной областью применения и целью, которые, в свою очередь, сократят свои деревья зависимостей.
Это мог бы быть момент, когда npm смирится со своим ущербным дизайном и, приложив хорошо финансируемые усилия (напомним, что в конечном итоге npm — это GitHub, а GitHub — это Microsoft, рыночная капитализация которой составляет 3 триллиона долларов США), разработает и внедрит следующее поколение управления пакетами для JavaScript. Он мог бы включить в себя практики, разработанные и проверенные в дистрибутивах Linux, которые редко страдают от подобных атак, путем разделения разработки от упаковки и распространения, создания сопровождающих пакетов, которые собирают и распространяют тщательно подобранные коллекции программных библиотек. Путем внедрения универсальных подписей для пакетов исполняемого кода, более мелких каналов и сетей доверия, воспроизводимых сборок и многих других простых, очевидных методов, используемых ответственными менеджерами пакетов.
Возможно, другие языки, зависящие от этой сломанной модели управления зависимостями, такие как Cargo, PyPI, RubyGems и многие другие, наблюдают за этим инцидентом и знают, что тот же самый кризис маячит в их будущем. Возможно, они тоже изменят курс до неизбежного.
Представьте, если бы другие крупные корпорации, которые зависят от этой огромной кучи безрассудно организованного программного обеспечения и извлекают из нее выгоду, вложили свои деньги и ресурсы в ее развитие, привлекая своих инженеров к решению этих проблем, объединяясь для установления и внедрения новых стандартов, напрямую финансируя свои зависимости и распределяя деньги через такие учреждения, как NLNet, открывая эру ответственной, устойчивой и безопасной разработки программного обеспечения.
Было бы здорово, если бы будущее было именно таким, но оно нас не ждет. Нас ждет то же самое, что и раньше. Ждите символических жестов — обязательная двухфакторная аутентификация (2FA) будет внедряться повсеместно, это точно, а крупные игроки будут списывать скудные пожертвования на «безопасность и устойчивость Open Source» в своих маркетинговых бюджетах.
Никто не извлечет уроков. Это происходит десятилетиями, и никто до сих пор ничему не научился. В этом заключается определяющая дерзость этого поколения разработчиков ПО.
Русскоязычное JavaScript сообщество

Друзья! Эту статью перевела команда «JavaScript for Devs» — сообщества, где мы делимся практическими кейсами, инструментами для разработчиков и свежими новостями из мира Frontend. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (6)
mSnus
03.10.2025 12:04Технические подробности атаки можно прочитать здесь: https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised
bromzh
Так а в чем предложение-то состоит? Как надо сделать? Как обогащение стандартной библиотеки защитит от атаки на просто популярные пакеты и как некая линуксовая модель распространения применима к библиотекам языка?
mSnus
Решение, которое первым приходит в голову:
не хранить все ключи вперемешку в одном файле .env
если не получается использовать что-то типа Vault, а надо хранить именно ключи, достаточно было бы файла secrets.json со структурой "ключ => компоненты, которым разрешен к этому ключу доступ" и механизма доступа к этим ключам из папки secrets
David_Osipov
Это должно было быть в статье, а не в комментах. По сути, статья о том "как плохо жизнь жить", хотя казалось бы, можно было бы упомянуть об экспериментальной функциональности предоставления разрешений или уже о рантайме Deno.
sanchas
Я так понимаю речь идет о том, чтобы функционал самых распространенных и при этом небольших пакетов включить в стандартную библиотеку. Хотя это не решит проблему полностью, но снизит вероятность негативных последствий да и сами последствия. Мелкие пакеты содержащие несколько простых но полезных функций - основной вектор атаки. Часто они поддерживаются единственным разработчиком, который не всегда серьезно относится к безопасности. А когда такой пакет добавляют в зависимости из сотни других пакетов, это приводит к тому, что вероятность получения зловредного кода сильно возрастает.