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

Значението на анализа на софтуерните компоненти на трети страни (англ. Software Composition Analysis - SCA) в процеса на разработка нараства с публикуването на годишни доклади за уязвимостите на библиотеки с отворен код, които се публикуват от Synopsys, Sonatype, Snyk, White Source. Според доклада Състоянието на уязвимостите на сигурността с отворен код 2020 г броят на идентифицираните уязвимости в отворен код през 2019 г. се е увеличил с почти 1.5 пъти в сравнение с предходната година, докато компонентите с отворен код се използват от 60% до 80% от проектите. В независимо мнение процесите на SCA са отделна практика от OWASP SAMM и BSIMM като индикатор за зрялост, а през първата половина на 2020 г. OWASP пусна нов стандарт за проверка на софтуерни компоненти на OWASP (SCVS), който предоставя най-добри практики за проверка на трети страни компоненти във веригата за доставки BY.

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

Тази статия ще обсъди въпроса за избора на инструмент за провеждане на SCA по отношение на качеството на резултатите от анализа. Ще бъде направено и функционално сравнение на инструментите. Ще оставим процеса на вграждане в CI / CD и възможностите за интеграция за последващи публикации. Широка гама от инструменти е въведена от OWASP на вашия уебсайт, но като част от настоящия преглед ще се докоснем само до най-популярния инструмент за проверка на зависимостта с отворен код, малко по-малко известната платформа с отворен код Dependency Track и решението Sonatype Nexus IQ Enterprise. Ще разберем също как работят тези решения и ще сравним получените резултати за фалшиви положителни резултати.

Принцип на действие

Проверка на зависимостта е помощна програма (CLI, maven, jenkins module, ant), която анализира файлове на проекта, събира фрагменти от информация за зависимости (име на пакет, groupid, заглавие на спецификация, версия ...), изгражда CPE низ - (Common Platform Enumeration ), 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) (Задължителен елемент)
• Търговец: Име на производителя на продукта (задължителен елемент)
• продукт: Име на продукта (задължително)
• Версия: Версия на компонент (отхвърлен елемент)
• Update: Актуализация на пакета
• Edition: Наследена версия (отхвърлен елемент)
• Език: Език, дефиниран в 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. По желание и зависи от вида.
• Име: Име на пакета (задължително)
• Версия: Версия на пакета
• Квалификации: Допълнителни данни за квалификация за пакета, като операционна система, архитектура, разпространение и т.н. Незадължителен и специфичен за типа елемент.
• подпът: Допълнителен път в пакета спрямо корена на пакета

Например:

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/[email protected]
pkg:pypi/[email protected]

Следа на зависимостта — локална уеб платформа, която приема генерирана готова спецификация на материалите (BOM). CycloneDX и SPDX, тоест готови спецификации за наличните зависимости. Това е XML файл с описание на зависимостите - име, хешове, url на пакета, издател, лиценз. След това Dependency Track анализира BOM, разглежда наличните CVE за идентифицираните зависимости от базата данни за уязвимости (NVD, Sonatype OSS Index ...) и след това изгражда графики, изчислява показатели, като редовно актуализира данните за състоянието на уязвимостта на компонентите. .

Пример за това как може да изглежда BOM в XML формат:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
  <components>
    <component type="library">
      <publisher>Apache</publisher>
      <group>org.apache.tomcat</group>
      <name>tomcat-catalina</name>
      <version>9.0.14</version>
      <hashes>
        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
      </hashes>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/org.apache.tomcat/[email protected]</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

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 може да приеме като вход както военни архиви (за java проекти) чрез уеб интерфейса или API, така и BOM, ако вашата организация не е имала време да премине от CycloneDX към ново решение. За разлика от решенията с отворен код, IQ не само се позовава на CP / PURL на идентифицирания компонент и съответната уязвимост в базата данни, но също така взема предвид собственото си изследване, например името на уязвимата функция или клас. Механизмите на IQ ще бъдат обсъдени по-късно в анализа на резултатите.

Нека обобщим някои от функционалните характеристики и също така да разгледаме поддържаните езици за анализ:

Език
Nexus IQ
Проверка на зависимостта
Следа на зависимостта

