Согласно статистике [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 кодовых баз и сервисов.
Процесс внедрения практики разбит на три этапа.
На старте внедрения было выявлено 374 проблемы с внешними библиотеками (см. рис. 1, 2, 3), включая:
Рис. 3. Уязвимости критичного и высокого уровня
И это только результаты от первой команды из 32 и первого продукта более чем из 300!
Спустя четыре месяца все 32 команды были включены в процесс, и все продукты были проанализированы. Итоговая статистика оказалась следующей:
Рассматривая эту статистику, нужно учитывать, что в течение трех месяцев, пока мы занимались подключением новых команд, первопроходцы уже начали закрывать найденные бреши. Если бы все команды подключались одновременно, суммарное количество уязвимостей оказалось бы заметно большим.
В конечном итоге к процессу были подключены 32 команды разработки, а в постоянный анализ добавлены 325 кодовых баз и 116 артефактов сборки. В зависимости от языка программирования, системы сборки и ряда других параметров процесс анализа зависимостей проекта (составления перечня используемых библиотек, так называемый Bill Of Material) может различаться.
Были посчитаны усредненные показатели:
Несмотря на то что среднее количество слабостей кажется небольшим, есть продукты, в которых практически каждая библиотека имеет ряд критичных уязвимостей. Впрочем, есть и продукты, в которых практически не встречается уязвимостей, где разработчики с начала проекта озаботились правильным подбором компонент, хотя это большая редкость.
После того как все команды были подключены к процессу, от месяца к месяцу стало наблюдаться уменьшение количества проблем безопасности. На момент написания статьи цифры сократилось до следующих:
Тенденция к снижению продолжается и по сей день. А благодаря непрерывности процесса каждая новая сборка проходит обязательный анализ, и новые уязвимости не появляются. Такими темпами через несколько месяцев компании удастся полностью избавиться от уязвимостей критичного и высокого уровней в библиотеках и тем самым существенно повысить уровень защищенности.
Какой должна быть стратегия исправления уязвимостей? Как грамотно подойти к процессу? За что браться в первую очередь? Ответить на эти вопросы поможет интересная статистика по уязвимым компонентам. Обладая всей информацией, можно увидеть, какие библиотеки целесообразнее всего исправить в первую очередь, а какие позднее. Данные на рис. 4 показывают, что, обновив всего один компонент, мы сразу же избавляемся от более 25 уязвимостей критичного уровня! И, пройдя по этому списку до самого конца, мы сможем существенно сократить количество проблем безопасности в продукте.
Рис. 4. Компоненты с наибольшим количеством критичных уязвимостей
Если же рассмотреть еще и уязвимости высокого уровня критичности, то получим более полную картину по организации (см. рис. 5).
Рис. 5. Компоненты с наибольшим количеством уязвимостей критичного и высокого уровня
Данные этого графика помогают понять, с чего именно стоит начать обновление и на что обращать внимание в первую очередь – конечно же, на наиболее выгодные с точки зрения исправления точки.
Подобные метрики полезно строить на разных уровнях, начиная от уровня компании и заканчивая уровнем конкретной команды или продукта.
Благодаря практике анализа компонент с открытым исходным кодом получается решить сразу две важные задачи, связанные с безопасностью таких компонент:
В свою очередь, благодаря этому возможно:
Ни для кого не секрет, что в последнее время количество уязвимостей, закладок и связанных с ними атак, осуществляемых через библиотеки с открытым исходным кодом, становится все больше и больше. Грамотно выстроенный процесс анализа позволит не только вовремя на них отреагировать, но и предотвратить возможности нанесения ущерба организации и разрушения ее бизнеса.