EnglishРусский Map
Dependency Vendoring

Меньше переиспользуйте чужой софт

title
Меньше переиспользуйте чужой софт
type
summary
summary
Мы переиспользуем слишком много софта; вендоринг зависимостей нужен как противопожарная полоса от атак на цепочку поставок
tags
dependencies, supply-chain, software-culture
created
2026-07-21
updated
2026-07-21
lang
ru
translation_of
reuse-less-software
source_updated
2026-07-21
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-medium

Эссе icefox (Саймон Хит) в вики alopex, июнь 2026 года. Тезис: дешёвая дистрибуция софта вместе с автоматической загрузкой зависимостей вывернули кризис программной инженерии 1970-х наизнанку. Раньше было трудно переиспользовать достаточно; теперь мы переиспользуем слишком много, и решение для растущих рисков цепочки поставок - вендорить каждую зависимость, чтобы остановить их автоматическое распространение. (Автор сразу называет заголовок кликбейтом.)

Как мы к этому пришли

"Кризис программного обеспечения" 1960-70-х годов заключался в экспоненциальном росте спроса на софт при сублинейной способности его создавать и повторно использовать. Это подтолкнуло исследования в области модульности и структурного программирования - модульные системы во всех языках с 1990 года восходят к Modula-2. Затем в 1990-2000-х дистрибуция подешевела: опенсорс и энтузиазм волонтёров породили пакетные репозитории и менеджеры (CPAN, CTAN, дистрибутивы Linux), которые скачивают и собирают софт, зная лишь название и номер версии. Собирать SDL вручную в 2003 году было мучительно; автор прямо говорит, что никто не должен тосковать по тем временам.

Современный софт на Rust, Go и в Docker'е почти не трогает системные библиотеки - сборочные системы затягивают зависимости напрямую. Это решило старый кризис и породило новый: ад зависимостей, раздутый объём, долгие сборки и мейнтейнеров, исчезающих в никуда. Использование софта всё ещё сопряжено с издержками, даже если его распространение бесплатно.

Проблема цепочки поставок

Атаки на цепочку поставок - не новость. В эссе в качестве раннего примера приводится классическая попытка внедрить вредоносный патч в ядро Linux - uid = 0 вместо uid == 0. Изменилась автоматизация: CI запускается на каждое изменение, и скомпрометированная зависимость "распространяется со скоростью лесного пожара, так быстро, как только исполнители CI успевают её выполнить". Автоматическая загрузка, удешевившая повторное использование, стала и каналом распространения атаки.

Предложение

Перестать автоматически подтягивать зависимости во время сборки. Вендорить всё - копировать исходный код апстрима в свой git-репозиторий и коммитить его; когда апстрим обновляется, копировать снова; автоматизировать копирование в инструменте сборки; сделать так, чтобы lock-файл соответствовал закоммиченному полному дереву исходников. "Vendor the shit out of your project... Own every line of source code with the iron fist of an absolute control freak."

Это превращает каждый пакет в противопожарную полосу против атак на цепочку поставок. Это также противопожарная полоса против распространения исправлений ошибок, с чем автор соглашается: если исправление важно, вы найдёте его сами, а если не ищете, оно обычно и не важно. Страница dependency-vendoring разбирает механику и компромиссы более подробно.

Возражения и побочные эффекты

В эссе опровергаются очевидные возражения. Разрастание git-репозитория - диск стоит дёшево. Время сборки - вы в любом случае пересобирали бы этот код. Усложнение переиспользования - это в основном касается пар клиент-сервер с общей библиотекой протокола, которым и так приходится решать проблемы несоответствия версий. Полезный побочный эффект: вендоринг повышает заметность и цену зависимостей, поэтому "библиотека на 200 строк", в которой на самом деле 50 000 строк, сразу бросается в глаза, подталкивая к более плоским и широким деревьям. Автор надеется сократить типичное количество зависимостей "с 200-300" до "максимум 2-3". Реальный минус - отсутствие автоматической транзитивной дедупликации. Логический предел этого подхода - Nix/Guix, которые автор одобряет.

См. также

  • dependency-vendoring - механика, эффект заметности и логический предел в виде Nix/Guix
  • supply-chain-security - класс атак и отложенное обновление зависимостей (cooldown) как более мягкий вариант
  • abi-stability - смежная причина победы самодостаточных артефактов: недоверие к окружающему окружению
  • open-source-security-astral - периоды охлаждения (cooldowns) и Trusted Publishing как альтернативные меры защиты
  • tanstack-npm-supply-chain-postmortem - конкретная атака с автораспространением того типа, который блокирует вендоринг
  • anubis-wasm-vendor-binary - вендоринг бинарного файла на практике и воспроизводимость, которой он требует