Ява
+
+
+

C / C ++
+
+
-

C#
+
+
-

.Net
+
+
+

Ерланг
-
-
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Питон
+
+
+

Рубин
+
+
+

Perl
-
-
-

Scala
+
+
+

Цел В
+
+
-

Swift
+
+
-

R
+
-
-

Go
+
+
+

функционалност

функционалност
Nexus IQ
Проверка на зависимостта
Следа на зависимостта

Способността да се гарантира, че компонентите, използвани в изходния код, са проверени за чистота на лиценза
+
-
+

Възможност за сканиране и анализиране за уязвимости и чистота на лиценза за 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 публични съветници
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, поддръжка на собствена база данни за уязвимости

Възможност за филтриране на компоненти с отворен код при опит за качване в цикъл за разработка според конфигурирани правила
+
-
-

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

Класиране на откритите уязвимости по критичност
+
+
+

Модел на ролеви достъп
+
-
+

CLI поддръжка
+
+
+- (само за CycloneDX)

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

Табло за управление по статус на приложението
+
-
+

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

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

Поддръжка на руски език
-
-
-

Опции за интеграция

интеграция
Nexus IQ
Проверка на зависимостта
Следа на зависимостта

Интеграция на LDAP/Active Directory
+
-
+

Bamboo непрекъсната интеграционна интеграция
+
-
-

Интеграция със система за непрекъсната интеграция (непрекъсната интеграция) TeamCity
+
-
-

Интеграция със системата за непрекъсната интеграция (непрекъсната интеграция) GitLab
+
+- (като плъгин за GitLab)
+

Интеграция със система за непрекъсната интеграция (непрекъсната интеграция) Дженкинс
+
+
+

Наличие на IDE добавки
+ IntelliJ, Eclipse, Visual Studio
-
-

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

Проверка на зависимостта

Първо начало

Стартирайте проверка на зависимостта на умишлено уязвимо приложение DVJA.

За това използваме Плъгин Maven за проверка на зависимостта:

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

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

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

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

Следват CPE, PURL и описание на CVE. Между другото, препоръките за коригиране не са приложени поради липсата им в базата данни на NVD.

За да преглеждате систематично резултатите от сканирането, можете да конфигурирате Nginx с минимални настройки или да изпратите получените дефекти към система за управление на дефекти, която поддържа конектори за проверка на зависимостта. Например Дефект Доджо.

Следа на зависимостта

Инсталация

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

Първо начало

Отидете на URL адреса на изпълняваната услуга. Влизаме през admin / admin, променяме данните за вход и паролата, след което стигаме до таблото за управление. Следващото нещо, което ще направим, е да създадем проект за тестово приложение на Java Начало/Проекти → Създаване на проект . Да вземем DVJA като пример.

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

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

Получаваме bom.xml и зареждаме файла в създадения проект DVJA → Зависимости → Качване на BOM.

Нека отидем на Администриране → Анализатори. Разбираме, че имаме активиран само вътрешния анализатор, който включва NVD. Нека също да свържем Sonatype OSS Index.

Така получаваме следната картина за нашия проект:

Също така в списъка можете да намерите една уязвимост, приложима към Sonatype OSS:

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

тук е видео (И тук), когато все още беше възможно.

Nexus IQ

Първо начало

Инсталацията на Nexus IQ идва от софтуерните архиви документация, но сме компилирали изображение на Docker за тази цел.

След като влезете в конзолата, трябва да създадете Организация и Приложение.

Както можете да видите, конфигурацията в случая на IQ е малко по-сложна, защото също трябва да създадем политики, които са приложими за различни „етапи“ (dev, build, stage, release). Това е необходимо, за да се блокират уязвимите компоненти, когато се приближат до производствения тръбопровод, или да се блокират веднага щом попаднат в Nexus Repo, когато бъдат изтеглени от разработчиците.

За да усетите разликата между отворен код и предприятие, нека извършим същото сканиране през Nexus IQ по същия начин през Приставка Maven, като преди това създаде тестово приложение в интерфейса на NexusIQ dvja-test-and-compare:

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

Следвайте URL адреса към генерирания отчет в уеб интерфейса на IQ:

