Что такое sca

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

Растущие риски и повсеместное использование открытого исходного кода в разработке программного обеспечения требуют анализа состава программного обеспечения (SCA) для обеспечения безопасности приложений. Руководители служб безопасности должны расширить область применения SCA-инструментов, включив в нее обнаружение вредоносного кода, операционных рисков и рисков цепочки поставок, считают в Gartner. Аналитики Gartner подготовили отчет «Market Guide for Software Composition Analysis», который помогает разобраться в функциональных возможностях класса SCA — Software Composition Analysis, анализ состава ПО — и выбрать подходящий для себя инструмент. Эксперты компании Web Control (Вэб Контрол ДК) специально для TAdviser сделали обзор этого документа.

В ходе исследования эксперты 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, в рамках которого устанавливаются и контролируются правила использования компонентов с открытым исходным кодом в приложениях (или в более широкой операционной среде). Инструменты могут делать независимые оценки и сканировать пакеты, но наиболее распространенным вариантом использования является прямая интеграция инструментов в конвейер разработки — в интегрированную среду разработки, в системы контроля версий кода или репозитории артефактов, а также на серверах сборки и интеграции. Российский рынок мобильных приложений для бизнеса и госсектора: крупнейшие игроки, тенденции и перспективы. Обзор TAdviser

При оценке операционного риска учитываются такие факторы, как количество разработчиков, поддерживающих проект и их репутация, частота обновлений, реакция на сообщения об уязвимостях и других дефектах, а также изменения в управлении проектом. В поддержку этой функции некоторые инструменты включают возможность тестирования пакетов на предмет неожиданных изменений или наличия вредоносного кода. Такой функционал не является распространенным, поскольку большинство инструментов 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 в своих решениях.

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

Обзор рынка инструментов SCA (Software Composition Analysis)

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

Введение

1.1. Принципы работы SCA
1.2. Почему важен анализ компонентов программного обеспечения (SCA)?
1.3. Задачи инструментов SCA

5.1. Black Duck
5.2. CAST Highlight
5.3. CodeScoring
5.4. Debricked
5.5. FOSSA
5.6. GitLab
5.7. Mend
5.8. ShiftLeft
5.9. Snyk
5.10. Sonatype Nexus Lifecycle
5.11. WhiteHat Sentinel

Введение

Открытый исходный код может содержать критические уязвимости. Недавний пример — широко используемая библиотека Apache Log4j, которая позволяла злоумышленникам выполнять произвольный код на устройствах, чтобы внедрить вредоносный софт или совершить мошенничество. И, к сожалению, этот пример — не единственный.

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

Принципы работы SCA

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

Инструменты SCA уже давно присутствуют на рынке, но растущее распространение открытого исходного кода за последние несколько лет сделало их ключевым элементом безопасности приложений. Современные подходы к разработке программного обеспечения, в том числе DevSecOps, требуют, чтобы SCA был в первую очередь ориентирован на программистов, предоставляя удобные им инструменты, а также на сотрудников служб безопасности, задача которых — направлять разработчиков, чтобы обеспечить безопасность на всех этапах SDLC.

Почему важен анализ компонентов программного обеспечения (SCA)?

Компоненты с открытым исходным кодом становятся основными строительными блоками программного обеспечения практически во всех сферах. SCA-системы помогают отслеживать опенсорсные компоненты в составе приложения, что существенно с точки зрения безопасности их применения. Всё больше и больше современных приложений строятся на основе открытого исходного кода. Было подсчитано, что Open Source составляет до 90 процентов кода приложений. При этом одна из проблем заключается в том, что приложения собираются из разных блоков, и все они должны быть защищены, чтобы была возможность эффективно управлять рисками и снижать их.

Задачи инструментов SCA

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

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

Недавно выпущенный доклад Snyk показал, что 86 % уязвимостей node.js обнаруживаются в транзитивных зависимостях. Аналогичны цифры для экосистем Java и Python. Это означает, что подавляющее большинство уязвимостей в приложениях обычно находятся в том открытом исходном коде, об использовании которого разработчики даже не подозревают.

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

Понимание логики зависимостей. Для точного определения зависимостей (и уязвимостей, которые они создают) требуется глубокое понимание того, как каждая экосистема их обрабатывает. Важно, чтобы решение SCA учитывало эти нюансы и не порождало излишних ложных срабатываний.
Оценка приоритета уязвимостей. На данный момент выявленные уязвимости, требующие внимания, уже исчисляются тысячами. Учитывая ограниченный объём ресурсов, имеющихся в распоряжении разработчиков и специалистов по безопасности, крайне сложно расставить приоритеты без необходимого набора знаний по информационной безопасности. Метод оценки уязвимостей CVSS (Common Vulnerability Scoring System) помогает, но имеет несколько недостатков, которые затрудняют его использование. Сбои CVSS в значительной степени связаны с различиями в средах и в том, как они эксплуатируются, проектируются и собираются. Оценки CVSS не учитывают ни возраст уязвимости, ни её использование в цепочках эксплойтов.
Развитие единой актуальной базы уязвимостей. Значительный объём аналитических данных разбросан по разнообразным источникам: национальные базы, онлайн-форумы, тематические аналитические онлайн-издания по безопасности и т. д. При этом уязвимости могут добавляться туда несвоевременно. Это отставание может иметь решающее значение.
Повышение скорости безопасной разработки. Код должен пройти проверку на безопасность, прежде чем двигаться далее по релизному процессу. Если соответствующим службам не удастся оперативно провести проверку на наличие уязвимостей, этот процесс может замедлиться. Средства автоматизированной проверки кода позволяют решить эту проблему, так как дают возможность синхронизировать процессы разработки и поиска уязвимостей и не вызывать непредвиденных задержек.

Существование перечисленных выше проблем привело к появлению концепции DevSecOps и модели «shift left», в результате чего ответственность за безопасность легла на плечи команд разработчиков. С учётом этого принципа было создано новое поколение решений SCA, которое позволяет проверять безопасность компонентов с открытым исходным кодом на ранних этапах процесса разработки.

Особенности подбора и использования SCA

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

SCA-системы полезно оценивать по следующим возможностям и параметрам:

Удобство для разработчиков.
Экосистемность и интеграционные возможности.
Анализ зависимостей.
Обнаружение, приоритизация, исправление уязвимостей.
Управление и контроль.
Составление отчётов.
Автоматизация и расширяемость.
Безопасность облачных приложений.

Удобство для разработчиков

Времена, когда служба безопасности просто передавала программистам список уязвимостей для исправления, давно прошли. DevSecOps требует от разработчиков брать на себя больше ответственности за безопасность, но этого не произойдёт, если инструменты, которые они используют, работают против них. Если инструмент SCA слишком сложен в использовании или затрудняет разработку, он не принесёт большой пользы. Таким образом, инструмент SCA должен:

быть интуитивно понятным и простым в настройке и использовании;
легко интегрироваться с существующими рабочими процессами;
автоматизированно предоставлять практические рекомендации по решению проблем.

Экосистемность и интеграция

Без возможности охватить языки, используемые для создания ваших приложений, или вписаться в вашу среду разработки инструмент SCA будет менее эффективным. Некоторые решения SCA могут обеспечивать полный языковой охват, но при этом не предоставляют, например, подключаемого модуля для Jenkins, позволяющего легко добавлять тестирование безопасности приложений в качестве шага в процессе сборки, или модулей для IDE.

Анализ зависимостей

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

Обнаружение, приоритизация, исправление уязвимостей

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

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

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

Управление и контроль

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

Отчётность

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

Автоматизация и расширяемость

