Можно Установить Пакет, но Владеете ли вы им? Начало
Создавайте форки зависимостей, ограничивайте их только вашими вариантами использования, никогда не обновляйте без крайней необходимости. Обновление гораздо рискованнее, чем обнаружение скрытых ошибок (которые можно отслеживать, а CVE – мониторить). Если вы обновляете зависимость, вы должны проанализировать каждый коммит во всё транзитивном наборе зависимостей. Если вы не видите ничего убедительного, не обновляйте!
Я помню, как в HashiCorp инженеры иногда пытались обновить зависимость или заменить самодельную библиотеку внешней, и я всегда спрашивал: «Покажите мне нужный коммит». Не обновляйте просто так.
Я очень доволен таким подходом, учитывая все эти атаки на цепочки поставок.
Это от Митчелла Хашимото
Вроде звучит здраво. Но есть проблема. Можно создать форк небольшой библиотеки и сократить её до того, что вам нужно. Но можно ли создать форк React и поддерживать его? Думаю, большинство команд не смогут. Поэтому совет «создавайте форки зависимостей» прекрасен до тех пор, пока зависимость не становится слишком большой.
Дело не ограничивается созданем форка. Дело в том, чтобы точно знать, за что вы взялись, и быть готовым взять на себя ответственность. Мы устанавливаем зависимость и берём на себя все проблемы, возникающие с зависимостями:
- атаки на цепочку поставок,
- лицензионные споры,
- недоработанные спецификации,
- проблемы, о которых узнаешь только после поломки…
Все они сводятся к тому, что мы стали зависеть от чужого продукта, даже не принимая на себя такого решения.
Устанавливать или нет?
Установить Automapper или написать маппинг вручную? Конечно, гораздо проще установить пакет и передать его обслуживание на аутсорс. Особенно когда вы спешите, вы ставите, что есть, и это может быть неплохим промежуточным решением, но затем стоит задуматься о следующем шаге.
Посмотрите, какие пакеты на самом деле попадают под все эти атаки на цепочки поставок. Почти всегда это мелочи. Помните инцидент с Left-pad? Обычно это какой-нибудь крошечный или низкоуровневый вспомогательный код, о котором никто не задумывается. Они повсюду, они тривиальны, и именно поэтому никто за ними не следит. Поэтому их так легко написать самому. Так что написание небольшого вспомогательного кода от руки — это не паранойя. Это более спокойный вариант, и это один из немногих случаев, когда точно знаешь, что находится в твоей системе.
Будьте дотошны в выборе зависимостей, которые вы устанавливаете, посмотрите, сколько зависимостей они подключают, и учитывайте это при принятии решения. Само число не имеет значения. Оно просто показывает, насколько вы соглашаетесь владеть чем-то, даже не видя этого.
И прямые зависимости – ещё не худшее. Чаще всего можно их прочитать и понять, что они делают. Страшно то, что происходит с транзитивными зависимостями, вплоть до самых нижних уровней, — то, что вы не выбирали, не видите и на что не можете повлиять.
Поэтому дело не в достижении нулевого количества зависимостей, а в наличии только тех, которые мы осторожно согласовали. Нельзя принимать решения, основываясь на том, чего не видишь, и если у вас нет даже базовых знаний (например, списка) того, от чего вы зависите, то любой разговор о рисках в цепочке поставки превращается в гадание.
Инвентаризация зависимостей
В большинстве сред существуют инструменты для генерации SBOM (Software Bill of Materials) — инвентаризации дерева зависимостей. Проблема в том, что большинство организаций никогда в жизни не создавали ни SBOM, ни инвентаризации, ничего нигде не записано. Поэтому в день следующего Log4Shell, а он обязательно будет, они не смогут ответить на самый первый вопрос, который им зададут: используем ли мы это, и если да, то где?
Окончание следует…
Источник: https://www.architecture-weekly.com/p/you-can-fork-a-package-but-can-you