Вероятность malware в дейли апдейтах open-source и что делать?
Если раньше было целесообразно проявлять некоторую осторожность при добавлении малоизвестного PPA
То теперь можете быть и с мейнстримом крупными продуктами так? Что делать? Какова стратегия? Есть ли ресурсы по безопасности чтобы automatic checks?
Автоматические проверки пригодны только для того, чтобы подсветить подозрительные места, нельзя надеяться на то, что они отловят все закладки. Поэтому обновляться придётся реже, новый код ревьювить, зависимости собирать вручную и хранить у себя. Или разрабатывать системы так, чтобы они не доверяли сами себе и легко откатывались на предыдущие версии.
Стратегия одна на все времена — устанавливайте только проверенное ПО от поставщиков, которым вы доверяете. У вас речь про PPA, но в тегах Windows — непонятно, какую ОС вы используете, но Debian и Ubuntu LTS следуют парадигме стабильности — просто так в репозиториях новая версия не появится, обновления закрывают преимущественно ошибки и уязвимости, с помощью патчей к текущей версии ПО.
Легко сказать! Когда у тебя тысячи микросервисов и каждый с весьма развесистые деревом зависимостей, постоянно проверять их все - огромный труд, а шанс на то, что мейнтейнер в одну из них засунет вредоносный код, стал высок. Опенсорс получил ужасный репутационный урон.
Сергей Горностаев, Шанс и раньше был высок — то тут, то там просунут, прогрузят, а то и удалят библиотеку, ух какие нехорошие, эти опенсорс-разработчики.
Фиксируйте версии по sha-хешу коммитов, зеркалируйте все зависимости. Если у вас действительно тысячи микросервисов, и вы задумались о проблеме только сейчас — вы некомпетентны.
ValdikSS, и как поможет "фиксация версии по sha-хэшу коммитов"? Пусть даже речь о модулях интерпретируемого языка, что мешает мейнтейнеру библиотеки, которую использует полмира, засунуть в код деструктивные действия при выполнении на хосте с русским IP или локалью, сделать коммит и опубликовать новую версию, а другим мейнтенерам в своих библиотеках использовать эту новую версию? Вы при обновлении используемой вашей системой библиотеки просматриваете весь её код и код всех транизитивных зависимостей каждый раз?
Сергей Горностаев, Фиксация по sha-хешу коммитов нужна для использования именно той версии ПО/зависимости, которую вы отрецензировали на предмет отсутствия вредоносной функциональности. Если речь идёт об условном git, то привязку к конкретной версии (тегу) автор/администратор репозитория может изменить, а хеш коммита подделать невозможно (на минуту забудем о коллизиях SHA1 и не будем принимать их во внимание).
что мешает мейнтейнеру библиотеки, которую использует полмира, засунуть в код деструктивные действия при выполнении на хосте с русским IP или локалью, сделать коммит и опубликовать новую версию, а другим мейнтенерам в своих библиотеках использовать эту новую версию?
Если речь всё ещё о репозитории серьёзных LTS-дистрибутивов, то обновлённая библиотека просто не попадёт в репозитории. Если это исправление проблемы безопасности, мейнтейнер дистрибутива вручную проанализирует и перенесёт код на ту версию, которая есть в дистрибутиве, в ином случае, наиболее вероятно, что вы на вашей версии дистрибутива просто не получите обновления библиотеки.
Вы при обновлении используемой вашей системой библиотеки просматриваете весь её код и код всех транизитивных зависимостей каждый раз?
Да, в большинстве своём, я просматриваю ченджлоги и часть изменений наиболее значимых компонентов при обновлении. Автоматически у меня происходят только обновления безопасности (здесь приходится доверять мейнтейнерам пакета/дистрибутива).
Если говорить о разработке ПО и использовании зависимостей/библиотек не из репозитория дистрибутива, то следует вести учёт всех зависимостей и использовать конкретную проаудированную (вами) версию.
Если вы полагаетесь на ПО, написанное человеком или группой, не имеющей с вами финансовых обязательств, не несущих репутационных рисков, с неизвестно у кого обладающего правами его изменения, в лицензии которого явно указано использование «как есть, без каких-либо гарантий», позволяете ему автоматически обновляться и не проводите его аудит, то не понимаю, чему здесь стоит возмущаться.
Если речь всё ещё о репозитории серьёзных LTS-дистрибутивов, то обновлённая библиотека просто не попадёт в репозитории.
Декабрьская уязвимость log4j наглядно продемонстрировала, что абсолютно все без исключения enterprise-проекты, включая мастадонтов типа Amazon и Netflix, не проверяют свои зависимости. Часто эти проекты держатся на использовании библиотек, у которых один мейнтейнер и условия использования "as is", таких как ByteBuddy например. Всё это жило на доверии к open source, но теперь энтерпрайзу придётся увеличивать все команды на 20-25%, нанимая в каждую ИБшников, которые будут заниматься постоянным аудитом зависимостей, или нанимая разработчиков для перехода с открытых решений на собственные проприетарные.
Сергей Горностаев, Вы привели пример проблемы безопасности. Её исправление, как раз, попадёт в репозитории, причём отдельным патчем на текущую версию программы/библиотеки, а не её обновлением до последней доступной, в подавляющем большинстве случаев.
Авторы log4j занимались исправлением уязвимости в течение нескольких дней, бесплатно, и получали только требования побыстрее это все залатать, хотя совершенно не обязаны были этого делать.
До этого мы с вами обсуждали проблему внезапного намеренного добавления вредоносного кода — это другая проблема, и предложенное мной решение применяется широко.
ValdikSS, думаю, что если Ральф Винтерхальтер обозлится из-за чего-то на США и сделает в ByteBuddy закладку, то Amazon точно так же её пропустит в прод, как пропустил уязвимость в log4j.
Простой
