Open Source – панацея или риск?

Программное обеспечение с открытым исходным кодом, или open-source software, помогает быстро и беспроблемно разрабатывать софт, выпускать релизы. Сегодня рынок ПО с open source успешно растёт, конкурируя с частным софтом. Приоритетом является, конечно же, бесплатное использование или минимальные затраты. Особенно популярен Open Source среди стартап-проектов, ведь он позволяет экономить время при создании ПО.  Российская действительность на сегодняшний день такова, что в условиях санкций open source — это не столько инструмент и помощник в разработке, сколько необходимость – и в ближайшее время ситуация вряд ли изменится, ведь чтобы создать подобную российскую платформу, потребуется слишком много ресурсов, в том числе сильная юридическая поддержка – на это пока нет ни времени, ни широких финансовых возможностей, только долгосрочное планирование.

 

Open source – это ни плохо и ни хорошо, это возможность ускорить процесс разработки.

 

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

 

Решение проблемы

 

ПО с открытым кодом вообще является лакомым кусочком для мошенников. Есть немало примеров, когда компания не замечала существующей уязвимости в работе продукта на протяжении очень долгого периода, ведь в работе с open source много лазеек, которые позволяют злоумышленнику завладеть нужной информацией или управлением определённого сервиса даже просто нажав нужную кнопку или заполнив строку в журнале необходимым текстом.

Компании вынуждены работать над снижением рисков, проводить как раз-таки анализ уязвимостей, специалисты ищут выходы – к примеру, известна программа спецификации программного обеспечения (SBOM), которая содержит перечень компонентов, используемых для создания продукта. SBOM – что-то вроде аннотации, в которой прописаны компоненты ПО, зависимости, названия, версии, лицензии, порой даже более подробная информация: к примеру, данные по рискам, вторичные зависимости.

 

Чем же хороша эта программа?

 

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

  1. Сбор и анализ требований к программному продукту
  2. Разработка документации для всех требований к продукту
  3. Разработка дизайна продукта
  4. Разработка программного обеспечения
  5. Прохождение различных тестов
  6. Ввод в эксплуатацию и поддержка ПО

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

Также с помощью SBOM можно проверять действительность существующих лицензий на используемое ПО и открытый код – а это в первую очередь значит, что компания будет защищена от финансовых рисков и репутационных скандалов.

Помимо этого, есть решение для состава анализа ПО – Software Composition Analysis. SCA проводит анализ приложений и продуктов, которые разрабатываются в данный момент, и идентифицирует встроенные компоненты, содержащие открытый код, а также показывает наличие уязвимостей внутри проектов – это и повышает эффективность разработки, и снижает количество затраченных ресурсов на исправление багов. Как и SBOM, SCA может помочь с проверкой лицензии, что гарантирует юридическую безопасность и правовую защищенность.

Возвращаясь к SBOM, стоит отметить, что участники команды, разрабатывающей программу спецификации программного обеспечения (SBOM), обладают различным функциональным опытом, что позволяет им достигнуть общую цель, выполнить полный объем работ – это единый организм. В этой команде должны быть и разработчики, и юристы, и безопасники, и сотрудники отдела рисков, и специалисты по закупкам, специалисты отдела по контролю соответствия – опыт и мнение каждого из них важны для оптимальной и слаженной работы.

 

Какой вывод мы можем сделать?

 

Open Source используется очень давно. Открытый код успешно интегрируется в разработку нового ПО. Главная задача состоит в том, чтобы минимизировать риски, обеспечить информационную безопасность за счёт интеграции новейших технических практик и процессов обновления зависимостей, а также кропотливый выбор компонентов, библиотек и фреймворков, которые должны быть включены в проекты. Для этих целей существуют и программа SBOM, и SCA. Очень важно соблюсти баланс – не жертвовать качеством продукта ради быстрого релиза, использовать open source, но тщательно проверять компоненты и зависимости, анализировать риски и уязвимости, обеспечивать информационную безопасность, вследствие которой гарантируется юридическая защищённость компании и её проектов.

 

Запросить медиа-кит и прайс