Чем больше среда разработки, тем сложнее выполнять все ручные операции, связанные с процессами SCA. Возможность автоматизации таких задач, как добавление новых проектов и пользователей для тестирования или сканирование новых сборок в рамках конвейеров CI / CD, повышает эффективность, а также помогает смягчить конфликты с существующими рабочими процессами, что крайне важно для успешного DevSecOps.

Одним из ключевых требований, которые следует учитывать, является наличие надёжного API, так как это обеспечивает более глубокую интеграцию. Дополнительно стоит отметить возможность взаимодействия со смежными системами (SOAR, SIEM) в части получения информации об инцидентах в безопасности.

Безопасность управления компонентами приложений

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

Мировой рынок систем SCA

По прогнозам аналитического агентства Mordor Intelligence, рынок SCA-решений вырастет в среднем на 21,7 % в течение прогнозируемого периода с 2021 по 2026 год. Предполагается, что потребность в SCA в основном обусловлена растущим количеством угроз для программ с открытым исходным кодом. Кроме того, ожидается рост количества коммерческих программных продуктов и систем на основе IoT, которые опираются на множество опенсорсных компонентов, находящихся в открытом доступе.

По мнению аналитиков, Северная Америка будет доминировать на мировом рынке анализаторов состава программного обеспечения с точки зрения доходов в течение ближайших пяти лет благодаря всё более широкому внедрению подобных инструментов в этом регионе. Также в последнее время SCA-инструменты активно масштабируются в Азии и Австралии.

Рисунок 1. Прогнозируемый темп роста SCA-технологий по регионам

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

Перечень лидеров мирового рынка на данный момент возглавляют компании Synopsys, Sonatype, WhiteHat Security и Veracode. Далее в обзоре будет приведено описание их разработок, а также продуктов других компаний:

Black Duck.
CAST Highlight.
Debricked.
FOSSA.
GitLab.
Mend.
ShiftLeft.
Snyk.
Sonatype Nexus Lifecycle.
WhiteHat Sentinel.

Российский рынок систем SCA

Отечественные производители инструментов статического анализа кода анонсируют отдельные функции SCA в своих решениях. Объём соответствующего сегмента на 2020 год составил не более 6 % от общего размера российского рынка ИБ.

В ближайшем будущем ожидается увеличение количества отечественных продуктов на рынке ИБ в России, что, вероятно, будет касаться и SCA-решений. Основными драйверами роста рынка будут, в первую очередь, ускорение тенденции к импортозамещению в связи с уходом зарубежных вендоров из страны, а также повышенное внимание компаний к кибербезопасности из-за ускоренной цифровизации и перестройки бизнес-процессов, вызванной пандемией. Также сильное влияние оказывают периодические резонансные инциденты в сфере безопасности и возможное ужесточение ответственности за них.

В следующем разделе приведено описание самого известного из отечественных SCA — CodeScoring.

Обзор мирового рынка SCA 2022

Black Duck

Black Duck от компании Synopsys уже более 15 лет предоставляет командам безопасности, юристам и разработчикам по всему миру возможность управлять рисками. Опираясь на базу данных по опенсорсным компонентам, уязвимостям и лицензиям, решения Black Duck проводят анализ и аудит состава программного обеспечения с открытым исходным кодом и предоставляют информацию, которая необходима для его отслеживания. Black Duck предлагает комплексное исследование состава ПО, а также обеспечивает контроль тех рисков в области безопасности, качества и соответствия требованиям, которые могут быть вызваны сторонним и открытым исходным кодом в контейнерах и приложениях. Решение обеспечивает видимость стороннего кода, позволяя управлять им на протяжении всей цепочки поставок программного обеспечения, а также всего жизненного цикла приложения.

CAST Highlight

CAST Highlight распространяется по схеме SaaS и предназначен для быстрого анализа корпоративного портфеля приложений. Он автоматически анализирует исходный код и состав программ, проверяет отказоустойчивость. Объективные сведения о программном обеспечении, полученные в результате автоматизированного анализа исходного кода, позволяют принимать более обоснованные решения. Технология CAST может «заглянуть внутрь» пользовательских приложений, автоматически собирая информацию об их составе, архитектуре, потоках транзакций, структурных недостатках, юридических рисках и проблемах безопасности. Инструмент позволяет быстро проводить миграцию в облако, повышать скорость и эффективность разработки программного обеспечения, а также обеспечивать контроль рисков применительно к открытому исходному коду. CAST работает по всему миру с офисами в Северной Америке, Европе, Индии, Китае.

CodeScoring

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

Система обеспечивает возможность встраивания на всех этапах SDLC через интеграцию с необходимыми смежными системами: блокирование нежелательных компонентов в прокси-репозиториях, проверка и блокирование сборок продуктов в CI-конвейерах, непрерывный риск-мониторинг веток и тегов в репозиториях. Для каждого этапа жизненного цикла возможно настроить гибкие политики безопасной разработки: от блокирования нежелательных компонентов и уведомления ответственных специалистов до сигнализации в смежные системы.

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

Debricked

Сервис Debricked основан на машинном обучении; благодаря этому повышается точность его работы, обеспечиваются высокое качество данных и оперативное обновление. Он постоянно отслеживает код и уведомляет всякий раз, когда обнаруживается новая уязвимость. Инструмент помогает разработчикам, обеспечивая соответствие открытого исходного кода автоматизированным и обязательным правилам конвейера. Он также рассчитывает уровни риска для репозиториев на основе предполагаемого использования. В итоге появляется возможность более широко использовать Open Source и не беспокоиться при этом о вероятных проблемах в области безопасности.

FOSSA

Флагманский продукт FOSSA позволяет отслеживать открытый исходный код, а также автоматизирует сканирование лицензий и обеспечение соответствия нормативным требованиям. Инструменты FOSSA использовались в интересах более чем 7000 проектов с открытым исходным кодом (Kubernetes Webpack, Terraform и ESLint), а также применялись такими компаниями, как Uber, Ford, Zendesk и Motorola. Помимо анализа уязвимостей в инструменте сделан акцент на лицензиях и авторских правах. Исследовательская группа юридических консультантов сервиса непрерывно поддерживает информацию в общедоступной базе по лицензированию в актуальном состоянии.

GitLab

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

Mend

Mend (ранее WhiteSource) — решение для гибкого управления безопасностью открытого исходного кода и соблюдения требований лицензий. Интегрируется с конвейером DevOps в режиме реального времени для обнаружения уязвимых опенсорсных библиотек. Инструмент выполняет автоматизацию политик и предлагает пути исправления изъянов, а также позволяет устанавливать приоритеты предупреждений об уязвимостях. Mend поддерживает более 200 языков программирования и одну из самых больших баз данных уязвимостей, объединяющую информацию из десятков источников. Единый интерфейс для пользовательского и открытого исходного кода обеспечивает максимальную эффективность и простоту.

ShiftLeft

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

Snyk

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

Sonatype Nexus Lifecycle

Этот продукт используют более 100 000 организаций по всему миру. Он совместим с компонентами Maven / Java, npm и NuGet, Helm и Docker, OBR, APT и GO, компонентами R и многими другими. Все компоненты, двоичные файлы и артефакты доступны из одного источника. В решение включена расширенная поддержка виртуальной машины Java (JVM), включая Gradle, Ant и Maven, а также Ivy. Совместим с Eclipse, IntelliJ и Hudson, Jenkins, Puppets, Chef, Docker и многими другими популярными инструментами. Является источником достоверной информации для всех компонентов на протяжении всего жизненного цикла разработки, включая контроль качества, подготовку и эксплуатацию. Доступна интеграция с существующими системами обеспечения доступа пользователей, такими как LDAP, Atlassian Crowd и другими.

