Безопасность сторонних зависимостей — проверяем при помощи snyk

    Недавно была прекрасная публикация “Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов”, на которую я переводил ответ. Автор недавно опубликовал вторую часть, но, подозреваю, что перевода не будет — там предлагается решать проблему прекрасными способами вроде перевода важных элементов ввода «в отдельный iframe» или «на особые страницы без стороннего javascript». На этом месте те, кто повёлся на первую статью, должны бы усомниться в адекватности автора — и низкий (относительно предыдущей) рейтинг новой статьи это показывает.

    UPD: перевели таки.

    Тем не менее, проблема сторонних зависимостей есть, и решать её как-то нужно. Причём стоит она в равной степени в любой экосистеме, где используются сторонние зависимости. В комментариях к прошлому посту уже запрашивали какой-нибудь вариант решения, и я хочу представить один из них — инструмент под названием snyk.

    image

    Snyk это довольно популярный инструмент, но на хабре я пока не встречал его упоминаний. Он умеет проверять зависимости для многих экосистем (Javascript, Ruby, Python, Scala and Java) по своей базе — и авторы уверяют, что их база уязвимостей большая. Можно посмотреть на неё своими глазами. Код проекта открыт, лежит на гитхабе и у него довольно много звёздочек и форков:


    Основные возможности


    Описание взято с сайта проекта, делаем скидку на marketing bullshit, повторения есть и в оригинале. Личные впечатления будут ниже.

    Поиск


    • Поиск уязвимостей в Javascript, Ruby, Python, Scala и Java
    • Проверка GitHub репозиториев
    • Проверка open source пакетов перед использованием
    • Используется собственная база уязвимостей Snyk

    image

    Мониторинг


    • Проверка зависимостей приложения
    • Интеграция в CI процессы
    • Предупреждения о новых уязвимостях в реальном времени
    • Поддержка приложений на AWS Lambda и Heroku

    image

    Исправление


    • Обновление или исправление уязвимых зависимостей
    • Автоматические пулл реквесты от 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: 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 для автоматизированых тестов
    • Можно настраивать желаемый уровень безопасности для своих нужд и приоритетов

    image

    Интеграция


    • Автоматический мониторинг ваших github репозиториев
    • Добавление Snyk в CI процессы
    • Гибкие политики, настраиваемые под вашу команду

    image

    Совместная работа


    • Используйте Snyk Organisations для работы в команде
    • Роли администратора и участника
    • Любой в команде может искать и исправлять уязвимости
    • Только нужные люди будут оповещены о новых уязвимостях

    image

    Обучение


    • Подписывайтесь на базу уязвимостей, чтобы вовремя о них узнавать
    • Узнавайте о способах эксплуатации уязвимостей и об их исправлении

    image

    Личные впечатления


    Установка


    Попробовать эту штуку можно очень быстро — просто делаем

    npm install -g snyk
    cd ~/projects/myproj/
    snyk test

    Да, как вы поняли, сам инструмент написан на Node.JS, и вам потребуется npm. Так же нужно будет авторизоваться на сайте, это можно сделать через несколько сервисов — github, google, bitbucket. Кроме этого, можно протестировать пакет и без установки, прямо на сайте — и получить внятный отчёт вроде этого. Ну и, конечно, можно получить красивый бейджик вроде такого:

    Known Vulnerabilities

    Естественно, можно это так же интегрировать в свой CI, но всё настолько очевидно, что не хочется об этом писать.

    Использование


    После того, как вы установили snyk, он просто работает. Пока что я его попробовал только на Node.JS проектах, и некоторое неприятное послевкусие осталось. Как минимум, заметил, что при отсутствии или при пустой директории node_modules проверка считает, что зависимостей нет, и это значит, что в проекте всё отлично. То, что вы могли снести их руками, они могли не полностью установиться, и так далее — не учитывается. Но в целом отчёт получился неплохой — хотя по сути всё сводится к тому, что нужно держать зависимости up to date. Что весьма очевидно и без специального инструмента. Однако все мы знаем, что не всегда можно «просто взять и обновиться» на новую мажорную версию, и наличие критической уязвимости, о которой вовремя предупредил инструмент для мониторинга, может служить хорошим стимулом не откладывать это на продолжительное «завтра».


    Ещё несколько огорчило качество кода самого проекта. Меня не очень смущает, что он написан на ES5 (хотя зачем тогда в проекте бабель?) — но сам код выглядит не очень красиво. Так же огорчает, что я не вижу активной работы с пулл реквестами (на примере моего, где я как раз правил описанную выше проблему с node_modules — да и вообще, кажется, было принято 2 из 23). Ну и странно, что проект, связанный с обновлением и безопасностью модулей, сам содержит кучу устаревших зависимостей, и в нём встречается большое количество различных «велосипедов».

    Опять же, меня несколько смущает количество маркетинга в проекте. Например, то, что сам процесс проверки называется проверкой на уязвимости, и бейджик показывает количество уязвимостей. Это не так. Максимум, что проверяет snyk — это уязвимые зависимости, но никак не уязвимости. Эти понятия просто нельзя подменять. И точно так же нельзя показывать, что проект, не содержащий зависимостей, не обладает уязвимостями. Это ужасная подмена понятий. Хотя возможно, что это всего лишь моя паранойя — я до сих пор считаю ужасно лицемерным зелёный замок и надпись «Secure» в браузере при использовании SSL…

    Как бы то ни было, у этого проекта есть большой плюс — он работает. Он востребован и развивается. Так что я от всей души желаю ему становиться лучше, и надеюсь, что у нас когда-нибудь будет хорошее и надёжное решение для глобальной проблемы уязвимости зависимостей в наших проектах.

    Only registered users can participate in poll. Log in, please.

    А как вы проверяете свои зависимости?

    Support the author
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 6

      0
      Я не очень понял, почему 7.7к лайков статьи — это «низкий рейтинг» и почему вариант с iframe без стороннего JS, предложенный автором оригинальной статьи, это плохое решение.
        0

        У первой статьи было 160к. Против 7к второй. Понятно, что вторая была опубликована позже — но тем не менее. Вторая должна была бы на волне хайпа первой выехать как минимум. И во всякие хорошие рассылки она не вошла, в отличие от первой.


        По поводу iframe — подойдите и предложите такой вариант какому-нибудь знакомому фронтендеру. Только отойдите немного, чтобы слюной не забрызгало.

          0
          А кроме риска быть забрызганным слюной, есть какие-то радикальные недостатки у предложенного способа?
            0

            Мне казалось это интуитивно понятным, но если нет — описал здесь.

        +1
        для проекта на Ruby мы запускаем bundler-audit на CI
        github.com/rubysec/bundler-audit
          0
          Спасибо. Прочитал всю эту историю оригинальный переводов и ваших, и в итоге дошел до этой где рассказывается синк. Терь буду знать что это и с чем его едят )

          Only users with full accounts can post comments. Log in, please.