Тук можете да видите всички нарушения на правилата с различни нива на сериозност (от Информация до Критично за сигурността). Буквата D до компонента означава, че компонентът е Direct Dependency, а буквата T до компонента означава, че компонентът е Transitive Dependency, т.е. той е транзитивен.

Между другото, докладът Доклад за състоянието на сигурността с отворен код за 2020 г от Snyk съобщава, че повече от 70% от уязвимостите с отворен код, открити в Node.js, Java и Ruby, са в преходни зависимости.

Ако отворим някое от нарушенията на правилата на Nexus IQ, можем да видим описанието на компонента, както и графиката на версиите, която показва местоположението на текущата версия на времевата графика, както и в кой момент уязвимостта престава да бъдете уязвими. Височината на свещите на графиката показва популярността на използването на този компонент.

Ако отидете в раздела за уязвимости и отворите CVE, можете да прочетете описанието на тази уязвимост, препоръки за отстраняване, както и причината, поради която този компонент е бил нарушен, тоест наличието на класа DiskFileitem.class.

Нека обобщим само Java компонентите на трети страни, като премахнем js компонентите. В скоби посочваме броя на онези уязвимости, които са открити извън NVD.

Общ Nexus IQ:

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

Пълна проверка на зависимостта:

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

Проследяване на пълна зависимост:

• Сканирани зависимости: 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 няма нищо общо с други компоненти. В този случай то ще бъде фалшиво положително.

Обект на изследване е проектът с отворен код DVJA. Проучването включва само java компоненти (без js).

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

Нека да преминем към резултата от ръчния преглед на идентифицираните уязвимости. Пълен отчет за всеки CVE може да бъде намерен в Приложението.

Обобщени резултати за всички уязвимости:

Параметър
Nexus IQ
Проверка на зависимостта
Следа на зависимостта

Общо идентифицирани уязвимости
42
91
51

Неправилно идентифицирани уязвимости (фалшиво положително)
2 (4.76%)
62 (68,13%)
29 (56.86%)

Не са намерени подходящи уязвимости (фалшиво отрицателно)
10
20
27

Обобщени резултати по компоненти:

Параметър
Nexus IQ
Проверка на зависимостта
Следа на зависимостта

Общо разкрити компоненти
62
47
59

Общо уязвими компоненти
16
13
10

Уязвимите компоненти са идентифицирани неправилно (фалшиво положително)
1
5
0

Уязвимите компоненти са идентифицирани неправилно (фалшиво положително)
0
6
6

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

За сравнение, подобно проучване беше проведено от екипа на 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-

пролетен контекст: 3.0.5
CVE-2011 2894-

пружинно ядро:3.0.5
CVE-2011 2894-

описание CVE-2011 2894- от nvd:


описание CVE-2016 1000027- от nvd:


CVE-2011-2894 е доста добре известен сам по себе си. В доклада Бял източник за 2011г този CVE е признат за един от най-често срещаните. Описанията за CVE-2016-100027 по принцип са малко в NVD и изглежда е приложимо само за Spring Framework 4.1.4. Нека да разгледаме справка и тук става горе-долу ясно. от Устойчиви статии Разбираме, че в допълнение към уязвимостта в RemoteInvocationSerializingExporter в CVE-2011-2894, уязвимостта се вижда в HttpInvokerServiceExporter. Ето какво ни казва Nexus IQ:

В NVD обаче няма нищо подобно, поради което проверката на зависимостите и проследяването на зависимостите получават фалшиви отрицания.

От описанието на CVE-2011-2894 може също да се разбере, че уязвимостта наистина присъства както в spring-context:3.0.5, така и в spring-core:3.0.5. Потвърждение за това може да се намери в статията от този, който е открил тази уязвимост.

№ 2

компонент
Уязвимост
Резултат

носачи2-ядро:2.3.30
CVE-2016 4003-
FALSE

Ако проучим уязвимостта на CVE-2016-4003, ще разберем, че тя е коригирана във версия 2.3.28, въпреки това Nexus IQ ни информира за това. В описанието на уязвимостта има забележка:

