Безопасность сторонних зависимостей — проверяем при помощи snyk
Недавно была прекрасная публикация “Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов”, на которую я переводил ответ. Автор недавно опубликовал вторую часть, но, подозреваю, что перевода не будет - там предлагается решать проблему прекрасными способами вроде перевода важных элементов ввода “в отдельный iframe” или “на особые страницы без стороннего javascript”. На этом месте те, кто повёлся на первую статью, должны бы усомниться в адекватности автора - и низкий (относительно предыдущей) рейтинг новой статьи это показывает.
UPD: перевели таки.
Тем не менее, проблема сторонних зависимостей есть, и решать её как-то нужно. Причём стоит она в равной степени в любой экосистеме, где используются сторонние зависимости. В комментариях к прошлому посту уже запрашивали какой-нибудь вариант решения, и я хочу представить один из них - инструмент под названием snyk.
Snyk это довольно популярный инструмент, но на хабре я пока не встречал его упоминаний. Он умеет проверять зависимости для многих экосистем (Javascript, Ruby, Python, Scala and Java) по своей базе - и авторы уверяют, что их база уязвимостей большая. Можно посмотреть на неё своими глазами. Код проекта открыт, лежит на гитхабе и у него довольно много звёздочек и форков:
Основные возможности
Описание взято с сайта проекта, делаем скидку на marketing bullshit, повторения есть и в оригинале. Личные впечатления будут ниже.Поиск
- Поиск уязвимостей в Javascript, Ruby, Python, Scala и Java
- Проверка GitHub репозиториев
- Проверка open source пакетов перед использованием
- Используется собственная база уязвимостей Snyk
Мониторинг
- Проверка зависимостей приложения
- Интеграция в CI процессы
- Предупреждения о новых уязвимостях в реальном времени
- Поддержка приложений на AWS Lambda и Heroku
Исправление
- Обновление или исправление уязвимых зависимостей
- Автоматические пулл реквесты от Snyk в gihub репозитории на Node.js и Ruby
- Пулл реквесты с выбранными исправлениями
- Интерактивный помощник для быстрого применения исправлений
- Уведомление о новых уязвимостях, которые затрагивают ваши проекты
- Уведомления в Slack и по емейлу о уязвимостях и их исправлении
- Понятный анализ узвимостей
? High severity vuln found in handlebars@3.0.0, introduced via handlebars@3.0.0 - desc: Content Injection (XSS) - info: https://snyk.io/vuln/npm:handlebars:20151207 Remediation options > Upgrade to handlebars@4.0.0 (potentially breaking change) Patch (no patch available, we'll notify you when there is one) Set to ignore for 30 days (updates policy) Skip
Предотвращение
- Snyk может проверять пулл реквесты, которые могут сделать уязвимыми ваши приложения на Node.js, Ruby, Python, Scala и Java
- Можно использовать Snyk в CI для автоматизированых тестов
- Можно настраивать желаемый уровень безопасности для своих нужд и приоритетов
Интеграция
- Автоматический мониторинг ваших github репозиториев
- Добавление Snyk в CI процессы
- Гибкие политики, настраиваемые под вашу команду
Совместная работа
- Используйте Snyk Organisations для работы в команде
- Роли администратора и участника
- Любой в команде может искать и исправлять уязвимости
- Только нужные люди будут оповещены о новых уязвимостях
Обучение
- Подписывайтесь на базу уязвимостей, чтобы вовремя о них узнавать
- Узнавайте о способах эксплуатации уязвимостей и об их исправлении
Личные впечатления
Установка
Попробовать эту штуку можно очень быстро - просто делаем
Естественно, можно это так же интегрировать в свой CI, но всё настолько очевидно, что не хочется об этом писать.
Использование
После того, как вы установили snyk, он просто работает. Пока что я его попробовал только на Node.JS проектах, и некоторое неприятное послевкусие осталось. Как минимум, заметил, что при отсутствии или при пустой директории node_modules проверка считает, что зависимостей нет, и это значит, что в проекте всё отлично. То, что вы могли снести их руками, они могли не полностью установиться, и так далее - не учитывается. Но в целом отчёт получился неплохой - хотя по сути всё сводится к тому, что нужно держать зависимости up to date. Что весьма очевидно и без специального инструмента. Однако все мы знаем, что не всегда можно "просто взять и обновиться" на новую мажорную версию, и наличие критической уязвимости, о которой вовремя предупредил инструмент для мониторинга, может служить хорошим стимулом не откладывать это на продолжительное "завтра".
Ещё несколько огорчило качество кода самого проекта. Меня не очень смущает, что он написан на ES5 (хотя зачем тогда в проекте бабель?) - но сам код выглядит не очень красиво. Так же огорчает, что я не вижу активной работы с пулл реквестами (на примере моего, где я как раз правил описанную выше проблему с node_modules - да и вообще, кажется, было принято 2 из 23). Ну и странно, что проект, связанный с обновлением и безопасностью модулей, сам содержит кучу устаревших зависимостей, и в нём встречается большое количество различных “велосипедов”.
Опять же, меня несколько смущает количество маркетинга в проекте. Например, то, что сам процесс проверки называется проверкой на уязвимости, и бейджик показывает количество уязвимостей. Это не так. Максимум, что проверяет snyk - это уязвимые зависимости, но никак не уязвимости. Эти понятия просто нельзя подменять. И точно так же нельзя показывать, что проект, не содержащий зависимостей, не обладает уязвимостями. Это ужасная подмена понятий. Хотя возможно, что это всего лишь моя паранойя - я до сих пор считаю ужасно лицемерным зелёный замок и надпись “Secure” в браузере при использовании SSL…
Как бы то ни было, у этого проекта есть большой плюс - он работает. Он востребован и развивается. Так что я от всей души желаю ему становиться лучше, и надеюсь, что у нас когда-нибудь будет хорошее и надёжное решение для глобальной проблемы уязвимости зависимостей в наших проектах.