Вероятность malware в дейли апдейтах open-source и что делать?

Question

[uyrij]

Если раньше было целесообразно проявлять некоторую осторожность при добавлении малоизвестного PPA
То теперь можете быть и с мейнстримом крупными продуктами так? Что делать? Какова стратегия? Есть ли ресурсы по безопасности чтобы automatic checks?

Comments

[posters]

Я пропустил какую-то новость? Хакеры взломали гатхаб?)

[shurshur]

posters, погуглить в новостях node-ipc.

[posters]

shurshur, спасибо

Answer 1

[Сергей Горностаев]

Автоматические проверки пригодны только для того, чтобы подсветить подозрительные места, нельзя надеяться на то, что они отловят все закладки. Поэтому обновляться придётся реже, новый код ревьювить, зависимости собирать вручную и хранить у себя. Или разрабатывать системы так, чтобы они не доверяли сами себе и легко откатывались на предыдущие версии.

Answer 2

[Владимир Коротенко]

да бог ты мой индусы этой фигней не занимаются, они рушат системы просто так.

Создайте политику для обновлений, подопытные, пользователи, критические сервисы

Comments

[uyrij]

Про индусов, lol

Answer 3

[Drno]

ничего не изменилось. все работает как и было до этого

Comments

[Сергей Горностаев]

https://dtf.ru/flood/1120898-avtor-npm-modulya-ras...

Answer 4

[ValdikSS]

Стратегия одна на все времена — устанавливайте только проверенное ПО от поставщиков, которым вы доверяете. У вас речь про PPA, но в тегах Windows — непонятно, какую ОС вы используете, но Debian и Ubuntu LTS следуют парадигме стабильности — просто так в репозиториях новая версия не появится, обновления закрывают преимущественно ошибки и уязвимости, с помощью патчей к текущей версии ПО.

Comments

[Сергей Горностаев]

Легко сказать! Когда у тебя тысячи микросервисов и каждый с весьма развесистые деревом зависимостей, постоянно проверять их все - огромный труд, а шанс на то, что мейнтейнер в одну из них засунет вредоносный код, стал высок. Опенсорс получил ужасный репутационный урон.

[ValdikSS]

Сергей Горностаев, Шанс и раньше был высок — то тут, то там просунут, прогрузят, а то и удалят библиотеку, ух какие нехорошие, эти опенсорс-разработчики.
Фиксируйте версии по sha-хешу коммитов, зеркалируйте все зависимости. Если у вас действительно тысячи микросервисов, и вы задумались о проблеме только сейчас — вы некомпетентны.

[Сергей Горностаев]

ValdikSS, и как поможет "фиксация версии по sha-хэшу коммитов"? Пусть даже речь о модулях интерпретируемого языка, что мешает мейнтейнеру библиотеки, которую использует полмира, засунуть в код деструктивные действия при выполнении на хосте с русским IP или локалью, сделать коммит и опубликовать новую версию, а другим мейнтенерам в своих библиотеках использовать эту новую версию? Вы при обновлении используемой вашей системой библиотеки просматриваете весь её код и код всех транизитивных зависимостей каждый раз?

[ValdikSS]

Сергей Горностаев, Фиксация по sha-хешу коммитов нужна для использования именно той версии ПО/зависимости, которую вы отрецензировали на предмет отсутствия вредоносной функциональности. Если речь идёт об условном git, то привязку к конкретной версии (тегу) автор/администратор репозитория может изменить, а хеш коммита подделать невозможно (на минуту забудем о коллизиях SHA1 и не будем принимать их во внимание).

что мешает мейнтейнеру библиотеки, которую использует полмира, засунуть в код деструктивные действия при выполнении на хосте с русским IP или локалью, сделать коммит и опубликовать новую версию, а другим мейнтенерам в своих библиотеках использовать эту новую версию?

Если речь всё ещё о репозитории серьёзных LTS-дистрибутивов, то обновлённая библиотека просто не попадёт в репозитории. Если это исправление проблемы безопасности, мейнтейнер дистрибутива вручную проанализирует и перенесёт код на ту версию, которая есть в дистрибутиве, в ином случае, наиболее вероятно, что вы на вашей версии дистрибутива просто не получите обновления библиотеки.

Вы при обновлении используемой вашей системой библиотеки просматриваете весь её код и код всех транизитивных зависимостей каждый раз?

Да, в большинстве своём, я просматриваю ченджлоги и часть изменений наиболее значимых компонентов при обновлении. Автоматически у меня происходят только обновления безопасности (здесь приходится доверять мейнтейнерам пакета/дистрибутива).

Если говорить о разработке ПО и использовании зависимостей/библиотек не из репозитория дистрибутива, то следует вести учёт всех зависимостей и использовать конкретную проаудированную (вами) версию.
Если вы полагаетесь на ПО, написанное человеком или группой, не имеющей с вами финансовых обязательств, не несущих репутационных рисков, с неизвестно у кого обладающего правами его изменения, в лицензии которого явно указано использование «как есть, без каких-либо гарантий», позволяете ему автоматически обновляться и не проводите его аудит, то не понимаю, чему здесь стоит возмущаться.

[Сергей Горностаев]

ValdikSS,

Если речь всё ещё о репозитории серьёзных LTS-дистрибутивов, то обновлённая библиотека просто не попадёт в репозитории.

Декабрьская уязвимость log4j наглядно продемонстрировала, что абсолютно все без исключения enterprise-проекты, включая мастадонтов типа Amazon и Netflix, не проверяют свои зависимости. Часто эти проекты держатся на использовании библиотек, у которых один мейнтейнер и условия использования "as is", таких как ByteBuddy например. Всё это жило на доверии к open source, но теперь энтерпрайзу придётся увеличивать все команды на 20-25%, нанимая в каждую ИБшников, которые будут заниматься постоянным аудитом зависимостей, или нанимая разработчиков для перехода с открытых решений на собственные проприетарные.

[ValdikSS]

Сергей Горностаев, Вы привели пример проблемы безопасности. Её исправление, как раз, попадёт в репозитории, причём отдельным патчем на текущую версию программы/библиотеки, а не её обновлением до последней доступной, в подавляющем большинстве случаев.
Авторы log4j занимались исправлением уязвимости в течение нескольких дней, бесплатно, и получали только требования побыстрее это все залатать, хотя совершенно не обязаны были этого делать.

До этого мы с вами обсуждали проблему внезапного намеренного добавления вредоносного кода — это другая проблема, и предложенное мной решение применяется широко.

[Сергей Горностаев]

ValdikSS, думаю, что если Ральф Винтерхальтер обозлится из-за чего-то на США и сделает в ByteBuddy закладку, то Amazon точно так же её пропустит в прод, как пропустил уязвимость в log4j.