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

Уровни зрелости заимствования На начальном этапе, который многие из нас проходят еще в студенческие годы, подход к Open Source зачастую прост и беззаботен – "установил и забыл", но все вроде бы работает, и работает достаточно долго. Иногда, в лучшем случае, что-то обновляется вручную. Но рано или поздно приходит понимание, что этот подход ограничен, и хочется заглянуть чуть дальше. Следующий этап наступает, когда компания осознает, что нельзя некон- тролируемо заимствовать все подряд. В этот момент появляются каталоги и кэши пакетов, устанавливаются пра- вила: только проверенные компоненты и исключительно из внутренних репо- зиториев. Продуктовый процесс начи- нает включать обязательные проверки компонентов, прежде чем они попадут в эти репозитории. Затем приходит понимание важности регулярного мониторинга уязвимостей. Настраиваются процессы, позволяющие своевременно выявлять проблемы в используемых компонентах и опера- тивно обновлять их при необходимости. На еще более зрелом уровне появляются процедуры проверки входя- щих пакетов и их обновлений. Для нача- ла они могут быть относительно легко- весными. Например, некоторые органи- зации адаптируют методику, опублико- ванную ФСТЭК России в 2022 г. для проприетарного ПО, и успешно приме- няют ее к компонентам Open Source. В дальнейшем проверки могут расши- ряться до полноценных практик разра- ботки безопасного программного обес- печения (РБПО), включая статический анализ, функциональное тестирование, фаззинг-тестирование и т.д. Другими словами, работа с Open Source – это путь от стихийного подхода к зрелой практике, где каждая новая ступень помогает компаниям минимизи- ровать риски и выстраивать более надеж- ную и устойчивую инфраструктуру. Шаги для повышения зрелости Давайте обратим внимание на основ- ные и, казалось бы, очевидные шаги, которые, тем не менее, могут быть орга- низованы далеко не везде. Во-первых, при получении кода стоит удостовериться в его подлинности: про- верить цифровую подпись, если она есть, сравнить результаты загрузки из разных источников, например, с россий- ского и нероссийского IP-адресов, чтобы убедиться, что код не изменен специ- ально для российских пользователей. Затем – проверить его через антивирус и применить хотя бы базовые YARA- правила, чтобы выявить потенциальные угрозы базового уровня. Следующий уровень – более сложный, включающий использование проверен- ных практик работы с программным обеспечением. Например, проведение статического анализа исходного кода, выполнение тестов на качество и без- опасность для каждого компонента, кото- рый планируется использовать, а также фаззинг-тестирование для выявления уязвимостей. Это тяжелый и ресурсоем- кий процесс, доступный лишь немногим организациям, располагающим соответ- ствующими ресурсами и опытом. Если взглянуть на текущую ситуацию, становится очевидным, что зрелость процессов в компаниях воспитывать нужно и важно. Особенно это заметно в тех сегментах, где программное обес- печение применяется для решения ответ- ственных задач. Где-то работа ведется более системно, и это дает положительные результаты. В качестве примера можно привести сентябрьское информационное письмо ФСТЭК России, обязывающее разра- ботчиков составить перечень заимство- ванных компонентов и предоставить информацию о них. Этот простой, на первый взгляд, шаг позволяет многим компаниям впервые получить полное представление о том, что именно исполь- зуется в их продуктах, и приступить к работе над улучшением процессов. Однако, если мы говорим о полноцен- ной реализации третьего уровня зрело- сти – с полным охватом статического анализа, фаззинга и прочих проверок, – становится ясно, что для большинства серьезных разработчиков это практиче- ски невыполнимая задача. Огромный объем заимствованного кода просто не позволяет проверить все досконально. Более того, очевидно, что подавляю- щее большинство организаций сталки- ваются с одними и теми же задачами: компоненты, используемые в разработ- ке, пересекаются у разных участников отрасли на 80% или даже больше. Это поднимает вопрос о необходимости выработки единых решений и инстру- ментов для оптимизации этих трудоем- ких процессов. Центр исследований безопасности системного программного обеспечения Три года назад началась работа над проектом, направленным на организа- цию совместных исследований заимствованных программных компо- нентов. В 2021 г. мы стартовали с ядра Linux – наиболее крупного и критически важного компонента с точки зрения его роли в обеспечении ключевых функций и высокой степени уязвимости на поверхности атаки. Постепенно проект расширялся, охватывая и другие ком- поненты, чтобы проводить их углублен- ное исследование с использованием лучших практик РБПО. На примере ядра Linux можно наглядно посмотреть, как организована эта рабо- та. Для начала мы создали зеркало всех репозиториев, связанных с ядром Linux, которые размещены на kernel.org . Для исследования безопасности и сопровож- дения были выделены две стабильные ветки ядра – 5.10 и 6.1. Выбор осу- ществлялся совместно с участниками проекта, учитывая актуальность версий и их практическое применение в про- дуктах участников. 54 • СПЕЦПРОЕКТ О безопасности заимствованных компонентов Open Source pen Source стал неотъемлемой частью современного мира. Сегодня уже нет необходимости объяснять, что это такое, – с этим явлением все давно свыклись и приняли его как данность. Однако возникает другой вопрос: как эффективно и зрело работать с Open Source? O Алексей Хорошилов, руководитель Центра исследований безопасности системного программного обеспечения, ведущий научный сотрудник ФГБУН “ИСП РАН” Фото: Антон Косицын