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

В пользу необходимо- сти регулярного прове- дения анализа свиде- тельствуют такие цифры: в 2021 г. появились более 6 млн новых версий биб- лиотек Open Source, суммарное количество доступных для использования компонентов превысило отметку в 37 млн, а количество загрузок различ- ных библиотек за 2021 г. соста- вило более 2,2 трлн. С другой стороны, согласно данным исследований, более 29% популярных библиотек содер- жат уязвимости, а количество атак через них увеличилось на впечатляющие 650% по сравне- нию с предшествующим годом. На эту картину накладывается новая тенденция: в связи с событиями начала 2022 г. неко- торые активисты начали выпус- кать версии библиотек Open Source с намеренно заложен- ным в них зловредным функ- ционалом, нацеленным специ- ально на Россию и российские IP-адреса. В некоторые библио- теки были внесены относитель- но безобидные изменения, кото- рые, например, выводят в лог не связанное с функциональ- ностью сообщение. Но в отдель- ных случаях код полностью отключает заложенный в биб- лиотеке функционал, а иногда даже пытается удалить все про- граммные строки, к которым может получить доступ. Такие действия ставят под удар мно- гие проекты, в которых исполь- зуется ПО на базе Open Source. Конечно, в открытом доступе можно найти списки известных на данный момент библиотек с внедренным опасным функ- ционалом, но задача соотнесе- ния таких списков с реальными проектами остается крайне сложной, если счет используе- мых библиотек идет на тысячи. Решением этой проблемы может стать только грамотно выстроенный процесс безопас- ной разработки и, в частности, отлаженная практика анализа компонентов Open Source. Уязвимости в цифрах Рассмотрим практику внедре- ния анализа компонентов с открытым исходном кодом у достаточно крупного заказчика из сферы финтеха. У компании в едином процессе разработки, не учитывая проекты на заказ, участвуют 32 команды, в управ- лении которых находятся более 300 кодовых баз и сервисов. Процесс внедрения практики разбит на три этапа. 1. Для начала были описаны бизнес-процессы, то есть ком- муникации всех участников – бизнеса, разработки, безопас- ности и др. Описание включало в себя также и указание сроков для выработки необходимых решений – принятия рисков, подключения средств митига- ции уязвимостей, установление сроков для устранения выявлен- ных проблем и т.д. 2. После того как бизнес-про- цессы были согласованы сто- ронами, все команды разработ- ки разделили на несколько групп, поэтапно подключавших- ся к процессу анализа про- граммных продуктов. Пионера- ми стали наиболее лояльные команды: процесс их работы был приведен в соответствие с новой практикой, при этом целью ставились не только полезность, но и удобство. 3. После того как была про- ведена обкатка процесса на ограниченном количестве команд и были проанализиро- ваны первые результаты, нача- лось подключение остальных команд. 42 • ТЕХНОЛОГИИ Опасность компонент с открытым исходным кодом в цифрах на реальном проекте огласно статистике 1 , доля библиотек с открытым исходным кодом в больших проектах может достигать 30–40%, а в отдельных случаях и больше. Анализ таких компонентов на предмет безопасности должен проводиться регулярно и в соответствии с лучшими практиками. Ответ на вопрос, почему это так, получим, рассмотрев данные одного из реальных проектов. С Юрий Шабалин, ведущий архитектор информационной безопасности Swordfish Security Рис. 1. Общее количество уязвимостей Рис. 2. Только критичные уязвимости Рис. 3. Уязвимости критичного и высокого уровня 1 https://www.sonatype.com/resources/white-paper-2021-state-of-the-software-supply-chain-report-2021?hsLang=en-us