История изменений

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости? Особенно это забавно может оказаться в том случае, если софт, упаковываемый в docker/статичный пакет - разрабатывается вполне себе открыто или какая-то его открытая версия есть на github, gitlab и т.п. В этом случае злоумышленнику достаточно знать: а) о «внезапной» (крайне предсказуемой) приверженности docker'у разработчиков приложения; б) о том, что нужные приложению библиотеки подключаются не извне (отдельным докер-слоем), а просто статично пакуются внутрь контейнера - и это тоже весьма предсказуемо, потому что разработчики как правило «выше этого», у них «более важные задачи» (чем забота о том, чтобы их приложение могло с минимальным ручным оверхедом работать с обновляемыми версиями библиотек).

При этом никакой реальной объективной проблемы с библиотеками общего пользования нет и в помине. Она реально просто придумана людьми, которые либо умозрительно делают заключение о том, что проблема может возникнуть, либо когда у них возникала такая проблема - даже не пытались разобраться в её причинах, свалив всё на «разные же версии». Почему так? Да потому что любые common used популярные библиотеки поддерживают ABI back compatibility на протяжении десятилетий. А если разработчик использует какую-то редкую библиотеку от Васи Пупкина - то здесь возникают вопросы совершенно иного характера (и её в общем-то можно упаковать в контейнер/пакет, предварительно всё-таки выяснив, почему вообще в проекте используется загадочная сторонняя библиотека).

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости? Особенно это забавно может оказаться в том случае, если софт, упаковываемый в docker/статичный пакет - разрабатывается вполне себе открыто или какая-то его открытая версия есть на github, gitlab и т.п. В этом случае злоумышленнику достаточно знать: а) о «внезапной» (крайне предсказуемой) приверженности docker'у разработчиков приложения; б) о том, что нужные приложению библиотеки подключаются не извне (отдельным докер-слоем), а просто статично пакуются внутрь контейнера - и это тоже весьма предсказуемо, потому что разработчики как правило «выше этого», у них «более важные задачи» (чем забота о том, чтобы их приложение могло с минимальным ручным оверхедом работать с обновляемыми версиями библиотек).

При этом никакой реальной объективной проблемы с библиотеками общего пользования нет и в помине. Она реально просто придумана людьми, которые либо умозрительно делают заключение о том, что проблема может возникнуть, либо когда у них возникала такая проблема - даже не пытались разобраться в её причинах, свалив всё на «разные же версии». Почему так? Да потому что любые common used популярные библиотеки поддерживают ABI на протяжении десятилетий. А если разработчик использует какую-то редкую библиотеку от Васи Пупкина - то здесь возникают вопросы совершенно иного характера (и её в общем-то можно упаковать в контейнер/пакет, предварительно всё-таки выяснив, почему вообще в проекте используется загадочная сторонняя библиотека).