WhiteHat Sentinel

WhiteHat Sentinel построен по принципу SaaS, разработан с нуля для массового масштабирования и поддержки крупнейших предприятий. В отличие от традиционного программного обеспечения WhiteHat Sentinel сочетает патентованную технологию сканирования с «человеческим» тестированием силами центра исследования угроз — группы экспертов по безопасности веб-сайтов. Продукт постоянно сканирует веб-сайты по мере их развития, автоматически обнаруживая и оценивая изменения кода и уязвимости, а затем отчёт проходит дополнительную верификацию на стороне специалистов центра исследования угроз. Хорошо подходит для гибкой разработки, так как позволяет обеспечить интеграцию с ключевыми инструментами разработчика и поддержку процессов CI / CD.

Выводы

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

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

Specialty Coffee Association (SCA): организация, которая развивает индустрию

Отделение Ассоциации Спешелти Кофе в России существует с 2002 года. Несмотря на то что членство стоит от 70$ до 300$ в год, в российской Ассоциации состоит уже 356 человек. Разбираемся, чем полезна SCA и почему люди стремятся в неё вступить.

7 мин. на чтение

Specialty Coffee Association (SCA): организация, которая развивает индустрию

Что такое SCA

SCA (Specialty Coffee Association или Ассоциация Спешелти Кофе) существует для того, чтобы продвигать спешелти кофе. Это некоммерческая организация, основанная на принципе открытости и желании делиться знаниями. Она объединила весь кофейный мир: фермеров, обжарщиков и бариста.

Ещё три года назад SCA не существовало. В 1982 году была основана SCAA — Specialty Coffee Association of America, в 1998 появилась SCAE — Specialty Coffee Association of Europe. В январе 2017 года они объединились в SCA.

В России отделение SCA функционирует на волонтёрских началах. Её работа отличается от других отделений Ассоциации. Например, во многих европейских странах организацией чемпионатов занимается комитет SCA из 5 человек. В России проводится несколько региональных отборочных помимо национального чемпионата, поэтому в организации участвует гораздо больше человек.

Миссия Ассоциации: объединить участников кофейной индустрии по всему миру, повысить стандарты качества, вдохновить каждого члена сообщества на развитие, рассказать миру о спешелти кофе. Для этого SCA работает в трёх направлениях: методология, обучение и продвижение. Расскажем подробнее о каждом из них.

SCA разработала стандарты каппинга — от количества воды до высоты стола

Как Ассоциация развивает знания о спешелти кофе

Ещё 30 лет назад все данные о кофе были обрывочными, разрозненными и неупорядоченными. SCA собрала информацию о кофе, классифицировала её и выделила понятие «спешелти кофе».

Впервые определение «спешелти кофе» дала Эрна Кнатсен, основатель компании по продаже кофе Knutsen Coffee Ltd: «Спешелти кофе — это зёрна с уникальными характеристиками вкусоароматического букета, выращенные в уникальном географическом микроклимате». Это случилось в 1978 году в Монреале на выступлении для делегатов международной кофейной организации.

Ассоциация продолжила развивать это определение и сделала его фундаментом индустрии. Также SCA разработала стандарты, теперь во всём мире:

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

Появление стандартов SCA привело к единообразию кофейных процессов и ещё больше сплотило кофейных специалистов во всём мире.

Какие направления обучения разработала Ассоциация

Ассоциация разработала программу обучения, которую может пройти как новичок, так и профессионал. Она состоит из 6 модулей:

Введение в кофе (Introduction to Coffee);
Навыки бариста (Barista Skills);
Заваривание кофе (Brewing);
Зелёный кофе (Green Coffee);
Обжарка (Roasting);
Дегустация кофе (Sensory Skills).

Модуль «Введение в кофе» имеет 1 уровень, все остальные модули — 3 уровня: базовый (Foundation), продвинутый (Intermediate) и профессиональный (Professional).

После прохождения обучения ученики получают диплом SCA

Базовый подходит для новичков. Продвинутый — для тех, кто уже работает в индустрии. Профессиональный уровень можно проходить только после сдачи экзамена по продвинутому уровню.

Как Ассоциация продвигает спешелти кофе

SCA распространяет информацию о спешелти кофе разными способами. Основной инструмент в России — чемпионаты.

Идею проведения чемпионатов среди бариста предложил Альф Крамер, первый президент SCA в Европе (SCAE). С их помощью он хотел улучшить качество кофе в мире, мотивировать бариста развиваться, повысить значимость этой профессии и привлечь внимание к кофейной индустрии. И у него получилось.

Впервые мировой чемпионат бариста провели в 2000 году в Монте-Карло, где участвовало всего 13 стран. На тот момент профессия бариста была непопулярной, а доля спешелти кофе на мировом рынке не превышала 5 %. Но чемпионат прошёл успешно и сразу привлёк всеобщее внимание к индустрии.

В дальнейшем стали появляться другие дисциплины:

Кап-тестинг — соревнование по умению быстро и точно определить по вкусу отличную от других чашку кофе;
Кофе и алкоголь — соревнование по приготовлению авторских напитков на основе кофе, алкоголя и других ингредиентов;
Ибрик/джезва — соревнование по приготовлению кофе в ибрик/джезве (проще говоря — турке);
Брюерс кап — соревнование по завариванию кофе альтернативными методами;
Обжарка — соревнование по обжарке кофе;
Латте-арт — соревнование по рисованию молочной пеной на кофе.

Роман Стерхов, наш менеджер по качеству, занял первое место на Уральском чемпионате бариста в 2018 году, который проводился под эгидой SCA

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

Что даёт членство в SCA

Членство в SCA — обязательное условие для тех, кто хочет участвовать в чемпионатах. Остальные вступают в Ассоциацию по другим причинам:

доступ к исследованиям рынка и информации об экономических стратегиях индустрии. Всё это — подсказки для дальнейшего развития специалистов, кофеен, обжарочных компаний;
возможность обучаться на тренера AST (Authorized SCA Trainers);
подписка на ежеквартальный журнал Café Europa, где собраны последние новости индустрии;
доступ к использованию логотипа Ассоциации;
скидки на обучение по программе SCA;
20 % скидка на журналы, книги, посуду в онлайн-магазине SCA;
возможность голосовать при выборах Совета Правления, Национального Комитета и Гильдии.

Вступить в Ассоциацию может каждый. Для этого нужно заполнить анкету на сайте SCA и заплатить денежный взнос. Для всех цена разная: для бариста 70$ в год, для обжарщика 200$, для небольшой кофейни 300$. Обучаться по программам SCA можно и без членства, но заплатить за обучение придётся больше.

В Ассоциацию не могут вступить жители Ирана и Крыма из-за санкций, так как SCA — американская организация.

Нужно ли вступать в SCA? Подведём итоги

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

По данным на апрель 2019 года, 356 человек в России состоят в SCA. Членство даёт много преимуществ, но не всем оно нужно. Быть членом Ассоциации или нет — решать только вам.

Specialty Coffee Association (SCA): организация, которая развивает индустрию

Вам может быть интересно:

История появления «Харио V60»

22 июн 2020 · 10 мин. на чтение

DevSecOps: принципы работы и сравнение SCA. Часть первая

