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

Значението на анализа на софтуерни компоненти от трети страни (на англ. Software Composition Analysis — SCA) в процеса на разработка нараства с публикуването на ежегодните отчети за уязвимостите в open source библиотеките от компании като Synopsys, Sonatype, Snyk, White Source. Според отчета Състояние на уязвимостите в open source сигурността 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), която анализира файлове на проекта, събира фрагменти информация за зависимости (име на пакет, groupid, заглавие на спецификация, версия …), изгражда 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

• Част: Указание, че компонентът принадлежи на приложение (a), операционна система (o), хардуер (h) (задължителен елемент)
• Производител: Името на производителя на продукта (задължителен елемент)
• Продукт: Името на продукта (задължителен елемент)
• Version: Версия на компонента (остарял елемент)
• Актуализация: Обновление на пакета
• Издание: Наследена версия (остарял елемент)
• Език: Език, определен в RFC-5646
• SW Издание: Версия на софтуера
• Целеви SW: Програмна среда, в която работи продуктът
• Целеви HW: Хардуерна среда, в която работи продуктът
• Друго: Информация за доставчика или продукта

Пример CPE изглежда по следния начин:

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

• Схема: Винаги ще бъде ‘pkg’, указващ, че това е URL адрес на пакет (задължителен елемент)
• Тип: „Тип“ на пакета или „протокол“ на пакета, например maven, npm, nuget, gem, pypi и т.н. (задължителен елемент)
• Пространство от имена: Някакъв префикс на име, като идентификатор на група Maven, собственик на Docker образ, потребител или организация GitHub. Необязателен и зависи от типа.
• Име: Име на пакета (задължителен елемент)
• Version: Версия на пакета
• Квалификатори: Допълнителни квалификационни данни за пакета, като ОС, архитектура, дистрибуция и т.н. Необязателно и зависящо от типа поле.
• Подпътек: Допълнителен път в пакета относно корена на пакета

Например:

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 — платформа на място, която приема готови списъци на материали (BOM), формирани CycloneDX и SPDX, т.е. готови спецификации за наличните зависимости. Това е XML файл с описание на зависимостите - име, хешове, URL на пакета, издател, лиценз. След това 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 г. в САЩ дори беше предложен закон «Закон за управление и прозрачност на кибернетичната верига на доставки от 2014 г.», който заявява, че при закупуването на софтуер всяко държавно учреждение трябва да изисква BOM, за да предотврати използването на уязвими компоненти, но поради това актът не беше приет.

Връщайки се към SCA, Dependency Track предлага готови интеграции с платформи за уведомяване като 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 не се основава само на CP/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)

Извличане / сортиране на уязвимости по зададени критерии
+
—
+

Дашборд за състоянието на приложенията
+
—
+

Генериране на отчети в PDF формат
+
—
—

Генериране на отчети в JSONCSV формат
+
+
—

Поддръжка на български език
—
—
—

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

Интеграция
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
—
—

Поддръжка на персонализирана интеграция чрез уеб услуги (API) на инструмента
+
—
+

Dependency Check

Първо стартиране

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

За целта ще използваме Dependency Check Maven Plugin:

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

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

Ще отворим файла. След обобщената информация за общия брой уязвимости можем да видим информация за уязвимостите с висок нивото на тежест и увереност с посочване на пакета, CPE, брой CVE.

Следва по-подробна информация, в частност на база на което е било взето решението (доказателство), т.е. някакъв BOM.

На следващо място идват CPE, PURL и описание на CVE. Препоръките за корекция, между другото, не са приложени поради тяхното отсъствие в базата NVD.

За систематично прегледане на резултатите от сканирането можете да настроите Nginx с минимални настройки или да изпращате получените дефекти в система за управление на дефекти, които поддържат конектори към Dependency Check. Например, Defect Dojo.

Dependency Track

Инсталиране

Dependency Track, от своя страна, е уеб платформа с графики, така че остър въпрос относно съхранение на дефекти в трето решение тук не стои.
За инсталация има следните поддържани сценарии: Docker, WAR, Executable WAR.

Първо стартиране

Преминаваме по URL адреса на стартирания сервис. Влизаме с admin/admin, променяме логин и парола, а след това попадаме на дашборда. Следващото, което ще направим, е да създадем проект за тестово приложение на Java в Home/Projects → Create Project . Като пример ще вземем DVJA.

Тъй като Dependency Track може да приема като входни данни само BOM, е необходимо да получим този BOM. Нека използваме CycloneDX Maven Plugin:

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

Получаваме bom.xml и качваме файла в създадения проект DVJA → Dependencies → 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:

• Сканирани зависимости: 62
• Уязвими зависимости: 16
• Намерени уязвимости: 42 (8 sonatype db)

Общо Dependency Check:

• Сканирани зависимости: 47
• Уязвими зависимости: 13
• Намерени уязвимости: 91 (14 sonatype oss)

Общо Dependency Track:

• Сканирани зависимости: 59
• Уязвими зависимости: 10
• Намерени уязвимости: 51 (1 sonatype oss)

Следващата стъпка е да анализираме получените резултати и да разберем кои от тези уязвимости са реални дефекти, а кои лъжливи срабатывания.

Дисклеймер

Този преглед не представлява неоспорима истина. Пред автора не беше поставена целта да се отличи отделен инструмент на фона на другите. Същността на прегледа беше да покаже механизмите на работа на инструментите SCA и начините за проверка на техните резултати.

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

Условия:

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

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

Обект на изследването е избраният Open Source проект DVJA. В изследването участват само java компоненти (без js).

Обобщени резултати

Нека преминем директно към резултатите от ръчното ревю на откритите уязвимости. С пълен отчет за всяка 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, а CVE-2017-9804 произтича от CVE-2017-7672. Наличието на втора уязвимост не носи никаква полезна информация, освен че нейното ниво на опасност е нараснало до 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: Екипът за сигурност на Sonatype откри, че тази уязвимост е въведена в версия 3.0.2.RELEASE, а не в 5.0.x, както е посочено в уведомлението.

След това следва 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 е приключил жизнения си цикъл и е необходимо да се премине към 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. Според доклад Състояние на уязвимостите в open source сигурността 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, но с добавка «атаките могат да засегнат значително допълнителни продукти»

—
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: «Екипът за изследване на сигурността на Sonatype откри, че тази уязвимост е била въведена в версия 3.0.2.RELEASE, а не 5.0.x, както е посочено в уведомлението.»

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

Източник: habr.com