Компоненты ПО с открытым кодом могут содержать уязвимости. Как повысить безопасность кода?

В ходе исследования эксперты Gartner пришли к следующим выводам.

• Компоненты с открытым исходным кодом несут в себе множество рисков, включая хорошо известные проблемы, такие как уязвимости и невыгодные условия лицензирования, одновременно с этим растут потребности в оценке операционного риска и выявлении вредоносного кода и других атак на цепочку поставок ПО.
• Покупателям приходится ориентироваться на все более сложном рынке, включающем решения с разным происхождением (open source-решения, независимые решения, пакеты AST и платформы разработки), что усложняет оценку и выбор.
• Команды разработчиков приложений и DevOps наравне с группой безопасности заинтересованы в закупке инструментов тестирования безопасности приложений, включая анализ состава программного обеспечения.
• Проблемы цепочки поставок ПО стимулируют добавление новых функций в инструменты анализа состава ПО, включая оценку операционного риска и проверку на наличие вредоносного кода. Тем не менее, большинство предложений незрелы, когда речь идет об этой функциональности.

Что Gartner советует руководителям служб безопасности?

Чтобы минимизировать риски, связанные с использованием open source, эксперты Gartner рекомендуют придерживаться следующих правил:

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

Таким образом, эксперты Gartner констатируют становление класса решения SCA, рынок которого начинает приобретать более четкий силуэт.

Что такое SCA

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

Почему это важно

Gartner отмечает, что практически все организации используют компоненты c открытым исходным кодом в процессе разработки, чтобы повысить производительность разработчиков, снизить расходы и сроки разработки. Однако, как отмечалось выше, это несет очевидные риски.

Источник фото: gartner.com/en/documents/4005759

Сегодня инструменты SCA в основном нацелены на выявление известных уязвимостей в пакетах с открытым исходным кодом и предупреждение о лицензиях, которые могут налагать условия, неприемлемые для организации, так называемые вирусные лицензии - требовать раскрытия исходного кода всего проекта или оплаты при его распространении. Open source компоненты могут включать в себя другие компоненты, которые, в свою очередь, добавляют в проект все новые и новые библиотеки - транзитивные зависимости. Разработчикам сложно отслеживать такие цепочки вызовов зависимостей. Большинство зрелых продуктов композиционного анализа генерируют отчеты как о прямых зависимостях (тех, которые явно указываются разработчиком), так и о транзитивных. В некоторых случаях одна прямая зависимость может привести к включению в код нескольких уровней транзитивных. Таким образом появляется огромная неконтролируемая слепая зона заимствованного кода. Кроме обнаружения проблемных компонентов SCA-решения предоставляют рекомендации разработчикам в виде обновления версии компонентов или советов по митигации проблемы.

SCA-инструменты и сопутствующие услуги вендоров могут помочь в упорядочении использования open source, в рамках которого устанавливаются и контролируются правила использования компонентов с открытым исходным кодом в приложениях (или в более широкой операционной среде). Инструменты могут делать независимые оценки и сканировать пакеты, но наиболее распространенным вариантом использования является прямая интеграция инструментов в конвейер разработки - в интегрированную среду разработки, в системы контроля версий кода или репозитории артефактов, а также на серверах сборки и интеграции.Михаил Садиров, SMART technologies: На тестирование мультивендорных решений есть спрос

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

Gartner считает, что такие виды оценки операционных рисков быстро станут фундаментальными требованиями к инструментам SCA. Сообщество разработчиков ПО с открытым исходным кодом уже предприняло шаги по предоставлению такой информации для некоторых проектов. Фонд Open Source Security Foundation (OpenSSF) выпустил автоматический инструмент безопасности Open Source Security Scorecard, который в настоящее время предоставляет 16 различных проверок для программного обеспечения в различных open source экосистемах.

Тенденции рынка