Тоест уязвимостта съществува само във връзка с остаряла версия на JRE, за която решиха да ни предупредят. Въпреки това, ние го считаме за фалшиво положително, въпреки че не е най-ужасното.

№ 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. Наличието на втората уязвимост не носи никакъв полезен товар, освен че нейната тежест е нараснала до висока, така че това може да се счита за ненужен шум.

Като цяло не са открити други фалшиви положителни резултати за 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, тогава ще видим следното:
Уведомителна бележка за отклонение: Екипът за изследване на сигурността на Sonatype откри, че тази уязвимост е въведена във версия 3.0.2.RELEASE, а не 5.0.x, както е посочено в препоръката.

Това е последвано от PoC за тази уязвимост, която гласи, че тя присъства във версия 3.0.5.

Фалшивият отрицателен резултат се изпраща на Проверка на зависимостта и Проследяване на зависимостта.

№ 5

Нека разгледаме фалшивите положителни резултати за проверка на зависимости и проследяване на зависимости.

Проверката на зависимостта се откроява по-специално, защото отразява онези CVE, които се прилагат за цялата рамка в NVD, към онези компоненти, към които тези CVE не се прилагат. Това се отнася за CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, които Проверката на зависимостта е „закрепена ” към struts-taglib:1.3.8 и struts-tiles-1.3.8. Тези компоненти нямат нищо общо с това, което е описано в CVE - обработка на заявки, валидиране на страници и т.н. Това се дължи на факта, че само рамката е обща между тези CVE и компоненти, поради което проверката на зависимостта счита това за уязвимост.

Същата ситуация с 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

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

Данни

Както виждаме, определянето на надеждността на идентифицираните уязвимости чрез ръчен преглед не дава недвусмислени резултати, което поражда противоречиви въпроси. Резултатите са, че решението Nexus IQ има най-нисък процент фалшиви положителни резултати и най-висока точност.

На първо място, това се дължи на факта, че екипът на Sonatype разшири описанието за всяка уязвимост на CVE от NVD в своите бази данни, като посочи до класа или функцията на уязвимостта за определена версия на компонента, като извърши допълнителни проучване (например чрез проверка на уязвимости в по-стари версии на софтуера).

Важно влияние върху резултатите оказват и онези уязвимости, които не са включени в NVD, но въпреки това присъстват в базата данни Sonatype, обозначена с SONATYPE. Според доклада Състоянието на уязвимостите на сигурността с отворен код 2020 г 45% от откритите уязвимости с отворен код не се докладват на NVD. Според базата данни на WhiteSource само 29% от всички уязвимости с отворен код, подадени извън NVD, в крайна сметка се публикуват там, поради което е толкова важно да се търсят уязвимости и другаде.

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

Въпреки това практиката показва, че именно отвореният код трябва да стане първите стъпки към зрял DevSecOps. Първото нещо, за което трябва да помислите, за да вградите SCA в разработката, са процесите, а именно да обмислите с ръководството и свързаните отдели как трябва да изглеждат идеалните процеси във вашата организация. Може да се окаже, че за вашата организация първоначално Dependency Check или Dependency Track ще покрият всички бизнес нужди, а Enterprise решенията ще бъдат логично продължение поради нарастващата сложност на разработваните приложения.

Приложение A. Резултати за компоненти
Символи:

• High - високо и критично ниво на уязвимости в компонента
• Средна — Средно тежки уязвимости в компонента
• TRUE - Истински положителен проблем
• FALSE - Фалшив положителен проблем

компонент
Nexus IQ
Проверка на зависимостта
Следа на зависимостта
Резултат

dom4j:1.6.1
Високо
Високо
Високо
TRUE

log4j-ядро: 2.3
Високо
Високо
Високо
TRUE

log4j: 1.2.14
Високо
Високо
-
TRUE

общи-колекции:3.1
Високо
Високо
Високо
TRUE

commons-fileupload:1.3.2
Високо
Високо
Високо
TRUE

commons-beanutils:1.7.0
Високо
Високо
Високо
TRUE

Commons-codec:1:10
Среден
-
-
TRUE

mysql-конектор-java:5.1.42
Високо
Високо
Високо
TRUE

пролетен израз:3.0.5
Високо
компонент не е намерен