Значимость анализа сторонних компонентов ПО (англ. Software Composition Analysis — SCA) в процессе разработки растет по мере выхода ежегодных отчетов об уязвимостях open source библиотек, которые публикуются компаниями Synopsys, Sonatype, Snyk, White Source. Согласно отчету The State of Open Source Security Vulnerabilities 2020 число выявленных уязвимостей в open source в 2019 выросло почти в 1.5 раза в сравнении с предыдущим годом, в то время как компоненты с открытым кодом используются от 60% до 80% проектов. Если обратиться к независимому мнению, то процессы SCA являются отдельной практикой OWASP SAMM и BSIMM в качестве показателя зрелости, а в первой половине 2020 года OWASP выпустила новый стандарт OWASP Software Component Verification Standard (SCVS), предоставляющий лучшие практики по проверке сторонних компонент в цепочке поставок ПО.

Один из самых показательных кейсов произошел с компанией Equifax в мае 2017 года. Неизвестные злоумышленники завладели информацией о 143 млн. американцев, включая полные имена, адреса, номера социального страхования и водительских удостоверений. В 209 000 случаях в документах также фигурировала информация о банковских картах пострадавших. Данная утечка произошла в следствие эксплуатации критической уязвимости в Apache Struts 2 (CVE-2017-5638), в то время как исправление было выпущено еще в марте 2017 года. У компании было два месяца на установку обновления, однако этим никто не озаботился.

В данной статье будет обсуждаться вопрос выбора инструмента для проведения SCA с точки зрения качества результатов анализа. Также будет приведено функциональное сравнение инструментов. Процесс встраивания в CI/CD и возможности по интеграции оставим на последующие публикации. Широкий список инструментов был представлен OWASP на своем сайте, но в рамках текущего обзора мы коснемся только самого популярного open source инструмента Dependency Check, чуть менее известной open source платформы Dependency Track и Enterprise-решения Sonatype Nexus IQ. Также разберемся, как работают эти решения и сравним полученные результаты на предмет ложных срабатываний.

Принцип работы

Dependency Check — это утилита (CLI, maven, jenkins модуль, ant), которая анализирует файлы проекта, собирает фрагменты информации о зависимостях (package name, groupid, specification title, version…), строит строку CPE — (Common Platform Enumeration), Package URL (PURL) и выявляет для CPE/PURL уязвимости из баз данных (NVD, Sonatype OSS Index, NPM Audit API…), после чего строит единоразовый отчет в формате HTML, JSON, XML…

Рассмотрим, как выглядит CPE:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

Part: Указание о том, что компонент относится к приложению (a), операционной системе (o), железу (h) (Обязательный пункт)
Vendor: Название производителя продукта (Обязательный пункт)
Product: Название продукта (Обязательный пункт)
Version: Версия компоненты (Устаревший пункт)
Update: Обновление пакета
Edition: Наследуемая версия (Устаревший пункт)
Language: Язык, определяемый в RFC-5646
SW Edition: Версия ПО
Target SW: Программная среда, в которой работает продукт
Target HW: Аппаратная среда, в которой работает продукт
Other: Информация о поставщике или продукте

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

Строка означает, что CPE версии 2.3 описывает компонент приложения от производителя pivotal_software с названием spring_framework версии 3.0.0. Если мы откроем уязвимость CVE-2014-0225 в NVD, то можем увидеть упоминание этой CPE. Первая проблема, на которую сразу стоит обратить внимание — CVE в NVD, согласно CPE, сообщает о наличии проблемы во фреймворке, а не в конкретной компоненте. То есть, если разработчики плотно завязаны на фреймворк, а выявленная уязвимость не касается тех модулей, которые используют разработчики, специалисту по безопасности так или иначе придется разбирать данную CVE и задумываться об обновлении.

URL-адрес также используется инструментами SCA. Формат URL-адреса пакета следующий:

scheme:type/namespace/name@version?qualifiers#subpath

Sсheme: Всегда будет ‘pkg’, указывающий, что это URL-адрес пакета (Обязательный пункт)
Type: «Тип» пакета или «протокол» пакета, например maven, npm, nuget, gem, pypi и т.д. (Обязательный пункт)
Namespace: Некоторый префикс имени, такой как идентификатор группы Maven, владелец образа Docker, пользователь или организация GitHub. Необязательный и зависит от типа.
Name: Имя пакета (Обязательный пункт)
Version: Версия пакета
Qualifiers: Дополнительные квалификационные данные для пакета, такие как ОС, архитектура, дистрибутив и т. Д. Необязательный и зависящий от типа пункт.
Subpath: Дополнительный путь в пакете относительно корня пакета

pkg:golang/google.golang.org/genproto#googleapis/api/annotations pkg:maven/org.apache.commons/io@1.3.4 pkg:pypi/django-package@1.11.1.dev1

Dependency Track — on-premise веб-платформа, которая принимает готовые Bill of Materials (BOM) сформированные CycloneDX и SPDX, то есть готовые спецификации об имеющихся зависимостях. Это XML-файл с описанием зависимостей — name, hashes, package url, publisher, license. Далее Dependency Track разбирает BOM, смотрит имеющиеся к выявленным зависимостям CVE из базы данных уязвимостей (NVD, Sonatype OSS Index …), после чего строит графики, вычисляет метрики, регулярно обновляя данные о статусе уязвимости компонент.

Пример того, как может выглядеть BOM в формате XML:

    Apache org.apache.tomcat tomcat-catalina 9.0.14 3942447fac867ae5cdb3229b658f4d48 e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282   Apache-2.0   pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14

BOM может использоваться не только в качестве входных параметров для Dependency Track, но и для инвентаризации компонентов ПО в цепочке поставок, например, для предоставления заказчику ПО. В 2014 году на рассмотрение в США был даже предложен закон «Cyber Supply Chain Management and Transparency Act of 2014», который гласил, что при закупке ПО любое гос. учреждение должно запрашивать BOM для предотвращения использования уязвимых компонент, однако в силу акт так и не вступил.

Возвращаясь к SCA, у Dependency Track есть готовые интеграции с Notification Platforms вроде Slack, системами управления уязвимостями вроде Kenna Security. Стоит также сказать, что Dependency Track ко всему прочему выявляет устаревшие версии пакетов и предоставляет информацию о лицензиях (за счет поддержки SPDX).

Если говорить именно о качестве SCA, то здесь есть принципиальная разница.

Dependency Track не принимает проект в качестве входных данных, а принимает именно BOM. Это означает, что если мы захотим проверить проект, то сначала нам нужно сгенерировать bom.xml, например, с помощью CycloneDX. Таким образом, Dependency Track напрямую зависит от CycloneDX. В то же время, это дает возможность кастомизации. Так команда OZON написала модуль CycloneDX для сборки BOM-файлов для проектов на Golang с целью дальнейшего сканирования через Dependency Track.

Nexus IQ — коммерческое решение SCA от компании Sonatype, которое является частью экосистемы Sonatype, куда также входит Nexus Repository Manager. Nexus IQ может принимать в качестве входных данных как war архивы (для java проектов) через веб-интерфейс или API, так и BOM, если ваша организация не успела перестроиться с CycloneDX на новое решение. В отличие от open source решений, IQ обращается не только к CPE/PURL к выявленной компоненте и соответствующей уязвимости в базе данных, но и учитывает собственные исследования, например, название уязвимой функции или класса. Механизмы IQ будут рассмотрены позднее при разборе результатов.

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

Язык	Nexus IQ	Dependency Check	Dependency Track
Java	+	+	+
C/C++	+	+	—
C#	+	+	—
.Net	+	+	+
Erlang	—	—	+
JavaScript (NodeJS)	+	+	+
PHP	+	+	+
Python	+	+	+
Ruby	+	+	+
Perl	—	—	—
Scala	+	+	+
Objective C	+	+	—
Swift	+	+	—
R	+	—	—
Go	+	+	+

