Как обеспечить безопасность Open Source?

За последние пять лет доля открытого исходного кода (Open Source) в разработке увеличилась с 35% до 75%. ИТ-компании во всем мире все чаще используют его, чтобы сэкономить ресурсы и сократить время вывода продуктов на рынок. У российских организаций открытый код также популярен, а в 2022 году с уходом зарубежных вендоров его востребованность выросла еще больше. Отечественные компании используют ПО на основе Open Source в качестве замены иностранного софта или интегрируют его элементы в свои разработки. При этом, они всегда учитывают то, что у открытого кода немало проблем.

По нашим оценкам, сегодня 33% российского ПО, созданного на базе открытого кода, содержит серьезные уязвимости. Чтобы снизить риски, компаниям нужно проверять сторонние компоненты, прежде чем использовать их в своих продуктах. Для этого можно внедрить программу SBOM (Software Bill of Materials, список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта). Вместе с Андреем Красовским, директором по маркетингу компании Swordfish Security, поговорили подробнее о рисках Open Source, и разобрались что такое SBOM, как разработать программу и какую пользу от этого получит компания.

Риски Open Source

Open Source — это программное обеспечение, исходный код которого распространяется в свободном доступе, разработчики могут изменять и подстраивать его под свои требования и продукты. Открытый код, как правило, не имеет жестких зависимостей от платформы, его можно масштабировать без лицензионных ограничений, если аппаратное обеспечение компании это позволяет. Такое ПО обычно выпускается как общественное достояние или на условиях свободных лицензий, например GNU General Public License или BSD License.

Использование Open Source позволяет компаниям не писать весь код самостоятельно и тем самым увеличить скорость разработки и быстрее выпустить релиз. Открытый исходный код особенно популярен у стартапов, развивающихся технологических игроков и других компаний, которые стремятся оперативно создавать ПО.

Но кроме пользы, есть и риски. Компании-разработчики зачастую не проверяют Open Source, а значит, не знают, из каких компонентов он состоит и есть ли в них уязвимости, а они могут быть. Все до сих пор помнят, как в 2021 году в популярной биб­лиоте­ке жур­налиро­вания Log4j, вхо­дящей в сос­тав Apache Logging Project, была обнаружена серьезная уязвимость, которая оставалось незамеченной на протяжении более 8 лет. Дефект допускал удаленное выполнение произвольного кода, а для совершения атаки достаточно было добавить в журналы нужную запись, в результате чего злоумышленник получал возможность полностью завладеть уязвимым приложением или сервисом. Библиотека Log4j при­сутс­тву­ет во многих кор­поратив­ных продуктах на Java, поэтому под угрозой оказалось огромное количество компаний, в числе которых Google, Apple, Twitter, Amazon Web Services, Cloudflare, Minecraft.

Популярность Open Source привлекает злоумышленников, они используют уязвимости ПО с открытым кодом для совершения атак на цепочки поставок и, таким образом, получают доступ к системам компаний-пользователей. За 2021 год количество подобных атак выросло более чем на 300%, по сравнению с 2020 годом. В рамках недавнего инцидента в общедоступном хранилище GitHub были распространены более 35 тыс. клонов библиотек. Файлы максимально замаскировали под оригиналы и заразили вредоносными элементами. Российские ИТ-компании сегодня особенно сильно соприкасаются с проблемой небезопасности Open Source. После февраля 2022 года в стране в 15–20 раз увеличилось общее количество вредоносных закладок в программных продуктах с открытым кодом, причем авторами зараженных компонентов являются сами программисты, которые создали ПО.

Что такое SBOM?

Компоненты Open Source и код сторонних производителей могут состоять из других элементов открытого исходного кода, в которых, возможно, тоже применены фрагменты Open Source и так далее. Состав таких компонентов похож на матрешку — части накладываются друг на друга, и каждая из них может иметь определенные ограничения. Чтобы обеспечить безопасность своей разработки, компании прежде всего нужно узнать, из чего именно она состоит. Для этого как раз и предназначена программа SBOM — это спецификация материалов, то есть что-то вроде этикетки программного обеспечения, на которой указан четкий перечень компонентов ПО и зависимостей (они возникают в результате объединения элементов с открытым кодом, компонентов сторонних производителей и собственного кода), техническая информация обо всех этих фрагментах и их иерархической связи. По каждой компоненте, входящей в состав ПО, SBOM минимально содержит информацию о названии, версии и лицензии. Некоторые форматы обязательным указывают еще и тип компонента (например, «фреймворк» или «библиотека»). Иногда также сюда включаются данные по уязвимостям, подлинности, дочерним зависимостям и другое.

В числе конкретных преимуществ программы SBOM можно выделить следующее:

• Выявление уязвимостей и смягчение их последствий. В рамках системы SBOM реализуется инвентаризация компонентов кода. При получении информации о критической уязвимости аналитики безопасности обращаются к артефактам SBOM, выясняют, где именно находится ошибка, влияет ли она на код, и определяют приоритетность ее устранения.
• Управление лицензиями на ПО. Программа SBOM помогает компаниям определить перечень лицензий на стороннее программное обеспечение и Open Source, которые нужно периодически проверять, поскольку они могут меняться с течением времени. Это позволяет выяснять, не нарушает ли организация условия договоров и интеллектуальные права, вовремя реагировать на лицензионные иски и аудиторские проверки, то есть защищать компанию от финансовых и репутационных рисков.
• Улучшение жизненного цикла разработки ПО (SDLC). Программа SBOM позволяет организациям повысить свою эффективность и ускорить процесс создания, развертывания и эксплуатации ПО. Например, по мере написания кода разработчики создают начальную версию SBOM, в которой перечислены зависимости, заложенные в ПО. В процессе тестирования и упаковки выявляются уязвимости и дополнительные зависимости, и SBOM обновляется по мере развертывания кода. Если ошибки появляются во время эксплуатации, программа предупреждает об этом разработчиков. После внесения исправлений в код SBOM также обновляется. Вот поэтапная схема интеграции практик SBOM в процесс разработки:

1. Дизайн. Выявление областей, которые могут включать фрагменты открытого кода;
2. Кодирование. Интеграция зависимостей Open Source в код продукта;
3. Сборка. Создание первой версии SBOM со списком всех компонентов;
4. Тестирование. Поиск уязвимостей в коде;
5. Упаковка. Подготовка уязвимостей Open Source к развертыванию, обновление SBOM;
6. Развертывание. Реализация кода в промышленной эксплуатации со ссылкой на SBOM;
7. Эксплуатация. Обновление SBOM по мере внедрения исправлений в ПО.

Как разработать программу SBOM?

При создании программы компании могут сосредоточиться на четырех ключевых действиях:

Инвестирование в возможности SBOM с упором на практику SCA (Software Composition Analysis). SCA-инструменты сканируют кодовую базу ПО, в том числе связанные артефакты (контейнеры, сборки), формируют список используемых сторонних библиотек и компонентов, анализируют их на наличие уязвимостей и соответствие лицензионным требованиям. Такие сканеры подойдут в качестве основы для создания программы SBOM. Также руководству можно разработать собственными силами или закупить у внешнего поставщика другие инструменты анализа, соответствующие процессам SDLC, имеющие возможность бесшовной интеграции в конвейер CI/CD.

Формирование кросс-функциональной команды. Поскольку SBOM затрагивает специалистов из различных подразделений, представители каждого из них должны войти в команду программы. То есть в нее нужно включить:

• Разработчиков. Они интегрируют SBOM в жизненный цикл разработки ПО для более быстрого выявления и устранения уязвимостей;
• Юристов, которые разрабатывают и внедряют стандартизированные положения контрактов, требующих использования SBOM, и соглашений об уровне обслуживания;
• Сотрудников отдела рисков. Эти люди берут на себя анализ SBOM для выявления уязвимостей и налаживания баланса между затратами на их устранение и рисками.
• Специалистов отдела контроля соответствия. Они внедряют политику и структуру управления для обеспечения использования SBOM в компании;
• Сотрудников подразделения конфиденциальности, которые создают процессы для обеспечения защиты приватной информации;
• Специалистов по закупкам. Эти сотрудники проверяют наличие SBOM у ПО, которое компания получает от поставщиков.
• Безопасников, осуществляющих поиск компонентов Open Source и проверяющих их безопасность.

Интеграция SBOM в SDLC. Если организация внедрит программу в SDLC, она получит еще больше возможностей для поиска уязвимостей и лицензионных проблем на ранних этапах создания ПО. Автоматизация процессов снизит нагрузку разработчиков и простимулирует их к дальнейшему внедрению новых методов работы.

Проектирование управления SBOM. У компании с децентрализованной или иерархической культурой могут возникнуть сложности в реализации программы. Чтобы их устранить, стоит разработать специальную структуры управления, в которой будут распределены роли и обязанности для задач, связанных с SBOM.

Заключение

Спецификация SBOM, в первую очередь, необходима компаниям, предоставляющим ПО правительственным организациям, специализирующимся, например, в оборонной или аэрокосмической промышленности. Но другим компаниям программа также будет полезна. Участившиеся в последнее время атаки на цепочки поставок, реализующиеся с помощью уязвимостей Open Source, подчеркивают необходимость проверки сторонних компонентов, библиотек и фреймворков с открытым исходным кодом. В результате таких инцидентов злоумышленники могут полностью завладеть системой компании, нарушить работу ее продуктов, заразить их вредоносными программами и распространить вирусы на заказчиков и другие организации, взаимодействующие с «инфицированным» ПО. Подобные атаки опасны непредсказуемым масштабом последствий.

Программа SBOM выступает в качестве эффективного «противоядия» от таких киберугроз. Она позволяет повысить уровень безопасности ПО, а также проверить, не нарушает ли компания лицензионные соглашения, тем самым подвергая себя репутационным и финансовым рискам. Дополнительным преимуществом SBOM также можно считать то, что программа реализуется усилиями кросс-функциональной команды, благодаря этому налаживается взаимодействие между всеми отделами, соприкасающимися с безопасностью. Кроме этого, SBOM доступна для автоматизации и внедрения в конвейер CI/CD, что делает ее еще более привлекательной с точки зрения реализации и результатов.