TRUE

spring-web:3.0.5
Високо
компонент не е намерен
Високо
TRUE

пролетен контекст: 3.0.5
Среден
компонент не е намерен
-
TRUE

пружинно ядро:3.0.5
Среден
Високо
Високо
TRUE

struts2-config-browser-plugin:2.3.30
Среден
-
-
TRUE

spring-tx:3.0.5
-
Високо
-
FALSE

подпори-ядро:1.3.8
Високо
Високо
Високо
TRUE

xwork-core: 2.3.30
Високо
-
-
TRUE

подпори2-ядро: 2.3.30
Високо
Високо
Високо
TRUE

подпори-taglib:1.3.8
-
Високо
-
FALSE

подпори-керемиди-1.3.8
-
Високо
-
FALSE

Приложение B. Резултати от уязвимостта
Символи:

• High - високо и критично ниво на уязвимости в компонента
• Средна — Средно тежки уязвимости в компонента
• TRUE - Истински положителен проблем
• FALSE - Фалшив положителен проблем

компонент
Nexus IQ
Проверка на зависимостта
Следа на зависимостта
Суровост
Резултат
Коментар

dom4j:1.6.1
CVE-2018 1000632-
CVE-2018 1000632-
CVE-2018 1000632-
Високо
TRUE

CVE-2020 10683-
CVE-2020 10683-
CVE-2020 10683-
Високо
TRUE

log4j-ядро: 2.3
CVE-2017 5645-
CVE-2017 5645-
CVE-2017 5645-
Високо
TRUE

CVE-2020 9488-
CVE-2020 9488-
CVE-2020 9488-
ниско
TRUE

log4j: 1.2.14
CVE-2019 17571-
CVE-2019 17571-
-
Високо
TRUE

-
CVE-2020 9488-
-
ниско
TRUE

SONATYPE-2010-0053
-
-
Високо
TRUE

общи-колекции:3.1
-
CVE-2015 6420-
CVE-2015 6420-
Високо
FALSE
Дубликати RCE(OSSINDEX)

-
CVE-2017 15708-
CVE-2017 15708-
Високо
FALSE
Дубликати RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Високо
TRUE

commons-fileupload:1.3.2
CVE-2016 1000031-
CVE-2016 1000031-
CVE-2016 1000031-
Високо
TRUE

SONATYPE-2014-0173
-
-
Среден
TRUE

commons-beanutils:1.7.0
CVE-2014 0114-
CVE-2014 0114-
CVE-2014 0114-
Високо
TRUE

-
CVE-2019 10086-
CVE-2019 10086-
Високо
FALSE
Уязвимостта е приложима само за версии 1.9.2+

Commons-codec:1:10
SONATYPE-2012-0050
-
-
Среден
TRUE

mysql-конектор-java:5.1.42
CVE-2018 3258-
CVE-2018 3258-
CVE-2018 3258-
Високо
TRUE

CVE-2019 2692-
CVE-2019 2692-
-
Среден
TRUE

-
CVE-2020 2875-
-
Среден
FALSE
Същата уязвимост като CVE-2019-2692, но с добавката „атаките могат значително да повлияят на допълнителни продукти“

-
CVE-2017 15945-
-
Високо
FALSE
Не се отнася за mysql-connector-java

-
CVE-2020 2933-
-
ниско
FALSE
Дублиране на CVE-2020-2934

CVE-2020 2934-
CVE-2020 2934-
-
Среден
TRUE

пролетен израз:3.0.5
CVE-2018 1270-
компонент не е намерен
-
Високо
TRUE

CVE-2018 1257-
-
-
Среден
TRUE

spring-web:3.0.5
CVE-2016 1000027-
компонент не е намерен
-
Високо
TRUE

CVE-2014 0225-
-
CVE-2014 0225-
Високо
TRUE

CVE-2011 2730-
-
-
Високо
TRUE

-
-
CVE-2013 4152-
Среден
TRUE

CVE-2018 1272-
-
-
Високо
TRUE

CVE-2020 5398-
-
-
Високо
TRUE
Пример в полза на IQ: „Екипът за изследване на сигурността на Sonatype откри, че тази уязвимост е въведена във версия 3.0.2.RELEASE, а не 5.0.x, както е посочено в препоръката.“