Функциональные возможности	Nexus IQ	Dependency Check	Dependency Track
Возможность обеспечивать проверку компонент, используемых в исходном коде на лицензионную чистоту	+	—	+
Возможность сканирования и анализа на наличие уязвимостей и лицензионной чистоты для образов Docker	+ Интеграция с Clair	—	—
Возможность настройки политики безопасности для использования библиотек с открытым исходным кодом	+	—	—
Возможность сканирования репозиториев с открытым исходным кодом на наличие уязвимых компонентов	+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS	—	+ Hex, RubyGems, Maven, NPM, Nuget, Pypi
Наличие специализированной исследовательской группы	+	—	—
Работа в закрытом контуре	+	+	+
Использование сторонних баз данных	+ Закрытая БД Sonatype	+ Sonatype OSS, NPM Public Advisors	+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, поддержка собственной БД уязвимостей
Возможность фильтровать компоненты с открытым исходным кодом при попытке загрузки в контур разработки согласно сконфигурированным политикам	+	—	—
Рекомендации по исправлению уязвимостей, наличие ссылок на исправление	+	+- (зависит от описания в публичных базах)	+- (зависит от описания в публичных базах)
Ранжирование обнаруженных уязвимостей по степени критичности	+	+	+
Ролевая модель доступа	+	—	+
Поддержка интерфейса командной строки CLI	+	+	+- (только для CycloneDX)
Выборка / сортировка уязвимостей по определяемым критериям	+	—	+
Dashboard по состоянию приложений	+	—	+
Генерация отчётов в PDF-формате	+	—	—
Генерация отчётов в формате JSON\CSV	+	+	—
Поддержка русского языка	—	—	—

Интеграционные возможности

Интеграция	Nexus IQ	Dependency Check	Dependency Track
Интеграция с LDAP/Active Directory	+	—	+
Интеграция с системой непрерывной интеграции (continous integration) Bamboo	+	—	—
Интеграция с системой непрерывной интеграции (continous integration) TeamCity	+	—	—
Интеграция с системой непрерывной интеграции (continous integration) GitLab	+	+- (в виде плагина для GitLab)	+
Интеграция с системой непрерывной интеграции (continous integration) Jenkins	+	+	+
Наличие плагинов к IDE	+ IntelliJ, Eclipse, Visual Studio	—	—
Поддержка кастомизированной интеграции через web-services (API) инструмента	+	—	+

Dependency Check

Первый запуск

Запустим Dependency Check к умышленно уязвимому приложению DVJA.

mvn org.owasp:dependency-check-maven:check

В результате в директории target появится dependency-check-report.html.

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

Следом идет более подробная информация, в частности то, на основе чего было принято решение (evidence), то есть некий BOM.

Далее идет CPE, PURL и описание CVE. Рекомендации об исправлении кстати не прилагаются в силу отсутствия их в базе NVD.

Для систематичного просмотра результатов сканирования можно настроить Nginx с минимальными настройками, либо отправлять полученные дефекты в систему управления дефектами, которые поддерживают конекторы к Dependency Check. Например, Defect Dojo.

Dependency Track

Установка

Dependency Track, в свою очередь, является веб-платформой с отображающими графиками, поэтому острый вопрос о хранении дефектов в стороннем решении здесь не стоит.
Для установки есть следующие поддерживаемые сценарии: Docker, WAR, Executable WAR.

Первый запуск

Переходим по URL запущенного сервиса. Входим через admin/admin, меняем логин и пароль, после чего попадаем на Dashboard. Следующее, что мы сделаем — создадим проект для тестового приложения на Java в Home/Projects → Create Project . В качестве примера возьмем DVJA.

Так как Dependency Track может принимать в качестве входных данных только BOM, этот BOM необходимо получить. Воспользуемся CycloneDX Maven Plugin:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Получаем bom.xml и загружаем файл в созданном проекте DVJA → Dependeencies → Upload BOM.

Зайдем в Administration → Analyzers. Понимаем, что у нас включен только Internal Analyzer, включающий NVD. Подключим также Sonatype OSS Index.

Таким образом, получим следующую картину для нашего проекта:

Также в списке можно найти одну уязвимость, применимую к Sonatype OSS:

Основное разочарование было в том, что Dependency Track больше не принимает xml-отчеты Dependency Check. Последние поддерживаемые версии интеграции с Dependency Check были 1.0.0 — 4.0.2, в то время как я тестировал 5.3.2.

Вот видео (и вот), когда это было еще возможно.

Nexus IQ

Первый запуск

Установка Nexus IQ происходит из архивов по документации, но мы для этих целей собрали себе образ Docker.

После входа в консоль необходимо создать Организацию и Приложение.

Как можно видеть, настройка в случае с IQ происходит несколько сложнее, ибо нам также необходимо создать политики, применимые для разных “стейджей” (dev, build, stage, release). Это необходимо, чтобы блокировать уязвимые компоненты по мере продвижения по пайплайну ближе к проду, либо блокировать как только они попадают в Nexus Repo при скачивании разработчиками.

Чтобы ощутить разницу open source и enterprise, выполним такое же сканирование через Nexus IQ аналогично через Maven plugin, предварительно создав тестовое приложение в интерфейсе NexusIQ dvja-test-and-compare :

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl= -Dclm.username= -Dclm.password=

Переходим по URL к сгенерированному отчету в веб-интерфейсе IQ:

Здесь можно увидеть все нарушения политики с указанием разного уровня значимости (от Info до Security Critical). Буква D рядом с компонентой означает, что компонента Direct Dependency, а буква T рядом с компонентом означает, что компонента Transitive Dependency, то есть является транзитивной.

Кстати, отчет State of Open Source Security Report 2020 от Snyk сообщает, что более 70% уязвимостей open source обнаруженных в Node.js, Java и Ruby находятся в транзитивных зависимостях.

Если открыть одно из нарушений политики Nexus IQ, мы можем увидеть описание компоненты, а также Version Graph, который показывает местоположение текущей версии на временном графе, а также в какой момент уязвимость перестает быть уязвимой. Высота свечей на графе показывает популярность использования этой компоненты.

Если перейти в раздел уязвимостей и раскрыть CVE, то можно прочитать описание к этой уязвимости, рекомендации по устранению, а также причину, по которой данная компонента попала под нарушение, то есть наличие класса DiskFileitem.class .

Подведем итоги только касающиеся сторонних компонентов Java, убрав компоненты js. В скобках укажем число тех уязвимостей, которые были найдены за пределами NVD.

Итого Nexus IQ:

Dependencies Scanned: 62
Vulnerable Dependencies: 16
Vulnerabilities Found: 42 (8 sonatype db)

Dependencies Scanned: 47
Vulnerable Dependencies: 13
Vulnerabilities Found: 91 (14 sonatype oss)

Dependencies Scanned: 59
Vulnerable Dependencies: 10
Vulnerabilities Found: 51 (1 sonatype oss)

Дисклеймер

Данное ревью не является неоспоримой истиной. Перед автором не стояло цели выделить отдельный инструмент на фоне других. Смысл ревью был показать механизмы работы инструментов SCA и способы проверки их результатов.

Сравнение результатов

Ложным срабатыванием по отношению к уязвимостям сторонних компонентов является:

Несоответствие CVE к выявленной компоненте
Например, если уязвимость выявлена во фреймворке struts2, а инструмент указывает на компоненту фреймворка struts-tiles, к которой эта уязвимость не относится, то это false positive
Несоответствие CVE к выявленной версии компоненты
Например, уязвимость привязана к версии python > 3.5 и инструмент отмечает уязвимой версию 2.7 — это false positive, так как на самом деле уязвимость относится только к ветке продукта 3.x
Дублирование CVE
Например, если SCA указал на CVE, позволяющую реализовать RCE, после чего SCA указывает для этой же компоненты CVE, применимую к продуктам Cisco, подверженным этой RCE. В таком случае будет false positive.
Например, CVE была найдена в компоненте spring-web, после чего SCA указывает на эту же CVE в других компонентах фреймворка Spring Framework, в то время как CVE к другим компонентам отношения не имеет. В таком случае будет false positive.

