То, как мы потребляем программное обеспечение с открытым исходным кодом (OSS) резко изменилось за последние десять-два десятилетия. В начале 2000-х годов мы в основном использовали крупные проекты OSS от небольшого числа провайдеров, таких как Apache, MyS’L, Linux и OpenSSL. Эти проекты были реализованы в известных магазинах программного обеспечения, которые поддерживали хорошую практику разработки и качества. Это был не наш код, но он чувствовал себя надежным, и можно было с уверенностью предположить, что он не имеет больше ошибок, чем наш собственный код.
Перемотка вперед к сегодняшнему дню и OSS превратилась в краудсорсинговых рынках. npm узла несет более 210 000 пакетов из более чем 60 000 участников; RubyGems содержит более 110 000 драгоценных камней, а центральный репозиторий Maven индексирует почти 130 000 артефактов. Пакеты могут быть написаны кем угодно, и варьируются от небольших утилит, которые преобразуют миллисекунды в полномасштабные веб-серверы. Пакеты часто используют другие пакеты в свою очередь, заканчивая типичным приложением, вмещающих сотни, если не тысячи пакетов OSS.
Дальнейшее чтение на SmashingMag:
- Я внес свой вклад в редактор с открытым исходным кодом, и поэтому можете ли вы
- Краткое руководство по открытым исходным кодом и аналогичным лицензиям
- Итак, вы решили с открытым исходным кодом проекта на работе. Что теперь?
- Контрольный список производительности Front-End 2017
Это богатство с открытым исходным кодом функциональность является удивительным, но она также несет в себе риск. Вы работаете код незнакомца внутри ваших приложений. Вы знаете, какие пакеты вы работаете? Знаете ли вы, понимают ли их авторы безопасность или заботятся о ней? Знаете ли вы, если они имеют уязвимости?
Веб-сообщество нуждается в нескольких новых инструментов и практики, чтобы помочь нам отслеживать и изучать эти компоненты — и Сник берет на себя безопасность часть истории.
Риски безопасности и известные уязвимости
Запуск ненадежного кода внутри системы представляет собой широкий риск для безопасности. Решение этой проблемы не просто, но хорошее место для начала — это устранение известных уязвимостей. Это общераскрытые ошибки безопасности, обычно найденные и зарегистрированные пользователями, или намеренно найденные и сообщаемые исследователями безопасности. Будучи общественности делает эти вопросы самыми простыми для злоумышленников, чтобы найти и использовать,и так очень важно для решения.
Прямо сейчас, примерно 14% из верхней npm пакеты несут известные уязвимости. Статистика гораздо хуже для полных приложений: более 80% пользователей Snyk находят уязвимости при тестировании своих приложений. Некоторые из этих вопросов носят незначительный характер, а некоторые очень серьезные. Вы можете увидеть живую демонстрацию хакера, эксплуатирующего одну такую уязвимость в этом видео (примерно четыре минуты).
К счастью, есть новый бесплатный инструмент, который может помочь вам найти и исправить уязвимости в Node.js — Snyk. Эта статья проведет вас через, как вы можете использовать Snyk, чтобы сделать ваши приложения более безопасными.
Начало работы
Во-первых, вам понадобится проект для тестирования. Если у вас нет одного удобного, вы можете использовать демо-приложение, которое мы рассмотрим в этой статье, snyk-demo-app. Просто запустите эти строки, чтобы клонировать его и установить его зависимостей:
git clone https://github.com/Snyk/snyk-demo-app.git
cd snyk-demo-app
npm install
Теперь, когда у вас есть проект для тестирования, вам нужно установить Snyk от npm, изменить каталог в папку вашего проекта и запустить ВолшебникSnyk . Мы установим Snyk как глобальный инструмент для теперь; позже мы коснемся использования его в качестве локальной зависимости от ваших автоматизированных тестов. Выполнить следующее в папке проекта:
npm install –g snyk
snyk wizard
Как следует из названия, мастер является управляемым пошаговым руководством. Он ходит вас через поиск и исправление проблем, найденных через обновления и патчи, и создает политику Snyk (файл .snyk) с вашими решениями. Мастер использует четыре другие команды Snyk protect monitor — auth , test и — которые мы объясним, как мы продвигаемся.
Проверки подлинности
Если это первый раз, когда вы используете Snyk, мастер сначала попросит вас зарегистрироваться с помощью учетной записи GitHub. Обратите внимание, что Snyk не требует доступа к вашим репозиториям. Он запрашивает доступ только к вашей электронной почте, используя GitHub в качестве системы аутентификации.
После проверки подлинности мастер получит ключ API для локального хранения и приступить к тестированию. Тот же процесс аутентификации может snyk auth <api-key> быть выполнен путем запуска snyk auth или запуска (особенно полезно при интеграции Snyk в вашу систему сборки/непрерывной интеграции (CI).
Тестирования
Следующим шагом является поиск уязвимостей. Мастер будет пересекать локальный проект и собирать пакеты, которые он использует (обратите внимание, это означает, что вы должны запустить его только после npm install запуска). Затем он публикует этот список в службе Snyk, где они сопоставляются с базой уязвимости сприги. Этот тест также может snyk test быть выполнен путем запуска, что полезно при интеграции Snyk в ваш CI (подробнее об этом позже).
Как только уязвимости будут определены, мастер пройдет через них и проведет вас через необходимые шаги по исправлению. Он запоминает ответы, которые вы даете, и когда вопросы заканчиваются, он вносит изменения, о которые вы просили.
Давайте рассмотрим выводы на snyk демо-приложение.
Вы можете увидеть, как мастер обнаружил 11 уязвимостей в 314 используемых зависимостях. Первый из них является высокой серьезностью вопрос в прямой зависимости называется басмастер. Там только так много деталей мы можем поделиться в терминале, но вы можете использовать ссылку на информацию, чтобы получить больше информации о самой уязвимости.
Во многих случаях выявленные уязвимости фиксируются вскоре после их обнаружения, и все, что вам нужно сделать, это перейти на соответствующую версию. Когда это возможно, обновление является самым чистым и лучшим способом устранения такой ошибки безопасности. В случае bassmaster, все, что нам нужно применить это «исправить» обновление, что делает решение о обновлении не головной умысел.
Далее мастер сообщает о трех уязвимостях в зависимости happy ‘10.5.0. Обычно это происходит, когда вы находитесь в нескольких версиях последней версии, и в то же время было найдено и исправлено несколько уязвимостей. В этом случае, нажав на информационную ссылку, будут показаны три уязвимости, зафиксированные в версии 11.0.0, 11.1.3 и 11.1.4 счастливых.
Предложение мастера по умолчанию состоит в том, чтобы перейти на последнюю версию, решая все три проблемы, но вы также можете выбрать для рассмотрения и действия по каждой уязвимости отдельно.
Далее мы видим, что прямая зависимость, falcor-маршрутизатор-demo’1.0.3, ввела три уязвимости. Уязвимости в этом случае не в falcor-router-demo коде, а скорее в зависимостях, которые он тянет. Это очень распространенный сценарий, так как большинство пакетов, используемых вашим приложением, на самом деле вытягиваются косвенно.
Info link, которая приводит вас к странице тестирования на прямой зависимости, далее показывает две различные уязвимости в qs и один в semver .
К сожалению, вы не можете обновить глубокую зависимость, как по техническим причинам, так и из-за страха взлома функциональности. Таким образом, ваш шаг восстановления заключается в обновлении прямой зависимости, вызывая обновление глубокой зависимости. В этом случае обновление falcor-router-demo до версии 1.0.5 (обновление ‘fix’) вызовет qs и semver обновления, необходимые для устранения уязвимостей.
Патч и защита
Следующая проблема, о чем мастер сообщает в нашем демо-приложении, отличается.
Сник обнаружил уязвимость в руле, втянутом через прямую snyk-demo-child зависимость. Хотя уязвимость была исправлена в Handlebars 4.0.0, snyk-demo-child не модернизировала до той версии — поэтому вы не можете модернизировать уязвимость прочь.
Этот сценарий особенно распространен в недавно раскрытых уязвимостях, так как цепочке зависимостей требуется некоторое время, чтобы наверстать упущенное. Кроме того, иногда доступно обновление, но это крупное обновление с изменениями, и вы не можете справиться с этим прямо сейчас. В тех случаях, когда у вас нет опции обновления, вместо того, чтобы просто оставаться уязвимым, Сник предлагает вам исправить уязвимость.
Патчинг означает изменение локально установленных пакетных файлов для устранения уязвимости. Патчи создаются и поддерживаются Snyk, и обычно начинаются с изменений кода, внесенных владельцем пакета, чтобы устранить проблему, удалив любые косметические или не связанные с этим изменения. Затем группа безопасности Snyk проверяет их, загоняет в старые версии и тестирует, что они не нарушили функциональность. Патчи являются частью базы данных уязвимостисника с открытым исходным кодом, и вот пример патча для ms уязвимости ReDoS.
После того, как мы исправления Handlebars, мастер подсказывает о двух экземплярах uglify-js уязвимостей, предлагая вам патч их всех.
По мере расширения проектов часто можно найти один и тот же пакет, повторяемый в дереве зависимостей, и это не так уж редко, когда один пакет имеет несколько уязвимостей. Когда мастер видит несколько экземпляров уязвимого пакета, он предлагает ярлык, чтобы исправить их все, чтобы сэкономить время. Вы все еще можете выбрать для рассмотрения и исправления каждой проблемы отдельно, и если экземпляр был достаточно обновлен ранее выбранных обновлений, он не будет затронут.
Обратите внимание, что мастер патчи только локально установленных файлов. Это означает, что вам нужно повторно применять этот патч каждый раз, когда зависимости переустановлены, что вы можете сделать, запустив. snyk protect Мастер хранит патчи, которые вы выбрали в политике Snyk snyk protect (.snyk),и будет применять эти патчи, и эти патчи в одиночку — он никогда не применяет патч в одностороннем порядке. Каждый раз, когда вы переустанавливаете свои зависимости, следует запускать, snyk protect чтобы закрыть уязвимости. Мастер может сделать это за вас, как мы увидим позже.
Игнорировать
Следующая проблема, показанная мастером, не так легко решена.
Уязвимость обнаруживается в глубокой validator зависимости, которая не имеет ни обновления, ни патча. Есть много комбинаций уязвимости и модуля версий, и не все из них могут быть исправлены. Команда безопасности Snyk постоянно добавляет больше заплат к открытым исходным кодом VulnDB и будет приветствовать запросы на вытягивание,но некоторые проблемы до сих пор не имеют патча.
Там не легко исправить эти проблемы. Вам нужно будет лучше понять риск, который эта проблема представляет для вашей системы, и сопоставить этот риск с усилиями по устранению проблемы, например, путем удаления зависимости. В то время как вы считаете, ваши действия, вы можете «отложить» вопрос со Сник, сказав ему игнорировать вопрос в течение 30 дней. Сник подскажет вам дать повод для игнорирования, чтобы помочь вам вспомнить, почему вы сделали это позже.
Если вы оцените уязвимость и решите, что это не проблема (например, из-за того, что компонент на самом деле не развернут в производстве), можно вручную отсеить файл Snyk(.snyk)для использования далекого срока годности для данного экземпляра. Обратите внимание, что Сник не тестирует devDependencies по умолчанию, избегая большинства таких красных селедок.
В дополнение к любым действиям, которые вы предпринимаете, Snyk сообщит вам, когда патч или обновление станут доступны для этого сценария, так что вы можете применить лучшее решение.
Применение вашего выбора
Вот и все, мы решили все вопросы — ура!
Прежде чем мастер применяет запрошенные изменения, он предлагает добавить два шага к рабочему процессу Package.json, чтобы сохранить уязвимость бесплатной.
Во-первых, мастер предлагает добавить тест Сника в ваши регулярные npm test действия. Если был добавлен уязвимый пакет, тест не сдастся, сохраняя безопасность. Мастер также добавит snyk как devDependency, так как он вам понадобится в вашей тестовой или среде CI. Вы можете использовать ту же логику для выполнения этого теста в любой любимой платформе CI/test.
Если вы решили исправить проблему, мастер также предложит snyk protect добавить к postinstall шагу. postinstallКрючок работает каждый раз, когда вы устанавливаете зависимости этого пакета, обеспечивая, чтобы эти зависимости всегда должным образом исправлены. Обратите внимание, что такой крючок требует snyk добавления в качестве зависимости (не devDependency).
Со всеми ответами на все вопросы мастер приступает к изменению. Он изменяет файл Package.json с любыми запросами обновления или крючки, npm update работает, чтобы применить изменения, и хранит политику Snyk в файле .snyk (вы можете довольно-печать его, запустив). snyk policy Убедитесь в том, чтобы добавить этот файл .snyk к исходному элементу управления для патча и игнорировать инструкции применять.
Наконец, мастер делает снимок ваших зависимостей, чтобы он мог отслеживать их с течением времени.
Монитор
Теперь, когда вы свободны от известных уязвимостей, есть два способа, которые могут измениться. Во-первых, это добавление уязвимых пакетов в snyk test ваш код, который мы обрабатываем, добавляя к вашей системе тестирования/CI. Во-вторых, через вновь раскрытые уязвимости. Это новые раскрытия уязвимостей в старом коде — код, который вы работаете в производстве!
Это решается последним шагом Сника — монитором. Снимок, который делает мастер, сохраняется на серверах Snyk, вспомнив зависимости, используемые в этом приложении. Если новая выявленная уязвимость влияет на ваше приложение, вы получите электронное письмо с предупреждением о нем. Затем можно снова запустить мастерский, чтобы обновить или исправления по мере необходимости, и развернуть безопасный код.
Ниже приведен пример электронной почты, который вы можете получить. Как мы уже упоминали выше, вы также будете уведомлены о новых вариантах восстановления; например, путь патча или обновления, который ранее не существовал.
Чтобы держать понимание приложения в оквеченности Snyk, можно запустить snyk monitor в конце процесса развертывания. Это позволит сделать свежий снимок вашего приложения, как это делает мастер, и обеспечит, чтобы оповещения Сника применимы к вашему последнему коду.
Сводка
Пакеты с открытым исходным кодом являются удивительными, но они несут с собой значительный риск для безопасности. Хорошим способом начать признавать и обрабатывать этот риск является устранение известных уязвимостей в зависимостях, так как именно те злоумышленники, скорее всего, будут использовать.
Snyk упрощает поиск, исправление и мониторинг известных уязвимостей в Node.js. Я рекомендую вам:
- Запустите
snyk wizardприложение и исправьте текущие проблемы. Обновление, когда это возможно, патч, когда вы не можете обновить, и вручную оценить остальные вопросы. - Добавьте
snyk testк тестам и CI, чтобы избежать добавления уязвимых пакетов. - Если вы исправили проблемы, запускайте
snyk protectвсякий раз, когда переустановите свои зависимости; например, добавляя их в свойpostinstallскрипт. - Добавьте сьюдми
snyk monitorв процесс развертывания, чтобы убедиться, что вы отслеживаете уязвимости в самых современных зависимостях. - Будьте бдительны для уведомлений по электронной почте от Snyk о новых уязвимостях, и действовать быстро, когда они приходят.
Если у вас есть публичный проект GitHub, добавьте значок, чтобы показать, что вы свободны от уязвимости, и напомните пользователям о вопросах безопасности.
Если вы не используете Node.js, зарегистрируйтесь, чтобы получить уведомление, когда мы добавляем новые языки, или дайте нам знать, какие платформы вы хотели бы, чтобы мы поддерживали дальше!
Источник: smashingmagazine.com