CVE-2013 6429-
-
-
Среден
TRUE

CVE-2014 0054-
-
CVE-2014 0054-
Среден
TRUE

CVE-2013 6430-
-
-
Среден
TRUE

пролетен контекст: 3.0.5
CVE-2011 2894-
компонент не е намерен
-
Среден
TRUE

пружинно ядро:3.0.5
-
CVE-2011 2730-
CVE-2011 2730-
Високо
TRUE

CVE-2011 2894-
CVE-2011 2894-
CVE-2011 2894-
Среден
TRUE

-
-
CVE-2013 4152-
Среден
FALSE
Дубликат на същата уязвимост в spring-web

-
CVE-2013 4152-
-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web

-
CVE-2013 6429-
CVE-2013 6429-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web

-
CVE-2013 6430-
-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web

-
CVE-2013 7315-
CVE-2013 7315-
Среден
FALSE
РАЗДЕЛЯНЕ от CVE-2013-4152. + Уязвимостта е свързана с компонента spring-web

-
CVE-2014 0054-
CVE-2014 0054-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web

-
CVE-2014 0225-
-
Високо
FALSE
Уязвимостта е свързана с компонента spring-web

-
-
CVE-2014 0225-
Високо
FALSE
Дубликат на същата уязвимост в spring-web

-
CVE-2014 1904-
CVE-2014 1904-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web-mvc

-
CVE-2014 3625-
CVE-2014 3625-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web-mvc

-
CVE-2016 9878-
CVE-2016 9878-
Високо
FALSE
Уязвимостта е свързана с компонента spring-web-mvc

-
CVE-2018 1270-
CVE-2018 1270-
Високо
FALSE
За пролетно изразяване / пролетни послания

-
CVE-2018 1271-
CVE-2018 1271-
Среден
FALSE
Уязвимостта е свързана с компонента spring-web-mvc

-
CVE-2018 1272-
CVE-2018 1272-
Високо
TRUE

CVE-2014 3578-
CVE-2014-3578(OSSINDEX)
CVE-2014 3578-
Среден
TRUE

SONATYPE-2015-0327
-
-
ниско
TRUE

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
-
-
Среден
TRUE

spring-tx:3.0.5
-
CVE-2011 2730-
-
Високо
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2011 2894-
-
Високо
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2013 4152-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2013 6429-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2013 6430-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2013 7315-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2014 0054-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2014 0225-
-
Високо
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2014 1904-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2014 3625-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2016 9878-
-
Високо
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2018 1270-
-
Високо
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2018 1271-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

-
CVE-2018 1272-
-
Среден
FALSE
Уязвимостта не се отнася за spring-tx

подпори-ядро:1.3.8
-
CVE-2011-5057(OSSINDEX)

Среден
FASLE
Уязвимост към Struts 2

-
CVE-2012-0391(OSSINDEX)
CVE-2012 0391-
Високо
FALSE
Уязвимост към Struts 2

-
CVE-2014-0094(OSSINDEX)
CVE-2014 0094-
Среден
FALSE
Уязвимост към Struts 2

-
CVE-2014-0113(OSSINDEX)
CVE-2014 0113-
Високо
FALSE
Уязвимост към Struts 2

CVE-2016 1182-
3VE-2016-1182
-
Високо
TRUE

-
-
CVE-2011 5057-
Среден
FALSE
Уязвимост към Struts 2

-
CVE-2012-0392(OSSINDEX)
CVE-2012 0392-
Високо
FALSE
Уязвимост към Struts 2

-
CVE-2012-0393(OSSINDEX)
CVE-2012 0393-
Среден
FALSE
Уязвимост към Struts 2

CVE-2015 0899-
CVE-2015 0899-
-
Високо
TRUE

-
CVE-2012 0394-
CVE-2012 0394-
Среден
FALSE
Уязвимост към Struts 2

-
CVE-2012-0838(OSSINDEX)
CVE-2012 0838-
Високо
FALSE
Уязвимост към Struts 2