Сводные результаты

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

Сводные результаты по всем уязвимостям:

Параметр	Nexus IQ	Dependency Check	Dependency Track
Всего выявлено уязвимостей	42	91	51
Неверно выявлено уязвимостей (false positive)	2(4.76%)	62(68,13%)	29(56.86%)
Не обнаружено релевантных уязвимостей (false negative)	10	20	27

Сводные результаты по компонентам:

Параметр	Nexus IQ	Dependency Check	Dependency Track
Всего выявлено компонентов	62	47	59
Всего уязвимых компонентов	16	13	10
Неверно выявлены уязвимые компоненты (false positive)	1	5	0
Неверно выявлены уязвимые компоненты (false positive)	0	6	6

Построим визуальные графики, чтобы оценить соотношение false positive и false negative к общему числу уязвимостей. По горизонтали отмечены компоненты, а по вертикали выявленные в них уязвимости.

Для сравнения, аналогичное исследование было проведено командой Sonatype по тестированию проекта из 1531 компоненты с помощью OWASP Dependency Check. Как мы можем увидеть, соотношение шума к корректным срабатываниям соезмиримо с нашими результатами.

Источник: www.sonatype.com/why-precision-matters-ebook

Рассмотрим некоторые CVE из результатов нашего сканирования, чтобы понять причину таких результатов.

Подробнее

№1

Разберем сначала некоторые интересные моменты Sonatype Nexus IQ.

Nexus IQ указывает на проблему с десереализацией с возможностью выполнить RCE в Spring Framework несколько раз. CVE-2016-1000027 в spring-web:3.0.5 в первый раз, и CVE-2011-2894 в spring-context:3.0.5 и spring-core:3.0.5. Поначалу кажется, что происходит дублирование уязвимости по нескольким CVE. Ибо, если посмотреть CVE-2016-1000027 и CVE-2011-2894 в базе NVD, то кажется, что все очевидно

Компонент	Уязвимость
spring-web:3.0.5	CVE-2016-1000027
spring-context:3.0.5	CVE-2011-2894
spring-core:3.0.5	CVE-2011-2894

Описание CVE-2011-2894 из NVD:

Описание CVE-2016-1000027 из NVD:

CVE-2011-2894 сама по себе довольно известная. В отчете White Source за 2011 год эта CVE была признана одной из самых часто встречающихся. Описания для CVE-2016-100027 в принципе немного в NVD, да и применима она, вроде бы, только для Spring Framework 4.1.4. Взглянем на reference и тут становится все более или менее понятно. Из статьи Tenable мы понимаем, что помимо уязвимости в RemoteInvocationSerializingExporter в CVE-2011-2894, уязвимость наблюдается в HttpInvokerServiceExporter . Об этом нам и говорит Nexus IQ:

Тем не менее ничего подобного нет в NVD, из-за чего Dependency Check и Dependency Track получают по false negative.

Также из описания CVE-2011-2894 можно понять, что уязвимость действительно присутствует и в spring-context:3.0.5 и в spring-core:3.0.5. Подтверждение этому можно найти в статье от того, кто эту уязвимость нашел.

№2

Компонент	Уязвимость	Результат
struts2-core:2.3.30	CVE-2016-4003	FALSE

Если мы изучим уязвимость CVE-2016-4003, то поймем, что ее исправили еще в версии 2.3.28, тем не менее Nexus IQ нам о ней сообщает. В описании к уязвимости есть примечание:

То есть уязвимость существует только в связке с устаревшей версией JRE, о чем нас решили предупредить. Тем не менее, считаем это False Positive, хоть и не самым страшным.

№ 3

Компонент	Уязвимость	Результат
xwork-core:2.3.30	CVE-2017-9804	TRUE
xwork-core:2.3.30	CVE-2017-7672	FALSE

Если мы посмотрим описание к CVE-2017-9804 и CVE-2017-7672, то поймем, что проблема в URLValidator class , причем CVE-2017-9804 вытекает из CVE-2017-7672. Наличие второй уязвимости не несет никакой полезной нагрузки кроме того, что ее severity вырос до High, поэтому можно считать это лишним шумом.

В целом других false positive для Nexus IQ найдено не было.

№4

Есть несколько моментов, которые выделяют IQ на фоне других решений.

Компонент	Уязвимость	Результат
spring-web:3.0.5	CVE-2020-5398	TRUE

CVE в NVD сообщает, что она применима только для версий 5.2.x до 5.2.3, 5.1.x до 5.1.13, и версий 5.0.x до 5.0.16, тем не менее, если мы посмотрим описание CVE в Nexus IQ, то увидим следующее:
Advisory Deviation Notice: The Sonatype security research team discovered that this vulnerability was introduced in version 3.0.2.RELEASE and not 5.0.x as stated in the advisory.

После этого следует PoC к этой уязвимости, который сообщает, что она присутствует в версии 3.0.5.

False negative отправляется к Dependency Check и Dependency Track.

№5

Посмотрим на false positive для Dependency Check и Dependency Track.

Dependency Check отдельно выделяется тем, что отражает те CVE, которые относятся ко всему фреймворку в NVD, в те компоненты, к которым эти CVE не применимы. Это касается CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, которые Dependency Check “прикрутил” к struts-taglib:1.3.8 и struts-tiles-1.3.8. Эти компоненты не имеют ничего общего с тем, что описано в CVE — обработка запросов, валидация страниц и так далее. Это обусловлено тем, что общее между этими CVE и компонентами — только фреймворк, из-за чего Dependency Check и посчитал это уязвимостью.

Такая же ситуация с spring-tx:3.0.5, и похожая ситуация с struts-core:1.3.8. Для struts-core Dependency Check и Dependency Track нашли очень много уязвимостей, которые на самом деле применимы к struts2-core, который по сути является отдельным фреймворком. В данном случае Nexus IQ правильно понял картину и в тех CVE, которые выдал, указал, что struts-core пришел end of life и необходимо перейти к struts2-core.

№6

В некоторых ситуациях трактовать явную ошибку Dependency Check и Dependency Track несправедливо. В частности CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, которые Dependency Check и Dependency Track отнесли к spring-core:3.0.5 на самом деле относятся к spring-web:3.0.5. При этом часть из этих CVE были найдены и Nexus IQ, тем не менее IQ их корректно определил к другой компоненте. От того, что эти уязвимости не были найдены в spring-core, нельзя утверждать, что их нет во фреймворке в принципе и open source инструменты справедливо указали на эти уязвимости (просто немного промахнулись).

Выводы

Как мы можем видеть, определение достоверности выявленных уязвимостей ручным ревью не дает однозначных результатов, из-за чего возникают спорные моменты. Результаты таковы, что решение Nexus IQ обладает наименьшим показателем ложных срабатываний и наибольшей точностью.

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

Немаловажное влияние на результаты играют и те уязвимости, которые не попали в NVD, но тем не менее присутствуют в базе Sonatype с пометкой SONATYPE. Согласно отчету The State of Open Source Security Vulnerabilities 2020 о 45% обнаруженных уязвимостей с открытым исходным кодом не сообщается в NVD. Согласно базе данных WhiteSource, только 29% всех уязвимостей с открытым исходным кодом, зарегистрированных за пределами NVD, в конечном итоге публикуются в ней, поэтому так важно искать уязвимости также в других источниках.

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

