Насколько безопасны продукты на базе Open Source

Открытый код уже успел стать неотъемлемой частью разработки программных продуктов. В некоторых случаях его содержание превалирует над «авторским» кодом. Вместе с ростом популярности использования таких элементов в бизнес-среде, растут и риски, связанные с информационной безопасностью.

Эти риски особенно обострились в этом году, в связи с геополитическим кризисом. Многие авторы open-source компонентов решили использовать свои продукты в качестве инструмента высказывания своей позиции. В самом «безобидном» случае это были информационные баннеры с политическим текстом, в худшем – внедрение ВПО или произвольное удаление персональных данных.

Такие события, с точки зрения бизнеса, недопустимы и чреваты как финансовыми, так и правовыми издержками. В этой статье будут рассмотрены вопросы доверия к open-source и безопасности использования решений с открытым кодом.

Особенности использования Open Source

Главное преимущество открытого кода с позиции бизнеса – это возможность использовать готовые элементы кода для решения типовых задач. Это существенно снижает временные и финансовые затраты на создание нового программного продукта или доработку функций уже существующего.

Однако, это не значит что Open Source – это просто и бесплатно. Процесс кастомизации и адаптации кода под конкретные задачи и особенности инфраструктуры компании может быть довольно затратным.

Григорий Сизоненко
Генеральный директор компании ИВК

Open source уже давно является неотъемлемой частью многих ИТ-решений, представленных как на отечественном, так и международных рынках. В результате, при использовании однотипного кода каждому вендору приходится самостоятельно разрабатывать и применять комплекс мер по разработке безопасного программного обеспечения. Рациональнее, если ИТ-сообщество будет сообща решать данную задачу, если будет делиться опытом и практиками, работая на результат коллективно. Это реально позволит повысить уровень защищенности своей конечной продукции. Форматы такого взаимодействия ИТ-сообщества в нашей стране сейчас вырабатываются. Для этого вокруг ИСП РАН сформированы сообщества по безопасной разработке, создан Центр компетенции по ядру Linux. В этой работе активное участие принимают представители регулятора – ФСТЭК России, что позволяет сообществу принимать активное участие еще и в вопросах совершенствования руководящих требований в области разработки безопасного программного обеспечения с последующей их практической апробацией, в том числе в рамках соответствующих сертификационных испытаний.

Если говорить о безопасности решений, выполненных на открытом коде, то это достаточно дискуссионный вопрос. С одной стороны, высокий спрос на конкретное решение и большое количество положительных отзывов на платформе GitHub косвенно говорят и о высоком уровне безопасности продукта.

С другой стороны, никакого единого регламента к безопасности open-source, который соблюдался бы всеми интерессантами, в данный момент не существует. В актуальных условиях за безопасность продукта, фактически, отвечают все участники, от авторов до контрибьюторов и конечных пользователей. Из-за этого нередки ситуации, когда за безопасность открытого кода не отвечает вообще никто.

Диана Ахметова
Системный инженер группы безопасности ИТ-инфраструктуры ГК ICL

Open source – это программное обеспечение с открытым исходным кодом. Считается, что такой код обладает повышенной безопасностью. Почему? Во-первых, код уже был просмотрен, скачан и протестирован другими пользователями. Это повышает вероятность того, что все потенциальные уязвимости были найдены. Во-вторых, на кону стоит репутация разработчика, который выкладывает свою работу в открытый доступ. А это уже является стимулом к разработке удобного и безопасного кода. В-третьих, у таких программ есть цифровой сертификат от создателя, и они проходят проверку на целостность при запуске. Это дает возможность убедиться в том, что запускаемая программа и исходный код выполняют одну функцию.

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

С позиции ИБ, наиболее оптимальна политика «нулевого доверия» к компонентам Open Source. Она подразумевает проведение аудита безопасности кода еще до того, как он будет развернут в инфраструктуре компании.

Зачем заниматься безопасностью открытого кода

Если обратиться к проекту Стратегии развития ПО с открытым исходным кодом в России, то там указаны две группы рисков, наиболее актуальные для информационной безопасности:

1. Низкокачественное ОПО. Большинство площадок предлагают системы репутации для программных продуктов, но не создают порога вхождения для авторов. В результате, продукт может содержать в себе уязвимости просто потому что компетенции автора недостаточны для их выявления и устранения.

2. Умышленно зараженное ОПО. Разнообразные закладки, бэкдоры и вредоносные элементы могут быть помещены автором сознательно, для получения нелегитимного доступа к скомпрометированным сетям.

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

Анастасия Худоярова
Ведущий специалист по безопасной разработке Awillix

Вообще очень много споров в принципе по поводу использования open source и по поводу разграничения ответственности, но на мой взгляд, основная ответственность создателей open source компонентов состоит именно в разработке функциональности инструмента, а вот вопросы безопасности и дальнейшей поддержки не обязывают создателей инструментов и продуктов отвечать за них, поэтому пользователи систем/инструментов/фреймворков должны проверять то, что они используют. Те, кто использует эти компоненты, простые разработчики, тим лиды и тех лиды и тд должны понимать, что работать с OSS нужно грамотно, постоянно исследуя его. Подход “черный ящик” к open source компонентам не приемлем в крупных компаниях.

Кто должен отвечать за безопасность open-source

Это один из вопросов, который отличает открытое ПО от проприетарного. Фактически, ответственность не закреплена ни за кем. Формально, если говорить о популярных продуктах, вокруг которых уже сформировалось достаточно развитое комьюнити, можно говорить о коллективной ответственности. Для такой модели характерен высокий уровень доверия как одного пользователя к другому, так и пользователей к авторам.

Иван Чернов
Менеджер по развитию UserGate

Вопрос доверия к open-source действительно довольно острый, это правда. Я предлагаю прибегать к модели «нулевого доверия» – когда никакому источнику мы не доверяем априори, когда абсолютно любые источники считаем не доверенными. Любое заимствование кода из open-source должно быть сопровождено аудитом и инспекцией, так как ответственность за использование вредоносного кода ложится на того, кто его заимствует.

Можно попробовать переложить ответственность на автора, но так как головой отвечает в конечном итоге пользователь, то и озаботиться вопросами безопасности в первую очередь нужно ему.

Однако, на данном этапе развития Open Source такой концепт работает на практике далеко не везде. Учитывая тот факт, что открытый код, по данным Red Hat, используется в бизнесе все чаще, вопрос его проверки и анализа становится еще более актуальным.

Артём Гафнер
Ведущий аналитик компании iiii Tech («Форайз»)

Аудит безопасности мы не проводим, но предполагаем, что его необходимо выполнять на этапе выбора компонентов системы. После разработки системы аудит безопасности необходимо проводить одновременно с нагрузочным тестированием.

Как дополнение к аудиту возможно применение в процессах разработки и в процессах компиляции/сборки приложений автоматизированных систем аудитах.

Отвечать за безопасность должны пользователи (разработчики) или специализированные компании по аудиту безопасности ПО.

Важную роль играет зрелость Open Source как концепции. Согласно исследованию Linux Foundation, разработчики ОПО уделяют безопасности своего продукта примерно 3% от времени, которое тратится на разработку. В таких условиях безопасность продукта становится вопросом, который пользователю предстоит решать самостоятельно.

Павел Коростелев
Руководитель отдела продвижения продуктов компании «Код Безопасности»

По-хорошему, аудит безопасности открытого исходного кода представляет многоуровневый процесс. Во-первых, код должен проверять сам программист, который контрибьютит (дополняет открытый код своим. – прим. Ред.) тот или иной проект, во-вторых, его должен проверять пользователь при включении в основную сетку проекта, в-третьих, код должен проверяться дальнейшим регулярным аудитом безопасности. Однако это – идеал и случается редко, ведь по факту в безопасности Open-source кода нет сильно заинтересованных лиц и ей уделяют не так много внимания.