-
CVE-2013-1965(OSSINDEX)
CVE-2013 1965-
Високо
FALSE
Уязвимост към Struts 2

-
CVE-2013-1966(OSSINDEX)
CVE-2013 1966-
Високо
FASLE
Уязвимост към Struts 2

-
CVE-2013 2115-
CVE-2013 2115-
Високо
FASLE
Уязвимост към Struts 2

-
CVE-2013-2134(OSSINDEX)
CVE-2013 2134-
Високо
FASLE
Уязвимост към Struts 2

-
CVE-2013-2135(OSSINDEX)
CVE-2013 2135-
Високо
FASLE
Уязвимост към Struts 2

CVE-2014 0114-
CVE-2014 0114-
-
Високо
TRUE

-
CVE-2015 2992-
CVE-2015 2992-
Среден
FALSE
Уязвимост към Struts 2

-
CVE-2016-0785(OSSINDEX)
CVE-2016 0785-
Високо
FALSE
Уязвимост към Struts 2

CVE-2016 1181-
CVE-2016 1181-
-
Високо
TRUE

-
CVE-2016-4003(OSSINDEX)
CVE-2016 4003-
Високо
FALSE
Уязвимост към Struts 2

xwork-core: 2.3.30
CVE-2017 9804-
-
-
Високо
TRUE

SONATYPE-2017-0173
-
-
Високо
TRUE

CVE-2017 7672-
-
-
Високо
FALSE
Двойно до CVE-2017-9804

SONATYPE-2016-0127
-
-
Високо
TRUE

носачи2-ядро:2.3.30
-
CVE-2016 6795-
CVE-2016 6795-
Високо
TRUE

-
CVE-2017 9787-
CVE-2017 9787-
Високо
TRUE

-
CVE-2017 9791-
CVE-2017 9791-
Високо
TRUE

-
CVE-2017 9793-
-
Високо
FALSE
Дублиране на CVE-2018-1327

-
CVE-2017 9804-
-
Високо
TRUE

-
CVE-2017 9805-
CVE-2017 9805-
Високо
TRUE

CVE-2016 4003-
-
-
Среден
FALSE
Отнася се за Apache Struts 2.x до 2.3.28, което е версия 2.3.30. Въпреки това, въз основа на описанието, CVE работи на всички версии на Struts 2, стига да се използва JRE 1.7 и по-ниска версия. Явно тук са решили да ни презастраховат, но по-скоро изглежда НЕВЯРНО

-
CVE-2018 1327-
CVE-2018 1327-
Високо
TRUE

CVE-2017 5638-
CVE-2017 5638-
CVE-2017 5638-
Високо
TRUE
Същата уязвимост, използвана от нападателите в Equifax през 2017 г

CVE-2017 12611-
CVE-2017 12611-
-
Високо
TRUE

CVE-2018 11776-
CVE-2018 11776-
CVE-2018 11776-
Високо
TRUE

подпори-taglib:1.3.8
-
CVE-2012 0394-
-
Среден
FALSE
За подпори2-ядро

-
CVE-2013 2115-
-
Високо
FALSE
За подпори2-ядро

-
CVE-2014 0114-
-
Високо
FALSE
За Commons-beanutils

-
CVE-2015 0899-
-
Високо
FALSE
Не е свързано с taglib

-
CVE-2015 2992-
-
Среден
FALSE
Свързани със struts2-core

-
CVE-2016 1181-
-
Високо
FALSE
Не е свързано с taglib

-
CVE-2016 1182-
-
Високо
FALSE
Не е свързано с taglib

подпори-керемиди-1.3.8
-
CVE-2012 0394-
-
Среден
FALSE
За подпори2-ядро

-
CVE-2013 2115-
-
Високо
FALSE
За подпори2-ядро

-
CVE-2014 0114-
-
Високо
FALSE
Под Commons-beanutils

-
CVE-2015 0899-
-
Високо
FALSE
Не се отнася за плочки

-
CVE-2015 2992-
-
Среден
FALSE
За подпори2-ядро

-
CVE-2016 1181-
-
Високо
FALSE
Не е свързано с taglib

-
CVE-2016 1182-
-
Високо
FALSE
Не е свързано с taglib

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