Безопасные зависимости
Большой процент кода, присутствующих в современных приложениях, состоит из библиотек и зависимостей, выбранных вами, разработчиком. Это распространенная практика, которая экономит время и деньги. Однако недостатком является то, что теперь вы отвечаете за этот код, даже если другие написали его, потому что вы использовали его в проекте. Если исследователь (или хуже, хакер) обнаруживает уязвимость в одной из этих сторонних библиотек, то тот же недостаток, скорее всего, будет присутствовать в приложении.
Использование компонентов с известными уязвимостями — огромная проблема нашей отрасли. Это так проблематично, что он сделал OWASP топ-10 список худших уязвимостей веб-приложений, держась на #9 в течение нескольких лет.
Отслеживание известных уязвимостей безопасности
Задача, которая стоит перед нами, — это определить, когда найдена проблема. Разумеется, поддержание наших библиотек и зависимостей в актуальном состоянии (№ 4 в нашем списке!) полезно, но рекомендуется отслеживать выявленные уязвимости, которые могут повлиять на ваше приложение.
Важно!
Если у системы есть известная уязвимость, она, скорее всего, также имеет доступ к эксплойтам, код, который люди могут использовать для атак этих систем. Если эксплойт становится общедоступным, важно немедленно обновлять все затронутые системы.
Mitre — некоммерческая организация, которая поддерживает список распространенных уязвимостей и рисков. Это общедоступный набор известных уязвимостей кибербезопасности в приложениях, библиотеках и платформах. Если вы отыскали библиотеку или компонент в базе данных CVE, в них обнаружены известные уязвимости.
Сообщество безопасности отправляет проблемы при обнаружении недостатка безопасности в продукте или компоненте. Каждой опубликованной проблеме присваивается идентификатор, также она содержит дату обнаружения уязвимости, описание уязвимости и ссылки на опубликованные обходные решения или инструкции поставщика в отношении возникшей проблемы.
Как проверить, есть ли известные уязвимости в компонентах сторонних производителей
Вы можете настроить на своем телефоне ежедневную задачу, чтобы проверять этот список, но, к счастью, существует множество инструментов, позволяющих проверить, являются ли наши зависимости уязвимыми. Вы можете запустить эти инструменты в базе кода или, еще лучше, добавить их в конвейер непрерывной интеграции и непрерывной поставки, чтобы автоматически проверять на наличие проблем в ходе процесса разработки.
- Решение OWASP Dependency Check с модулем Jenkins.
- Средство Snyk, которое является бесплатным для репозиториев GitHub с открытым исходным кодом.
- Решение Black Duck, используемое многими предприятиями.
- Retire.js — средство для определения устаревших библиотек JavaScript, которое может использоваться как подключаемый модуль для различных средств, включая Burp Suite.
Для этого можно использовать некоторые средства, специально сделанные для анализа статического кода, а также.
- Проверка кода безопасности
- Puma Scan
- PT Application Inspector
- Apache Maven Dependency Plugin
- Sonatype
- И много других
Дополнительные сведения о рисках, возникающих при использовании уязвимых компонентов, см. на странице OWASP, которая посвящена этой теме.
Итоги
Если вы используете библиотеки или другие сторонние компоненты в рамках приложения, вы также принимаете любые риски, которые они могут иметь. Лучший способ уменьшить этот риск — убедиться, что вы используете только компоненты, в которых нет связанных с ними известных уязвимостей.