Comments 28
А как на счет того что бы особо пристально следить за конкретными разработчиками которые попались на подозрительной деятельности? Условно говоря, если в проекте были коммиты от автора node‑ipc - то есть смысл проверить такой коммит и в целом подозрительно относиться к проекту в котором апрувят коммиты от таких людей.
Python c PyPi ещё, терпимо: в типичном среднем проекте 20-60 зависимостей. А вот экосистема javascript — это что-то... Смотрю наши проекты: приложение на vuejs — 3220 уникальных пакетов-версий, на реакте — 6386, бек на ноде — жалкие 772. Понятно, что с такими числами хотя бы минимально прикинуть, что за проекты ты используешь, нет никакой реальной возможности.
В питончике я стараюсь поглядывать, что попадает в полный список зависимостей, и всякий раз расстраиваюсь, когда после обновления список зависимостей расширяется.
Если честно, то я удивлён, что реальных атак по большому счёту так мало, так как при наличие целеустремлённости сначала внедрить зависимость на свою полезную мелкую библиотеку, а потом подновить её, добавив зловредной функциональности — не особо большой фокус.
А ведь ещё можно бывают пакеты с бинарными артефактами...
На самом деле крупные корпорации вкладывают кучу денег в безопасность. Например, в статье упоминают Checkmarx. Это гигантский сервис, включающий в себя функции статического анализа приложений SAST (static application security testing), динамического DAST, композиционного анализа SCA (software composition analysis) и т.п.
Последнее в автоматическом режиме проводит анализ зависимостей приложения - да вот этих самых over 9k зависимостей (и зависимостей зависимостей) какого-либо hello world на react.js - и на выходе даёт отчёты о совместимости лицензий, наличии уязвимостей в коде со ссылками на CVE и многое другое. Интернировав такие проверки в CI/CD, компании начинают оперативно получать информацию о возможных инцидентах.
В общем, содержимое публичных репозиториев постоянно сканируется и при обнаружении инцидентов платежеспособная часть сразу получает уведомления. Далее что-то выносится в паблик, в виде твитов, статей или бесплатной помощи - баг репортов в опенсорсные проекты. В целом экосистема находится под постоянным контролем и поэтому довольно легко переносит разные катаклизмы, всплески различного malware, protestware (https://github.com/open-source-peace/protestware-list), и т.п.
Смотрю на наши проекты: 160 пакетов в node_modules на все 70 проектов. Возможно вам стоит почистить свои ряды?
Ваш подход улучшает ситуацию в определенном домене. Но представьте ситуацию на уровне компании, когда количество собственных репозиториев начинает измеряется тысячами, а счёт технологий идёт на десятки: go, rust, c++, python, c#, java, swift, js, ts, sh, ansible, terraform, docker и куча других. У каждого есть свой механизм определения зависимостей и желание что-то вытянуть снаружи. Тут 100 или 10000 уже не имеет принципиального значения - руками за всем не уследить и нужен комплексный подход.
То что в одном месте/аспекте всё плохо ещё не повод переставать заниматься улучшениями в другом. При этом реклама $mol меня тоже уже притомила.
За сотней руками вполне себе уследить. А за желание тянуть что попало снаружи надо бить по рукам.
Все постоянно меняется внутри и периодически меняется снаружи. Сегодня мейтейнер адекватный, через год съедет с катушек. Безопасность это вопрос рисков. А риски это штука вероятностная. В том смысле, что негативное развитие ситуации это не если, а когда . Минимизировать зависимости полезно не только в плане security. Но само по себе это не является решением данной проблемы. Даже если вы можете контролировать набор своих непосредственных зависимостей, то на зависимости зависимостей влиять уже не можете.
Зря заминусили, мысль верная, наверное за резкость высказывания.
Если сформулировать помягче и на языке бизнеса: каждый новый пакет (зависимость) — это не asset, а liability, и рассматривать его с этой точки зрения. Тогда и не будет случаться node_modules.jpg
Для бэка обычно безопасники открывают доступ во вне только для конкретных доменов по заявкам (сайты партнеров, госушные и проч), что решает проблему сброса инфы на какие-то мутные сайты.
Но идея,конечно, правильная, подтягивая 100500 зависимостей, даже не думаешь нарваться на пасхалочку.
А как можно "заглядывать" в свои зависимости? Ну первый уровень, то что явно прописано в моём package.json, ещё можно проверить. Но каждый из них тянет свои зависимости, они свои и так до бесконечности. В итоге можно откуда-то из глубин получить зловред и хрен его найдешь. Что-то не так в корне всей этой кухни...
Ну вручную системно это не сделать. У OWASP неплохо описана эта проблема безопасности, которую создают зависимости (причем не только программные), с примерами соответствующих подходов и инструментов для снижения рисков https://owasp.org/www-community/Component_Analysis
Спасибо за пост. Можно ли поменять цвета на графике "Number of releases by day of week"?
Плохо что на сайте PyPi можно выставлять свои значения в статистике — звезды GitHub, форки, скачивания.
Мне кажется ваш труд прямо коррелирует с PT PyAnalysis от Positive Technologies.
https://habr.com/ru/company/pt/blog/715754/
Да такая беда есть везде, где используются репозитории.
Unity, Gradle и др.
Очередное исследование, а сервис то есть, который можно прикупить по подписке?
А ваш продукт полностью закрытый? Он не будет открытым инструментом, что бы им пользовались и дополняли его?
Для разработчиков, тянущих в проект зависимости на каждый чих, есть отдельный котёл в аду. Стоит рядом с котлом для админов, гоняющих curl | sudo bash
С моей врождённой подозрительностью не приходится удивляться....
По вашему мнению, Леонид, избежать этого можно только начав контролировать и опенсорс? То есть убив саму идею опенсорса?
Или оставим все же свободу, в том числе и попасть в неприятную ситуацию?
А вы давно заглядывали внутрь ваших зависимостей?