Поскольку далеко не у каждой компании есть достаточное количество свободных и компетентных в вопросах безопасности сотрудников, набирает обороты тренд на делегирование аудита безопасности open-source сторонним, экспертным компаниям.

Это позволяет обеспечить высокий уровень проведения аудита, в рамках которого могут применяться и автоматизированные системы поиска уязвимостей. Весомый плюс работы с профильной компанией – это появление контрагента, который ответственен за результат.

Иван Король
Разработчик ПО Anwork

Аудит безопасности открытого исходного кода происходит по тому же алгоритму, что и коммерческих (закрытых) продуктов. Правообладатель либо проводит подобные аудиты самостоятельно, либо поручает это аутсорсинговым компаниям. Одноразовый аудит – одна из мер проверки и подтверждения безопасности решения. Но это не гарантия того, что потребитель получит качественный и безопасный продукт. В зависимости от области применения софта, аудит должен проводиться с определенной регулярностью – для подтверждения критериев безопасности и надежности решения. Например, в критическом софте важен не столько аудит, сколько изначально сам процесс разработки: отвечает ли он требованиям и стандартам безопасности – от постановки задач и написания кода, до проверки и тестирования продукта.

Влияние геополитики на Open Source

События этого года сильно сказались на самом понимании открытого кода. Если ранее представители сообщества позиционировали свои работы как экстерриториальные продукты, которые распространяются вне зависимости от политических процессов и других социальных вопросов, то сейчас тренд изменился.

Дмитрий Тишкин
Руководитель команды Application Security в компании R-Vision

Основным маркером является, в первую очередь, активность сообщества, разрабатывающего и поддерживающего данный opensource проект. Необходимо проводить постоянный анализ на предмет того, насколько активен поток изменений в репозитории кода проекта, насколько он новый, а также анализировать наличие достаточной документации и автоматизации проверок (тестов).

Еще стоит посмотреть заведенные в open source проекте задачи, в том числе, и как быстро устраняются задачи с уязвимостями или с уязвимыми компонентами.

Кроме этого, принимая во внимание текущую геополитическую ситуацию, следует обращать внимание на политические лозунги в репозитории, особенно от мейнтэйнеров. Также негативным маркером является ситуация, когда у open source проекта продолжительное время не было никакой активности, и, после долгого перерыва, они снова начали поставлять новые версии. Это может сигнализировать об компрометации зависимости.

Можно выделить два важных изменения, которые коснулись мира Open Source:

1. Политизация. Многие разработчики стали использовать свой продукт как «билборд» для политических заявлений. Подобная история освещалась ресурсом BleepingComputer.

2. Региональные альтернативы. Государственный регулятор рассматривает вероятность блокировки иностранных ресурсов, связанных с ОПО, поэтому стремится создать альтернативные. По данным РБК, аналог GitHub может появиться в России в 2024 году.

Геополитический фактор может существенно замедлить развитие Open Source и практику интеграции открытого кода в инфраструктуру компании. Однако, он вряд ли сможет остановить этот рост, ввиду высокой актуальности, эффективности и удобства открытых продуктов как для бизнеса, так и для частных пользователей.

Итоги

Open-source – это стратегическое направление, которое служит драйвером развития всей ИТ-отрасли. Оно позволяет аккумулировать опыт множества разработчиков и развивать продукты не только в рамках одной команды, но и в рамках большого комьюнити.

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

Павел Кузнецов
Директор по продуктам компании «Гарда Технологии»

В силу самой идеологии open-source, вопрос чистоты подобного ПО – вопрос дружелюбности и ответственности всего сообщества: и разработчиков и пользователей. Так, опять же после известных событий, сообщество разработчиков из России и Беларуси создало объединенный трекер внесения злоумышленниками вредоносных изменений в открытый исходный код – для оперативного сообщения владельцам репозиториев о подобной активности и борьбы с этим явлением.

Можно говорить о том, что вопрос аудита и анализа защищенности элементов открытого кода, становится еще более актуальным в текущих условиях. Вероятность скачать из репозитория умышленно уязвимый продукт становится только выше.