Журнал "Information Security/ Информационная безопасность" #4, 2022

В связи с событиями начала 2022 г. некоторые активисты начали выпускать версии библиотек Open Source с намеренно зало- женным в них зловредным функционалом, нацеленным специально на Россию. На старте внедрения было выявлено 374 проблемы с внеш- ними библиотеками (см. рис. 1, 2, 3), включая: l 371 проблему с безопас- ностью; l 3 проблемы с лицензиями; l 56 (!) уязвимостей с критич- ным уровнем опасности (от 9 до 10 по шкале CVSS, то есть экс- плуатация которых может при- вести к самым неприятным последствиям); l 46 уязвимостей с высоким уровнем критичности (от 8 до 9 по шкале CVSS). И это только результаты от первой команды из 32 и первого продукта более чем из 300! Спустя четыре месяца все 32 команды были включены в про- цесс, и все продукты были про- анализированы. Итоговая стати- стика оказалась следующей: l найдено 2504 уязвимости в используемых компонентах, включая 598 уязвимостей кри- тичного уровня и 416 уязвимо- стей высокого уровня критич- ности; l выявлено 197 компонентов с лицензиями, запрещающими коммерческое использование. Рассматривая эту статистику, нужно учитывать, что в течение трех месяцев, пока мы занима- лись подключением новых команд, первопроходцы уже начали закрывать найденные бреши. Если бы все команды подключались одновременно, суммарное количество уязви- мостей оказалось бы заметно большим. Анализ результатов внедрения В конечном итоге к процессу были подключены 32 команды разработки, а в постоянный ана- лиз добавлены 325 кодовых баз и 116 артефактов сборки. В зависимости от языка про- граммирования, системы сбор- ки и ряда других параметров процесс анализа зависимостей проекта (составления перечня используемых библиотек, так называемый Bill Of Material) может различаться. Были посчитаны усредненные показатели: l 79 уязвимостей в среднем на команду; l 7 уязвимостей на один репо- зиторий; l 22 уязвимости на каждый артефакт сборки. Несмотря на то что среднее количество слабостей кажется небольшим, есть продукты, в которых практически каждая библиотека имеет ряд критич- ных уязвимостей. Впрочем, есть и продукты, в которых практи- чески не встречается уязвимо- стей, где разработчики с начала проекта озаботились правиль- ным подбором компонент, хотя это большая редкость. После того как все команды были подключены к процессу, от месяца к месяцу стало наблю- даться уменьшение количества проблем безопасности. На момент написания статьи цифры сократилось до следующих: l 1610 уязвимостей, включая 490 уязвимостей критичного уровня и 172 уязвимости высо- кого уровня; l 156 компонент с лицензиями, запрещающими использование в коммерческих продуктах. Тенденция к снижению про- должается и по сей день. А бла- годаря непрерывности процесса каждая новая сборка проходит обязательный анализ, и новые уязвимости не появляются. Такими темпами через несколь- ко месяцев компании удастся полностью избавиться от уязви- мостей критичного и высокого уровней в библиотеках и тем самым существенно повысить уровень защищенности. Уязвимости по компонентам Какой должна быть стратегия исправления уязвимостей? Как грамотно подойти к процессу? За что браться в первую оче- редь? Ответить на эти вопросы поможет интересная статистика по уязвимым компонентам. Обладая всей информацией, можно увидеть, какие библиоте- ки целесообразнее всего испра- вить в первую очередь, а какие позднее. Данные на рис. 4 пока- зывают, что, обновив всего один компонент, мы сразу же избав- ляемся от более 25 уязвимостей критичного уровня! И, пройдя по этому списку до самого конца, мы сможем существенно сокра- тить количество проблем без- опасности в продукте. Если же рассмотреть еще и уязвимости высокого уровня критичности, то получим более полную картину по организации (см. рис. 5). Данные этого графика помо- гают понять, с чего именно стоит начать обновление и на что обращать внимание в пер- вую очередь – конечно же, на наиболее выгодные с точки зре- ния исправления точки. Подобные метрики полезно строить на разных уровнях, начиная от уровня компании и заканчивая уровнем конкрет- ной команды или продукта. Выводы Благодаря практике анализа компонент с открытым исход- ным кодом получается решить сразу две важные задачи, свя- занные с безопасностью таких компонент: l оценить количество исполь- зуемых уязвимых библиотек; l понять, насколько продукт лицензионно чист. В свою очередь, благодаря этому возможно: l принять компенсирующие меры на время обновления, поскольку процесс этот небыст- рый, а закрывать критичные бреши нужно как можно скорее; l произвести планомерное обновление библиотек до неуязвимых версий и избавить- ся от уязвимостей хотя бы высо- кого и критичного уровней; l начать корректно работать с лицензиями внутри продукта. Ни для кого не секрет, что в последнее время количество уязвимостей, закладок и свя- занных с ними атак, осуществ- ляемых через библиотеки с открытым исходным кодом, становится все больше и боль- ше. Грамотно выстроенный процесс анализа позволит не только вовремя на них отреа- гировать, но и предотвратить возможности нанесения ущер- ба организации и разрушения ее бизнеса. l • 43 Безопасная разраБотка www.itsec.ru Рис. 4. Компоненты с наибольшим количеством критичных уязвимостей Рис. 5. Компоненты с наибольшим количеством уязвимостей критичного и высокого уровня Ваше мнение и вопросы присылайте по адресу is@groteck.ru