Opensource-проекты становятся все более популярными благодаря своей гибкости и доступности. Однако с увеличением их использования в коммерческих и частных целях возникает вопрос о безопасности.
Рассказываем, как обеспечивается информационная безопасность в опенсорс-проектах, кто несет ответственность за безопасность, как часто проводится тестирования и какие инструменты и методы для этого используются.
Opensource (или открытое программное обеспечение, опенсорс) — это модель разработки программного обеспечения, в рамках которой исходный код доступен для свободного использования, изменения и распространения. Такие проекты позволяют разработчикам и пользователям со всего мира совместно работать над улучшением и адаптацией программных продуктов. Примеры известных опенсорс-проектов включают Linux, Apache, и PostgreSQL.
Петр Василенко
Генеральный директор ГрафТех и графического редактора «Автограф»
Для российского IT-рынка важен не сам по себе опенсорсный продукт, а то, какие решения создаются уже коммерческими командами на его основе. В самом опенсорсном продукте блок информационной безопасности может быть прописан, а может быть не проработан вообще. А вот в решениях, которые российские вендоры создают на их основе и выпускают на рынок, этот аспект должен быть хорошо продуман. Кто-то проводит анализ исходного кода, исследует на предмет уязвимостей, закрывает их, проводит рефакторинг и только после этого отдает клиентам. Но есть и те, кто берет опенсорс-продукт, встраивает его в архитектуру, вешает собственный лейбл и выпускает на рынок без этой предварительной шлифовки. И это большая проблема.
Но рыночная конкуренция все расставляет по своим местам, и все больше компаний начинают смотреть на глубину проработки опенсорсных элементов, потому что бизнес постепенно наращивает экспертизу в сфере информационной безопасности и хочет контролировать закупку ПО и с этой стороны.
Плюсы использования опенсорса:
Минусы использования опенсорса:
Таким образом, несмотря на недостатки, опенсорс-программное обеспечение продолжает набирать популярность, становясь важным элементом современной ИТ-инфраструктуры.
Вопрос обеспечения безопасности в опенсорс-проектах становится все более актуальным, особенно с ростом их использования в различных сферах. Одной из ключевых тем является наличие специалистов, ответственных за безопасность, и их роль в процессе разработки.
Дмитрий Овчинников
Руководитель Лаборатории стратегического развития продуктов кибербезопасности Аналитического центра кибербезопасности «Газинформсервис»
Опенсорс-проекты очень разные по наполнению и по командам, которые над ними работают. Поэтому в каждом проекте проверка на безопасный код производится по-разному и с разной частотой.
В каких-то командах на эту задачу назначен отдельный программист, в каких-то ведется совместная работа над безопасностью кода. Плюс опенсорс решений в том, что любой может проверить исходный код на безопасность и практическую значимость. Этот фактор как раз и позволяет «живым» проектам быть безопасными. Конечно, это не гарантирует того, что в коде не будет закладок. Поэтому компаниям, которые используют опенсорс, лучше придерживаться следующих правил:
Использовать наиболее зрелые и проверенные временем решения.
Если есть возможность, то сначала проверять работоспособность на отдельном стенде. Такая возможность требует большого объема времени и сил, поэтому такое возможно не всегда.
Следить за обновлениями и за новостями по обнаружению уязвимостей в опенсорс продукте.
Тщательно защитить среду и сетевой сегмент, где используется опенсорс. Это снизит вероятность взлома или использования уязвимостей в опенсорсе при атаке.
В большинстве опенсорс-проектов отсутствует централизованная команда безопасности, как это принято в коммерческих компаниях. Вместо этого безопасность часто зависит от заинтересованных участников сообщества. Некоторые крупные проекты, такие как Linux или Kubernetes, имеют выделенные группы или даже отдельных специалистов, которые занимаются вопросами безопасности. Однако для небольших проектов или менее известных библиотек такая структура может быть недостаточной.
Никита Распопов
Специалист по анализу защищенности УЦСБ
В большинстве opensource-проектов отсутствуют специалисты, формально назначенные для обеспечения безопасности. Это связано с тем, что такие проекты часто разрабатываются добровольцами или небольшими командами без официального управления. Однако безопасность все чаще становится приоритетом для крупных opensource-проектов. Проверки безопасности либо проводятся самостоятельно разработчиками, либо открывается программа приема уязвимостей со стороны исследователей безопасности.
В случае проектов, поддерживаемых крупными компаниями, безопасностью занимаются уже специализированные команды. Например, если у вас появится вопрос о безопасности дистрибутива Ubuntu, вы обнаружили уязвимость в компонентах дистрибутива или хотите получить консультацию, вы можете связаться со специалистами компании.
Часто ответственность за безопасность распределена между всеми участниками проекта. Это означает, что разработчики и пользователи должны быть активными в поиске уязвимостей и их исправлении. Такой подход может привести к более быстрому выявлению проблем, но также создает риски, если недостаточно внимания уделяется вопросам безопасности.
Обеспечение безопасности в опенсорс-проектах требует постоянного внимания, и регулярное тестирование и анализ безопасности играют ключевую роль в этом процессе. Частота проведения таких мероприятий может варьироваться в зависимости от размера проекта, его популярности и уровня риска.
В крупных опенсорс-проектах, таких как Linux или Kubernetes, тестирование безопасности может проводиться регулярно, например, каждые несколько недель или после выпуска новой версии. Эти проекты обычно имеют четко установленные процессы, включая автоматизированные тесты, которые помогают выявлять уязвимости на ранних стадиях.
Ильмар Хабибулин
Заместитель директора центра разработки и тестирования NGR Softlab
Опенсорс-проекты разные, и реализация этих инициатив зависит от управляющих проектом. Даже при наличии встроенных в пайплайны проектов механизмов юнит- и фаззинг-тестирования, бывают неучтенные ситуации, которые вызывают ошибки и сбой программ.
Также стандартной проблемой является контроль внешних зависимостей. Не все пакетные менеджеры предлагают для него встроенные инструменты, и поэтому необходимо использовать внешние. Все это является отдельным видом деятельности, однако разработчик обычно сосредоточен на создании кода, а не на тестировании безопасности.
Небольшие проекты, как правило, не имеют такой системности. Тестирование может проводиться не регулярно, а по мере появления новых уязвимостей или обновлений. В таких случаях на качество тестирования влияет активность сообщества и заинтересованность разработчиков в безопасности.
Внедрение опенсорс-компонентов в корпоративные системы требует тщательного подхода к обеспечению безопасности. Компании используют разнообразные инструменты и методики, чтобы минимизировать риски и защитить свои данные.
Денис Фокин
Руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft
Если рассматривать использование библиотек с открытым исходным кодом при разработке собственных приложений, без применения специальных инструментов это несет определенную угрозу. Как минимум нужно позаботиться об использовании локального репозитория для хранения библиотек, чтобы избежать рисков, когда автор удаляет или изменяет библиотеку, что автоматически может сказаться на проектах, в которых она используется. А как максимум — использовать OSA/SCA-инструменты и выстроить процесс анализа библиотек, содержащих уязвимости, и исключения их применения в проектах.
В перечень инструментов, необходимых для обеспечения безопасности опенсорс-проектов, входят:
Таким образом, использование правильных инструментов и методик помогают компаниям эффективно управлять безопасностью опенсорс-компонентов и снижать риски.
Обеспечение безопасности в опенсорс-проектах представляет собой общий вызов, требующий совместных усилий разработчиков, организаций и пользователей. Несмотря на множество преимуществ, таких как гибкость и доступность, открытые проекты могут быть уязвимы, если не принимать серьезных мер по их защите.
Регулярное тестирование, использование современных инструментов и организационных подходов, а также активное взаимодействие с сообществом — все это играет ключевую роль в снижении рисков.
Нажимая на кнопку, я даю Согласие на обработку персональных данных в соответствии с Политикой обработки.
Зарегистрироваться