Тем не менее, практика показывает, что именно open source должен становится первым шагов на пути к зрелому DevSecOps. Первое, над чем стоит задуматься для встраивания SCA в разработку, — это процессы, а именно размышления совместно с руководством и смежными департаментами над тем, как должны выглядеть идеальные процессы у себя в организации. Возможно, окажется так, что для вашей организации на первых порах Dependency Check или Dependency Track закроют все стоящие перед бизнесом потребности, а Enterprise-решения будут являться логическим продолжением в силу роста сложности разрабатываемых приложений.

Приложение А. Результаты применительно к компонентам

Условные обозначения:

High — уязвимости высокого и критичного уровня в компоненте
Medium — Уязвимости среднего уровня критичности в компоненте
TRUE — Верно определенная уязвимость (True positive issue)
FALSE — Ложное срабатывание (False positive issue)

Компонент	Nexus IQ	Dependency Check	Dependency Track	Результат
dom4j: 1.6.1	High	High	High	TRUE
log4j-core: 2.3	High	High	High	TRUE
log4j: 1.2.14	High	High	—	TRUE
commons-collections:3.1	High	High	High	TRUE
commons-fileupload:1.3.2	High	High	High	TRUE
commons-beanutils:1.7.0	High	High	High	TRUE
commons-codec:1:10	Medium	—	—	TRUE
mysql-connector-java:5.1.42	High	High	High	TRUE
spring-expression:3.0.5	High	компонент не найден	TRUE
spring-web:3.0.5	High	компонент не найден	High	TRUE
spring-context:3.0.5	Medium	компонент не найден	—	TRUE
spring-core:3.0.5	Medium	High	High	TRUE
struts2-config-browser-plugin:2.3.30	Medium	—	—	TRUE
spring-tx:3.0.5	—	High	—	FALSE
struts-core:1.3.8	High	High	High	TRUE
xwork-core: 2.3.30	High	—	—	TRUE
struts2-core: 2.3.30	High	High	High	TRUE
struts-taglib:1.3.8	—	High	—	FALSE
struts-tiles-1.3.8	—	High	—	FALSE

Приложение Б. Результаты применительно к уязвимостям

Условные обозначения:

High — уязвимости высокого и критичного уровня в компоненте
Medium — Уязвимости среднего уровня критичности в компоненте
TRUE — Верно определенная уязвимость (True positive issue)
FALSE — Ложное срабатывание (False positive issue)