В последний год количество запросов в Gartner на исследование SCA увеличилось почти на 20%. Это отражает растущее признание рисков, связанных с использованием open source в разработке, а также связано с атаками на цепочки поставок и предлагаемыми правительственными мерами кибербезопасности. По оценкам Gartner, инструменты SCA внедрили менее половины компаний, но их внедрение будет неуклонно расти из-за следующих факторов.

• Повышенное внимание к безопасности приложений: многие организации стремятся внедрить или усовершенствовать программы безопасности приложений. SCA часто рассматривается как «легкая победа», учитывая широкое распространение открытого исходного кода, относительную простоту усилий по обнаружению и (обычно) относительную легкость решения проблем. Кроме того, растет признание рисков цепочки поставок open source, что еще больше стимулирует внедрение.
• Операционные риски: атаки на цепочки поставок как коммерческого ПО, так и open source являются проблемой на протяжении десятилетий. Эти опасения в сочетании с мерами безопасности, принятыми федеральным правительством США и другими организациями, вызвали интерес к оценке операционных рисков, по сути, к анализу «здоровья и благополучия» проектов с открытым исходным кодом. Некоторые инструменты SCA предоставляют такие оценки, и эта возможность станет необходимым функционалом.
• Перечень используемых компонентов: непрозрачность содержимого данного пакета программного обеспечения (включая прямые и транзитивные зависимости как открытого, так и коммерческого ПО) уже много лет вызывает озабоченность. Это особенно актуально для коммерческого ПО, а также для физических устройств (здравоохранение, производство и т.д.), которые сильно зависят от ПО, но содержание которого непрозрачно для пользователя. Эти проблемы привели к усилиям по созданию перечня используемых компонентов - SBOM - или спецификации материалов программного обеспечения, описывающей элементы, которые использовались при создании данного программного пакета. В США требование к поставщикам программного обеспечения предоставлять SBOM (по крайней мере, для тех, кто продает программное обеспечение федеральному правительству США) было установлено в 2021 году майским указом президента США о кибербезопасности.
• Расширенное управление open source: эксперты Gartner уже давно рекомендуют компаниям разрабатывать официальную программу управления открытым исходным кодом, которая должна помочь определить и управлять рисками, связанными с использованием open source. Такие программы представляют собой превентивные меры по выявлению, изучению и утверждению конкретных пакетов компонентов, разрешенных для использования в проектах разработки. Несмотря на свои преимущества, такие программы трудно создавать, учитывая необходимость в различных инструментах (например, средствах тестирования SCA, репозиториях), процессах поддержки программы и квалифицированном персонале для поддержания системы. Учитывая уже выявленные факторы рынка, потребность в формальных программах управления будет расти, побуждая все больше поставщиков обеспечивать поддержку таких мер в SCA-решениях.

Команды разработчиков приложений и DevOps все чаще покупают инструменты тестирования безопасности приложений, включая SCA. Эта тенденция привела к повышению внимания к инструментам, ориентированным на разработчиков, которые лучше интегрированы в цепочки инструментов разработки и предлагают лучшие возможности для разработчиков.

Анализ предложения

Текущие SCA продукты и сервисы предлагают покупателям следующие возможности.

