Юрий Шабалин, 23/11/22
Согласно статистике [1], доля библиотек с открытым исходным кодом в больших проектах может достигать 30–40%, а в отдельных случаях и больше. Анализ таких компонентов на предмет безопасности должен проводиться регулярно и в соответствии с лучшими практиками. Ответ на вопрос, почему это так, получим, рассмотрев данные одного из реальных проектов.
Автор: Юрий Шабалин, ведущий архитектор информационной безопасности Swordfish Security
В пользу необходимости регулярного проведения анализа свидетельствуют такие цифры: в 2021 г. появились более 6 млн новых версий библиотек Open Source, суммарное количество доступных для использования компонентов превысило отметку в 37 млн, а количество загрузок различных библиотек за 2021 г. составило более 2,2 трлн. С другой стороны, согласно данным исследований, более 29% популярных библиотек содержат уязвимости, а количество атак через них увеличилось на впечатляющие 650% по сравнению с предшествующим годом.
На эту картину накладывается новая тенденция: в связи с событиями начала 2022 г. некоторые активисты начали выпускать версии библиотек Open Source с намеренно заложенным в них зловредным функционалом, нацеленным специально на Россию и российские IP-адреса. В некоторые библиотеки были внесены относительно безобидные изменения, которые, например, выводят в лог не связанное с функциональностью сообщение. Но в отдельных случаях код полностью отключает заложенный в библиотеке функционал, а иногда даже пытается удалить все программные строки, к которым может получить доступ. Такие действия ставят под удар многие проекты, в которых используется ПО на базе Open Source.
Конечно, в открытом доступе можно найти списки известных на данный момент библиотек с внедренным опасным функционалом, но задача соотнесения таких списков с реальными проектами остается крайне сложной, если счет используемых библиотек идет на тысячи.
Решением этой проблемы может стать только грамотно выстроенный процесс безопасной разработки и, в частности, отлаженная практика анализа компонентов Open Source.
Уязвимости в цифрах
Рассмотрим практику внедрения анализа компонентов с открытым исходном кодом у достаточно крупного заказчика из сферы финтеха. У компании в едином процессе разработки, не учитывая проекты на заказ, участвуют 32 команды, в управлении которых находятся более 300 кодовых баз и сервисов.
Процесс внедрения практики разбит на три этапа.
- Для начала были описаны бизнес-процессы, то есть коммуникации всех участников – бизнеса, разработки, безопасности и др. Описание включало в себя также и указание сроков для выработки необходимых решений – принятия рисков, подключения средств митигации уязвимостей, установление сроков для устранения выявленных проблем и т.д.
- После того как бизнес-процессы были согласованы сторонами, все команды разработки разделили на несколько групп, поэтапно подключавшихся к процессу анализа программных продуктов. Пионерами стали наиболее лояльные команды: процесс их работы был приведен в соответствие с новой практикой, при этом целью ставились не только полезность, но и удобство.
- 3. После того как была проведена обкатка процесса на ограниченном количестве команд и были проанализированы первые результаты, началось подключение остальных команд.
На старте внедрения было выявлено 374 проблемы с внешними библиотеками (см. рис. 1, 2, 3), включая:
- 371 проблему с безопасностью;
- 3 проблемы с лицензиями;
- 56 (!) уязвимостей с критичным уровнем опасности (от 9 до 10 по шкале CVSS, то есть эксплуатация которых может привести к самым неприятным последствиям);
- 46 уязвимостей с высоким уровнем критичности (от 8 до 9 по шкале CVSS).
Рис. 1. Общее количество уязвимостей
Рис. 2. Только критичные уязвимости
Рис. 3. Уязвимости критичного и высокого уровня
И это только результаты от первой команды из 32 и первого продукта более чем из 300!
Спустя четыре месяца все 32 команды были включены в процесс, и все продукты были проанализированы. Итоговая статистика оказалась следующей:
- найдено 2504 уязвимости в используемых компонентах, включая 598 уязвимостей критичного уровня и 416 уязвимостей высокого уровня критичности;
- выявлено 197 компонентов с лицензиями, запрещающими коммерческое использование.
Рассматривая эту статистику, нужно учитывать, что в течение трех месяцев, пока мы занимались подключением новых команд, первопроходцы уже начали закрывать найденные бреши. Если бы все команды подключались одновременно, суммарное количество уязвимостей оказалось бы заметно большим.
Анализ результатов внедрения
В конечном итоге к процессу были подключены 32 команды разработки, а в постоянный анализ добавлены 325 кодовых баз и 116 артефактов сборки. В зависимости от языка программирования, системы сборки и ряда других параметров процесс анализа зависимостей проекта (составления перечня используемых библиотек, так называемый Bill Of Material) может различаться.
Были посчитаны усредненные показатели:
- 79 уязвимостей в среднем на команду;
- 7 уязвимостей на один репозиторий;
- 22 уязвимости на каждый артефакт сборки.
Несмотря на то что среднее количество слабостей кажется небольшим, есть продукты, в которых практически каждая библиотека имеет ряд критичных уязвимостей. Впрочем, есть и продукты, в которых практически не встречается уязвимостей, где разработчики с начала проекта озаботились правильным подбором компонент, хотя это большая редкость.
После того как все команды были подключены к процессу, от месяца к месяцу стало наблюдаться уменьшение количества проблем безопасности. На момент написания статьи цифры сократилось до следующих:
- 1610 уязвимостей, включая 490 уязвимостей критичного уровня и 172 уязвимости высокого уровня;
- 156 компонент с лицензиями, запрещающими использование в коммерческих продуктах.
Тенденция к снижению продолжается и по сей день. А благодаря непрерывности процесса каждая новая сборка проходит обязательный анализ, и новые уязвимости не появляются. Такими темпами через несколько месяцев компании удастся полностью избавиться от уязвимостей критичного и высокого уровней в библиотеках и тем самым существенно повысить уровень защищенности.
Уязвимости по компонентам
Какой должна быть стратегия исправления уязвимостей? Как грамотно подойти к процессу? За что браться в первую очередь? Ответить на эти вопросы поможет интересная статистика по уязвимым компонентам. Обладая всей информацией, можно увидеть, какие библиотеки целесообразнее всего исправить в первую очередь, а какие позднее. Данные на рис. 4 показывают, что, обновив всего один компонент, мы сразу же избавляемся от более 25 уязвимостей критичного уровня! И, пройдя по этому списку до самого конца, мы сможем существенно сократить количество проблем безопасности в продукте.
Рис. 4. Компоненты с наибольшим количеством критичных уязвимостей
Если же рассмотреть еще и уязвимости высокого уровня критичности, то получим более полную картину по организации (см. рис. 5).
Рис. 5. Компоненты с наибольшим количеством уязвимостей критичного и высокого уровня
Данные этого графика помогают понять, с чего именно стоит начать обновление и на что обращать внимание в первую очередь – конечно же, на наиболее выгодные с точки зрения исправления точки.
Подобные метрики полезно строить на разных уровнях, начиная от уровня компании и заканчивая уровнем конкретной команды или продукта.
Выводы
Благодаря практике анализа компонент с открытым исходным кодом получается решить сразу две важные задачи, связанные с безопасностью таких компонент:
- оценить количество используемых уязвимых библиотек;
- понять, насколько продукт лицензионно чист.
В свою очередь, благодаря этому возможно:
- принять компенсирующие меры на время обновления, поскольку процесс этот небыстрый, а закрывать критичные бреши нужно как можно скорее;
- произвести планомерное обновление библиотек до неуязвимых версий и избавиться от уязвимостей хотя бы высокого и критичного уровней;
- начать корректно работать с лицензиями внутри продукта.
Ни для кого не секрет, что в последнее время количество уязвимостей, закладок и связанных с ними атак, осуществляемых через библиотеки с открытым исходным кодом, становится все больше и больше. Грамотно выстроенный процесс анализа позволит не только вовремя на них отреагировать, но и предотвратить возможности нанесения ущерба организации и разрушения ее бизнеса.