Компонент	Nexus IQ	Dependency Check	Dependency Track	Severity	Результат	Комментарий
dom4j: 1.6.1	CVE-2018-1000632	CVE-2018-1000632	CVE-2018-1000632	High	TRUE
CVE-2020-10683	CVE-2020-10683	CVE-2020-10683	High	TRUE
log4j-core: 2.3	CVE-2017-5645	CVE-2017-5645	CVE-2017-5645	High	TRUE
CVE-2020-9488	CVE-2020-9488	CVE-2020-9488	Low	TRUE
log4j: 1.2.14	CVE-2019-17571	CVE-2019-17571	—	High	TRUE
—	CVE-2020-9488	—	Low	TRUE
SONATYPE-2010-0053	—	—	High	TRUE
commons-collections:3.1	—	CVE-2015-6420	CVE-2015-6420	High	FALSE	Дублирует RCE(OSSINDEX)
—	CVE-2017-15708	CVE-2017-15708	High	FALSE	Дублирует RCE(OSSINDEX)
SONATYPE-2015-0002	RCE (OSSINDEX)	RCE(OSSINDEX)	High	TRUE
commons-fileupload:1.3.2	CVE-2016-1000031	CVE-2016-1000031	CVE-2016-1000031	High	TRUE
SONATYPE-2014-0173	—	—	Medium	TRUE
commons-beanutils:1.7.0	CVE-2014-0114	CVE-2014-0114	CVE-2014-0114	High	TRUE
—	CVE-2019-10086	CVE-2019-10086	High	FALSE	Уязвимость применима только для версий 1.9.2+
commons-codec:1:10	SONATYPE-2012-0050	—	—	Medium	TRUE
mysql-connector-java:5.1.42	CVE-2018-3258	CVE-2018-3258	CVE-2018-3258	High	TRUE
CVE-2019-2692	CVE-2019-2692	—	Medium	TRUE
—	CVE-2020-2875	—	Medium	FALSE	Та же самая уязвимость как и CVE-2019-2692, но c припиской «attacks may significantly impact additional products»
—	CVE-2017-15945	—	High	FALSE	Не относится к mysql-connector-java
—	CVE-2020-2933	—	Low	FALSE	Дубликат к CVE-2020-2934
CVE-2020-2934	CVE-2020-2934	—	Medium	TRUE
spring-expression:3.0.5	CVE-2018-1270	компонент не найден	—	High	TRUE
CVE-2018-1257	—	—	Medium	TRUE
spring-web:3.0.5	CVE-2016-1000027	компонент не найден	—	High	TRUE
CVE-2014-0225	—	CVE-2014-0225	High	TRUE
CVE-2011-2730	—	—	High	TRUE
—	—	CVE-2013-4152	Medium	TRUE
CVE-2018-1272	—	—	High	TRUE
CVE-2020-5398	—	—	High	TRUE	Показательный пример в пользу IQ: «The Sonatype security research team discovered that this vulnerability was introduced in version 3.0.2.RELEASE and not 5.0.x as stated in the advisory.»
CVE-2013-6429	—	—	Medium	TRUE
CVE-2014-0054	—	CVE-2014-0054	Medium	TRUE
CVE-2013-6430	—	—	Medium	TRUE
spring-context:3.0.5	CVE-2011-2894	компонент не найден	—	Medium	TRUE
spring-core:3.0.5	—	CVE-2011-2730	CVE-2011-2730	High	TRUE
CVE-2011-2894	CVE-2011-2894	CVE-2011-2894	Medium	TRUE
—	—	CVE-2013-4152	Medium	FALSE	Дубликат этой же уязвимости в spring-web
—	CVE-2013-4152	—	Medium	FALSE	Уязвимость относится к компоненте spring-web
—	CVE-2013-6429	CVE-2013-6429	Medium	FALSE	Уязвимость относится к компоненте spring-web
—	CVE-2013-6430	—	Medium	FALSE	Уязвимость относится к компоненте spring-web
—	CVE-2013-7315	CVE-2013-7315	Medium	FALSE	SPLIT из CVE-2013-4152. + Уязвимость относится к компоненте spring-web
—	CVE-2014-0054	CVE-2014-0054	Medium	FALSE	Уязвимость относится к компоненте spring-web
—	CVE-2014-0225	—	High	FALSE	Уязвимость относится к компоненте spring-web
—	—	CVE-2014-0225	High	FALSE	Дубликат этой же уязвимости в spring-web
—	CVE-2014-1904	CVE-2014-1904	Medium	FALSE	Уязвимость относится к компоненте spring-web-mvc
—	CVE-2014-3625	CVE-2014-3625	Medium	FALSE	Уязвимость относится к компоненте spring-web-mvc
—	CVE-2016-9878	CVE-2016-9878	High	FALSE	Уязвимость относится к компоненте spring-web-mvc
—	CVE-2018-1270	CVE-2018-1270	High	FALSE	Для spring-expression / spring-messages
—	CVE-2018-1271	CVE-2018-1271	Medium	FALSE	Уязвимость относится к компоненте spring-web-mvc
—	CVE-2018-1272	CVE-2018-1272	High	TRUE
CVE-2014-3578	CVE-2014-3578 (OSSINDEX)	CVE-2014-3578	Medium	TRUE
SONATYPE-2015-0327	—	—	Low	TRUE
struts2-config-browser-plugin:2.3.30	SONATYPE-2016-0104	—	—	Medium	TRUE
spring-tx:3.0.5	—	CVE-2011-2730	—	High	FALSE	Уязвимость не относится к spring-tx
—	CVE-2011-2894	—	High	FALSE	Уязвимость не относится к spring-tx
—	CVE-2013-4152	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2013-6429	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2013-6430	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2013-7315	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2014-0054	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2014-0225	—	High	FALSE	Уязвимость не относится к spring-tx
—	CVE-2014-1904	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2014-3625	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2016-9878	—	High	FALSE	Уязвимость не относится к spring-tx
—	CVE-2018-1270	—	High	FALSE	Уязвимость не относится к spring-tx
—	CVE-2018-1271	—	Medium	FALSE	Уязвимость не относится к spring-tx
—	CVE-2018-1272	—	Medium	FALSE	Уязвимость не относится к spring-tx
struts-core:1.3.8	—	CVE-2011-5057 (OSSINDEX)	Medium	FASLE	Уязвимость к Struts 2
—	CVE-2012-0391 (OSSINDEX)	CVE-2012-0391	High	FALSE	Уязвимость к Struts 2
—	CVE-2014-0094 (OSSINDEX)	CVE-2014-0094	Medium	FALSE	Уязвимость к Struts 2
—	CVE-2014-0113 (OSSINDEX)	CVE-2014-0113	High	FALSE	Уязвимость к Struts 2
CVE-2016-1182	3VE-2016-1182	—	High	TRUE
—	—	CVE-2011-5057	Medium	FALSE	Уязвимость к Struts 2
—	CVE-2012-0392 (OSSINDEX)	CVE-2012-0392	High	FALSE	Уязвимость к Struts 2
—	CVE-2012-0393 (OSSINDEX)	CVE-2012-0393	Medium	FALSE	Уязвимость к Struts 2
CVE-2015-0899	CVE-2015-0899	—	High	TRUE
—	CVE-2012-0394	CVE-2012-0394	Medium	FALSE	Уязвимость к Struts 2
—	CVE-2012-0838 (OSSINDEX)	CVE-2012-0838	High	FALSE	Уязвимость к Struts 2
—	CVE-2013-1965 (OSSINDEX)	CVE-2013-1965	High	FALSE	Уязвимость к Struts 2
—	CVE-2013-1966 (OSSINDEX)	CVE-2013-1966	High	FASLE	Уязвимость к Struts 2
—	CVE-2013-2115	CVE-2013-2115	High	FASLE	Уязвимость к Struts 2
—	CVE-2013-2134 (OSSINDEX)	CVE-2013-2134	High	FASLE	Уязвимость к Struts 2
—	CVE-2013-2135 (OSSINDEX)	CVE-2013-2135	High	FASLE	Уязвимость к Struts 2
CVE-2014-0114	CVE-2014-0114	—	High	TRUE
—	CVE-2015-2992	CVE-2015-2992	Medium	FALSE	Уязвимость к Struts 2
—	CVE-2016-0785 (OSSINDEX)	CVE-2016-0785	High	FALSE	Уязвимость к Struts 2
CVE-2016-1181	CVE-2016-1181	—	High	TRUE
—	CVE-2016-4003 (OSSINDEX)	CVE-2016-4003	High	FALSE	Уязвимость к Struts 2
xwork-core:2.3.30	CVE-2017-9804	—	—	High	TRUE
SONATYPE-2017-0173	—	—	High	TRUE
CVE-2017-7672	—	—	High	FALSE	Дубль к CVE-2017-9804
SONATYPE-2016-0127	—	—	High	TRUE
struts2-core:2.3.30	—	CVE-2016-6795	CVE-2016-6795	High	TRUE
—	CVE-2017-9787	CVE-2017-9787	High	TRUE
—	CVE-2017-9791	CVE-2017-9791	High	TRUE
—	CVE-2017-9793	—	High	FALSE	Дубликат к CVE-2018-1327
—	CVE-2017-9804	—	High	TRUE
—	CVE-2017-9805	CVE-2017-9805	High	TRUE
CVE-2016-4003	—	—	Medium	FALSE	Применимо к Apache Struts 2.x до 2.3.28, а это версия 2.3.30. Тем не менее, исходя из описания, CVE действует при любых версиях Struts 2, если используется JRE 1.7 и меньше. Видимо нас тут решили перестраховать, но больше похоже на FALSE
—	CVE-2018-1327	CVE-2018-1327	High	TRUE
CVE-2017-5638	CVE-2017-5638	CVE-2017-5638	High	TRUE	Та самая уязвимость, которой воспользовались злоумышленники в Equifax в 2017 году
CVE-2017-12611	CVE-2017-12611	—	High	TRUE
CVE-2018-11776	CVE-2018-11776	CVE-2018-11776	High	TRUE
struts-taglib:1.3.8	—	CVE-2012-0394	—	Medium	FALSE	Для struts2-core
—	CVE-2013-2115	—	High	FALSE	Для struts2-core
—	CVE-2014-0114	—	High	FALSE	Для commons-beanutils
—	CVE-2015-0899	—	High	FALSE	Не относится к taglib
—	CVE-2015-2992	—	Medium	FALSE	Относится к struts2-core
—	CVE-2016-1181	—	High	FALSE	Не относится к taglib
—	CVE-2016-1182	—	High	FALSE	Не относится к taglib
struts-tiles-1.3.8	—	CVE-2012-0394	—	Medium	FALSE	Для struts2-core
—	CVE-2013-2115	—	High	FALSE	Для struts2-core
—	CVE-2014-0114	—	High	FALSE	Под commons-beanutils
—	CVE-2015-0899	—	High	FALSE	Не относится к tiles
—	CVE-2015-2992	—	Medium	FALSE	Для struts2-core
—	CVE-2016-1181	—	High	FALSE	Не относится к taglib
—	CVE-2016-1182	—	High	FALSE	Не относится к taglib

Блог компании Swordfish Security
Информационная безопасность
Веб-разработка
Разработка мобильных приложений
DevOps

Что такое sca

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

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

Что такое SCA

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

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

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

Gartner советует

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

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

Обзор рынка инструментов SCA (Software Composition Analysis)

Введение

Принципы работы SCA

Почему важен анализ компонентов программного обеспечения (SCA)?

Задачи инструментов SCA

Особенности подбора и использования SCA

Мировой рынок систем SCA

Российский рынок систем SCA

Обзор мирового рынка SCA 2022

Black Duck

CAST Highlight

CodeScoring

Debricked

FOSSA

GitLab

Mend

ShiftLeft

Snyk

Sonatype Nexus Lifecycle

WhiteHat Sentinel

Выводы

Specialty Coffee Association (SCA): организация, которая развивает индустрию

Что такое SCA

Как Ассоциация развивает знания о спешелти кофе

Какие направления обучения разработала Ассоциация

Как Ассоциация продвигает спешелти кофе

Что даёт членство в SCA

Нужно ли вступать в SCA? Подведём итоги

DevSecOps: принципы работы и сравнение SCA. Часть первая

Принцип работы

Dependency Check

Первый запуск

Dependency Track

Установка

Первый запуск

Nexus IQ

Первый запуск

Дисклеймер

Сравнение результатов

Сводные результаты

Подробнее

№1

№2

№ 3

№4

№5

№6

Выводы

Добавить комментарий Отменить ответ