• Распознавание и идентификация компонентов с открытым исходным кодом. Для этого используются различные технологии, но все они ориентированы на идентификацию определенных пакетов с помощью стандартных методов программирования, используемых для добавления open source компонентов (и другого ПО) в программный продукт. Это могут быть директивы «include», другие инструкции или файлы манифеста, в зависимости от конкретного языка программирования. Кроме того, для этих целей может использоваться сканирование самого кода и/или библиотек для выявления конкретных элементов компонента. Реже инструменты исследуют код в поисках «фрагментов» - частей кода, которые были извлечены из более крупного компонента. Помимо обнаружения конкретных компонентов (прямые зависимости), инструменты также должны выявлять непрямые или транзитивные зависимости, которые возникают в результате того, что один компонент включает в себя другой компонент, часто рекурсивно.
• Идентификация open source лицензий и оценка рисков. Как и коммерческое ПО, открытый исходный код почти всегда распространяется в соответствии с условиями лицензионного соглашения, определяющими способы его использования. Существует много десятков лицензий, условия которых значительно различаются. Некоторые из них считаются разрешительными, в них мало ограничений на способы использования программного обеспечения и мало или вообще нет обязанностей, налагаемых на пользователя. Ограничительные лицензии могут представлять значительный юридический риск и потерю интеллектуальной собственности в результате выполнения условий лицензии. Хотя инструменты попытаются указать проблемные лицензии, решение об использовании компонента на условиях конкретной лицензии должно приниматься по согласованию с юридической службой.
• Уязвимости ПО. Как и любое программное обеспечение, компоненты с открытым исходным кодом содержат уязвимости, которые могут быть использованы злоумышленниками. Важнейшей функцией решений SCA является выявление пакетов, содержащих уязвимости. Эта функция стала отличительной чертой инструментов, при этом вендоры полагаются на широкий круг открытых и частных баз данных, в некоторых случаях пополняемыми внутренними исследовательскими командами, для обеспечения большей точности и уверенности в выводах. Как отмечалось ранее, в рамках этого процесса инструменты дают рекомендации по наиболее подходящему пути обновления для исправления небезопасного пакета.
• Управление и контроль. Организации, для которых важно все риски свести к минимуму, часто хотят обеспечить большую степень контроля над использованием компонентов с открытым исходным кодом в приложениях. В таких случаях обычным подходом является создание репозитория «утвержденных» пакетов с открытым исходным кодом. Разработчики могут свободно использовать любое программное обеспечение, содержащееся в репозитории, но другие пакеты должны пройти процесс рассмотрения и утверждения. Такой подход предполагает наличие ресурсов для рассмотрения предложенных редакций и поддержания актуальности «утвержденных» пакетов в репозитории. Независимо от существования таких «утвержденных» репозиториев, организации должны сканировать программное обеспечение в процессе сборки, чтобы убедиться, что неутвержденное программное обеспечение не прошло через барьер.
• Операционный риск. Как уже отмечалось, оценка различных аспектов операционного риска является новой возможностью. Хотя большинство покупателей по-прежнему сосредоточены на более традиционных требованиях (обнаружение уязвимостей, лицензирование), этот аспект SCA быстро станет критически важной и ожидаемой функцией инструментов.
• Отчетность и анализ. Создание и обмен спецификациями ПО приобретает все большее значение для предотвращения рисков в цепочке поставок ПО. Возможность создания формальной спецификации ПО с использованием любой из опубликованных спецификаций остается редкостью. Вендоры указывают, что они поддерживают построение спецификации, но исключительно в контексте своих собственных инструментов и собственного функционала по генерированию отчетности. Возможность создания спецификации для совместного использования и интеграции в другие системы (например, управление активами программного обеспечения, базу данных управления конфигурацией) будет развиваться одновременно с нормативными актами, требующими их предоставления.

Покупатели могут выбрать разные варианты решений.

• Open source решения. Существует несколько инструментов с открытым исходным кодом, выполняющих задачи SCA. Большинство из них разработаны для поддержки определенного языка программирования или прикладной среды, хотя некоторые, такие как Dependency-Check от Open Web Application Security Project (OWASP), обеспечивают поддержку нескольких языков. Таким образом, они часто ограничены в своих возможностях и могут полагаться только на ограниченные источники данных об уязвимостях при проведении оценок. Такие инструменты обычно не проверяют тип лицензии или другие атрибуты компонента, полезные для оценки операционного риска. Тем не менее, их доступность делает эти инструменты привлекательными.
• Специализированные продукты. Эти коммерческие предложения предоставляют более широкий спектр важного функционала, включая проверку лицензий, рекомендации по устранению последствий, управление open source и применение политик. В качестве примера можно привести MergeBase, Revenera (бывшая Flexera Software) и WhiteSource (теперь Mend). Такие вендоры как Tidelift предоставляют покупателям услугу подписки на поставку проверенных компонентов и возможности тестирования, что может облегчить работу по управлению использованием открытого исходного кода.
• Компонент пакета SAST. Большинство поставщиков решений тестирования безопасности приложений добавили возможности SCA в свои портфели. В качестве примера можно привести Checkmarx, Contrast Security, Veracode, Snyk и Synopsys. В большинстве случаев эти инструменты предлагаются как дополнительный компонент, требующий отдельного лицензирования.
• В составе платформы разработки приложений. Вендоры платформ разработки приложений - быстро развивающегося источника инструментов безопасности приложений - начали включать возможности SCA в свои предложения в качестве дополнительного функционала. В качестве примера можно привести GitHub, Gitlab, JFrog и Sonatype.

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

