Команда 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. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (17)
mSnus
03.10.2025 12:04Технические подробности атаки можно прочитать здесь: https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised
pavelsc
03.10.2025 12:04Не даёт покоя некоторым сделать из нормальной системы очередной .NET Framework. Хорошо, что этот фарш назад уже не прокрутить
Noah1
03.10.2025 12:04Это у JavaScript-то нормальная экосистема? Не смешите. Нет ничего более хаотичного и непостоянного, чем js. В .NET конечно полная беда с депрекейтед компонентами и неймингом своих нововведений, но они хотя бы в верном направлении развиваются(в качестве подтверждения - большинство последних обновлений Java скопировала).
muhachev
03.10.2025 12:04Очередгая. заранее проигранная, битва с дураками, ибо сказано: сколько не прикручивай защит от дураков, всегда найдутся более продвинутые дураки.
Qweker
03.10.2025 12:04Пст.
Проходи мимо. Питонист пишет про некий JavaScript. Статья водичка чистая. Ещё лучше, ставь минус данной статье.
Pubert
03.10.2025 12:04Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
BadCoder1337
03.10.2025 12:04Прочитав про антифа статьи автора стало ясно, что статья бред не просто так. Но если по фактам, то в чем может быть роль дистрибутора пакетов для скриптовых языков? Скачать сорцы с GitHub и перелить без изменений в npm?
Схема с отдельным дистрибутором живет только потому, что для бинарных зависимостей неочевидны изменения внесенные в готовый код перед сборкой. Да и на самом базовом софте банкет-то и заканчивается. Нужно поставить что-то свежее предлагаемого копролита - добавляй левые PPA, собирай из непроверенных сорцов, запускай под рутом сетевые скрипты установки.
LuxQ
03.10.2025 12:04Ах, опять эти старческие вздохи о том, как "раньше трава была зеленее, а зависимости - надёжнее". Автор так трогательно нарисовал картину апокалипсиса в
node_modules, что я чуть не пролил смузи на свой MacBook. Кажется, кто-то открыл для себя практики 30-летней давности и теперь пытается научить нас, инноваторов, жить.Разработайте стандартную библиотеку!
Серьёзно? Стандартная библиотека? Это так... по-джавистски.
Консолидируйте микробиблиотеки!
Автор просто не понимает всей красоты атомарности. Каждый пакет - это произведение искусства, решающее одну-единственную задачу.
Учитесь у дистрибутивов Linux!
О да, давайте превратим
npmв забюрократизированный редмондский кошмар с "сопровождающими", "сетями доверия" и "воспроизводимыми сборками". Звучит ужасно медленно.Никто не извлечет уроков
А вот тут - бинго! Единственная здравая мысль во всей статье. Конечно, не извлечет. Потому что извлекать нечего. "Атака на цепочку поставок" — это просто цена, которую мы платим за жизнь на передовой прогресса. Сломалось? Починим. Взломали? Накатим 2FA (как автор и предсказал, кстати, гений аналитики) и побежим дальше.
Так что спасибо автору за заботу, но мы, пожалуй, откажемся от его "здравого плана". У нас тут своя атмосфера: динамичная, хаотичная и весёлая.
bromzh
Так а в чем предложение-то состоит? Как надо сделать? Как обогащение стандартной библиотеки защитит от атаки на просто популярные пакеты и как некая линуксовая модель распространения применима к библиотекам языка?
mSnus
Решение, которое первым приходит в голову:
не хранить все ключи вперемешку в одном файле .env
если не получается использовать что-то типа Vault, а надо хранить именно ключи, достаточно было бы файла secrets.json со структурой "ключ => компоненты, которым разрешен к этому ключу доступ" и механизма доступа к этим ключам из папки secrets
David_Osipov
Это должно было быть в статье, а не в комментах. По сути, статья о том "как плохо жизнь жить", хотя казалось бы, можно было бы упомянуть об экспериментальной функциональности предоставления разрешений или уже о рантайме Deno.
sanchas
Я так понимаю речь идет о том, чтобы функционал самых распространенных и при этом небольших пакетов включить в стандартную библиотеку. Хотя это не решит проблему полностью, но снизит вероятность негативных последствий да и сами последствия. Мелкие пакеты содержащие несколько простых но полезных функций - основной вектор атаки. Часто они поддерживаются единственным разработчиком, который не всегда серьезно относится к безопасности. А когда такой пакет добавляют в зависимости из сотни других пакетов, это приводит к тому, что вероятность получения зловредного кода сильно возрастает.
Fr3nzy
Ни в чем. У автора оригинальной статьи следующая статья называется Cloudflare bankrolls fascists. Человек просто любит писать громкие заголовки и пустые статьи.
Еще и ANTIFA пиарит у себя в блоге. Удачи ему.
aamonster
Я понял посыл, как "у Микрософт много денег, пусть они сделают хорошо и безопасно".
theult
Мелкомягкие не считают js своим техническим долгом, тут больше похоже на проблемы дальних родственников, которые можно и нужно решать, но у них лапки.