Gartner советует

• Внедрите политики, основанные на допустимых рисках в таких областях, как безопасность, юридическая ответственность и права интеллектуальной собственности, а также жизнеспособность и целостность цепочки поставок. Актуальность каждого из них будет варьироваться для различных приложений в портфеле организации, но будет полезна даже общая политика. Эта политика может быть использована для описания характеристик компонента с открытым исходным кодом, которые приемлемы или неприемлемы для организации, и поможет определить необходимые возможности продукта (обнаружение уязвимостей, лицензирование, операционный риск и т.д.).
• Политики безопасности должны указывать степень серьезности и/или типы уязвимостей, которые составляют приемлемый риск. Эти политики должны учитывать профиль риска конкретного приложения, поскольку то, что может быть приемлемым для одного приложения, для другого может представлять значительный риск несоответствия нормативным требованиям или безопасности. Политики должны включать рекомендации по устранению уязвимостей в случаях, когда исправление недоступно, или когда в противном случае необходимое исправление должно быть отложено. Например, обновление open source компонента может решить проблему безопасности, но из-за изменений в функциях может нарушить работоспособность приложения, использующего такой компонент, что потребует других изменений в приложении. В некоторых случаях исправление может быть просто недоступно.
• Инструменты SCA, как правило, должны соответствовать темпам и масштабам оценки, необходимым для поддержки DevOps или других динамичных подходов к разработке. Критерии оценки должны включать такие факторы, как:
  • технологический охват - языки, фреймворки и open source экосистемы, которые будут оцениваться;
  • глубина и широта данных, предоставляемых инструментами - уязвимости, количество и качество источников этих данных, включая определение типов лицензий и относительных рисков;
  • информация о статусе и происхождении отдельных компонентов, а также возможность приоритизации этих данных;
  • операционное «соответствие» для основных конечных пользователей продукта - например, разработчики предпочитают совершенно иные интерфейсы и наборы возможностей, чем команды юристов или закупок;
  • способность помочь в определении потенциальных мер по исправлению ситуации или смягчению последствий;
  • интеграция в жизненный цикл разработки программного обеспечения (SDLC) и другие соответствующие системы.

• При оценке вариантов покупателям следует внимательно рассмотреть общие расходы. Клиенты Gartner регулярно выражают озабоченность по поводу расходов, связанных с инструментами безопасности, и SCA не является исключением. Но похоже, это становится неизбежным.

Ситуация на российском рынке

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

Но есть и специализированные инструменты. Пионером SCA на отечественном рынке является CodeScoring от компании Profiscope, которое в полной мере закрывает существующие потребности на сегодняшний день и активно развивается. Функционал CodeScoring позволяет не только управлять операционными и лицензионными рисками, уязвимостями безопасности, генерировать спецификацию ПО (SBOM), но и анализировать качество кода с точки зрения операционных рисков. А таким широким функционалом обладают не все SCA-решения из отчета Gartner.

Читайте также

• Анализ кода: проблемы, решения, перспективы
• Стратегия безопасной разработки ИТ-продуктов. Подход Bercut