🥇DevSecOps: zasady działania i porównanie SCA. Część pierwsza

Znaczenie analizy komponentów oprogramowania osób trzecich (ang. Software Composition Analysis — SCA) w procesie rozwoju rośnie w miarę publikacji corocznych raportów o podatnościach bibliotek open source, które wydają firmy Synopsys, Sonatype, Snyk, White Source. Zgodnie z raportem Stan podatności bezpieczeństwa open source 2020 liczba ujawnionych podatności w open source w 2019 roku wzrosła prawie 1,5 razy w porównaniu z poprzednim rokiem, podczas gdy komponenty o otwartym kodzie są wykorzystywane w 60% do 80% projektów. Jeśli zwrócimy się do niezależnych opinii, procesy SCA są osobną praktyką OWASP SAMM i BSIMM jako wskaźnik dojrzałości, a w pierwszej połowie 2020 roku OWASP wydał nowy standard OWASP Software Component Verification Standard (SCVS), dostarczający najlepsze praktyki w zakresie weryfikacji komponentów osób trzecich w łańcuchu dostaw oprogramowania.

Jednym z najbardziej wymownych przypadków zdarzył się z firmą Equifax w maju 2017 roku. Nieznani cyberprzestępcy uzyskali dostęp do informacji o 143 mln Amerykanów, w tym pełnych imion, adresów, numerów ubezpieczenia społecznego i praw jazdy. W 209 000 przypadków w dokumentach pojawiły się również informacje o kartach bankowych poszkodowanych. Ta luka miała miejsce w wyniku wykorzystania krytycznej podatności w Apache Struts 2 (CVE-2017-5638), podczas gdy poprawka została wydana już w marcu 2017 roku. Firma miała dwa miesiące na wprowadzenie aktualizacji, jednak nikt się tym nie zajął.

W artykule omówiony będzie temat wyboru narzędzia do przeprowadzania SCA z punktu widzenia jakości wyników analizy. Pojawi się także funkcjonalne porównanie narzędzi. Proces integracji w CI/CD oraz możliwości integracji zostawiamy na kolejne publikacje. Szeroki wykaz narzędzi został przedstawiony przez OWASP na swojej stronie, ale w ramach obecnego przeglądu zajmiemy się tylko najpopularniejszym narzędziem open source Dependency Check, nieco mniej znaną open source platformą Dependency Track oraz rozwiązaniem klasy Enterprise Sonatype Nexus IQ. Ponadto zbadamy, jak te rozwiązania działają i porównamy uzyskane wyniki pod kątem fałszywych pozytywów.

Zasada działania

Dependency Check — to narzędzie (CLI, moduł maven, jenkins, ant), które analizuje pliki projektu, zbiera fragmenty informacji o zależnościach (nazwa pakietu, groupid, tytuł specyfikacji, wersja…), tworzy ciąg CPE — (Common Platform Enumeration), Package URL (PURL) i wykrywa dla CPE/PURL podatności z baz danych (NVD, Sonatype OSS Index, NPM Audit API…), a następnie generuje jednorazowy raport w formacie HTML, JSON, XML…

Przyjrzyjmy się, jak wygląda CPE:

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

Część: Wskazanie, że komponent dotyczy aplikacji (a), systemu operacyjnego (o), sprzętu (h) (Wymagany element)
Producent: Nazwa producenta produktu (Wymagany element)
Produkt: Nazwa produktu (Wymagany element)
Wersja: Wersja komponentu (Element przestarzały)
Aktualizacja: Aktualizacja pakietu
Wydanie: Dziedziczona wersja (Element przestarzały)
Język: Język określony w RFC-5646
Wydanie SW: Wersja oprogramowania
Docelowe SW: Środowisko programowe, w którym działa produkt
Docelowe HW: Środowisko sprzętowe, w którym działa produkt
Inne: Informacje o dostawcy lub produkcie

Przykład CPE wygląda następująco:

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

Ciąg oznacza, że CPE wersji 2.3 opisuje komponent aplikacji od producenta pivotal_software o nazwie spring_framework wersji 3.0.0. Jeśli otworzymy podatność CVE-2014-0225 w NVD, to możemy zobaczyć odniesienie do tego CPE. Pierwszy problem, na który należy zwrócić uwagę — CVE w NVD według CPE informuje o problemie w frameworku, a nie w konkretnym komponencie. To znaczy, jeżeli deweloperzy są silnie związani z frameworkiem, a wykryta podatność nie dotyczy tych modułów, które używają deweloperzy, specjalista ds. bezpieczeństwa prędzej czy później będzie musiał zbadać ten CVE i pomyśleć o aktualizacji.

Adres URL jest również wykorzystywany przez narzędzia SCA. Format adresu URL pakietu jest następujący:

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

Schemat: Zawsze będzie to ‚pkg’, wskazujące, że to adres URL pakietu (Wymagany element)
Typ: „Typ” pakietu lub „protokół” pakietu, na przykład maven, npm, nuget, gem, pypi itp. (Wymagany element)
Namespace: Pewien prefiks nazwy, taki jak identyfikator grupy Maven, właściciel obrazu Docker, użytkownik lub organizacja GitHub. Nieobowiązkowy i zależy od typu.
Nazwa: Nazwa pakietu (Wymagany element)
Wersja: Wersja pakietu
Qualifiers: Dodatkowe dane kwalifikacyjne dla pakietu, takie jak system operacyjny, architektura, dystrybucja itp. Opcjonalne i zależne od typu elementu.
Podkatalog: Dodatkowa ścieżka w pakiecie w odniesieniu do katalogu głównego pakietu

Na przykład:

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 — lokalna platforma internetowa, która przyjmuje gotowe listy materiałów (BOM) utworzone CycloneDX i SPDX, czyli gotowe specyfikacje o dostępnych zależnościach. Jest to plik XML z opisem zależności - nazwa, hashe, adres URL pakietu, wydawca, licencja. Następnie Dependency Track analizuje BOM, sprawdza dostępne dla wykrytych zależności CVE w bazie danych luk (NVD, Sonatype OSS Index...), a następnie buduje wykresy, oblicza metryki, regularnie aktualizując dane o statusie luk w komponentach.

Przykład tego, jak może wyglądać BOM w formacie 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 może być używane nie tylko jako parametry wejściowe dla Dependency Track, ale także do inwentaryzacji komponentów oprogramowania w łańcuchu dostaw, na przykład w celu przekazania go klientowi oprogramowania. W 2014 roku w Stanach Zjednoczonych zaproponowano nawet ustawę „Cyber Supply Chain Management and Transparency Act of 2014”, która stwierdzała, że przy zakupie oprogramowania każdego urzędowego instytucja powinna domagać się BOM w celu zapobiegania używaniu podatnych komponentów, jednak akt ten nigdy nie wszedł w życie.

Wracając do SCA, Dependency Track ma gotowe integracje z platformami powiadomień, takimi jak Slack, systemami zarządzania lukami, takimi jak Kenna Security. Warto również dodać, że Dependency Track identyfikuje przestarzałe wersje pakietów i dostarcza informacje o licencjach (dzięki wsparciu SPDX).

Mówiąc o jakości SCA, istnieje zasadnicza różnica.

Dependency Track nie przyjmuje projektu jako danych wejściowych, a przyjmuje dokładnie BOM. Oznacza to, że jeśli chcemy sprawdzić projekt, musimy najpierw wygenerować bom.xml, na przykład za pomocą CycloneDX. W ten sposób Dependency Track bezpośrednio zależy od CycloneDX. Jednocześnie daje to możliwość dostosowania. Tak więc zespół OZON napisał moduł CycloneDX do generowania plików BOM dla projektów w Golang w celu dalszego skanowania przez Dependency Track.

Nexus IQ to komercyjne rozwiązanie SCA od firmy Sonatype, które jest częścią ekosystemu Sonatype, do którego należy również Nexus Repository Manager. Nexus IQ może przyjmować jako dane wejściowe zarówno archiwa war (dla projektów java) przez interfejs webowy lub API, jak i BOM, jeśli twoja organizacja nie zdążyła przestawić się z CycloneDX na nowe rozwiązanie. W przeciwieństwie do rozwiązań open source, IQ odnosi się nie tylko do CP/PURL dla wykrytej komponenty oraz odpowiedniej podatności w bazie danych, ale również uwzględnia własne badania, na przykład nazwę podatnej funkcji lub klasy. Mechanizmy IQ zostaną omówione później przy analizie wyników.

Podsumujmy niektóre funkcjonalne cechy oraz omówmy wspierane języki do analizy:

Język
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Funkcjonalne możliwości

Funkcjonalne możliwości
Nexus IQ
Dependency Check
Dependency Track

Możliwość zapewnienia weryfikacji komponentów używanych w kodzie źródłowym pod kątem czystości licencyjnej
+
—
+

Możliwość skanowania i analizy pod kątem podatności i czystości licencyjnej dla obrazów Docker
+ Integracja z Clair
—
—

Możliwość dostosowania polityki bezpieczeństwa dla użycia bibliotek open source
+
—
—

Możliwość skanowania repozytoriów open source pod kątem podatnych komponentów
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Obecność wyspecjalizowanej grupy badawczej
+
—
—

Praca w zamkniętym obiegu
+
+
+

Wykorzystanie zewnętrznych baz danych
+ Zamknięta baza danych Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, wsparcie własnej bazy danych podatności

Możliwość filtrowania komponentów open source podczas próby ładowania ich do obiegu rozwoju zgodnie z skonfigurowanymi politykami
+
—
—

Zalecenia dotyczące naprawy luk w zabezpieczeniach, w tym linki do rozwiązania
+
+- (zależy od opisu w publicznych bazach)
+- (zależy od opisu w publicznych bazach)

Ranking wykrytych luk w zabezpieczeniach pod względem krytyczności
+
+
+

Model dostępu oparty na rolach
+
—
+

Wsparcie dla interfejsu wiersza poleceń CLI
+
+
+- (tylko dla CycloneDX)

Wyciąganie / sortowanie luk w zabezpieczeniach według określonych kryteriów
+
—
+

Dashboard stanu aplikacji
+
—
+

Generowanie raportów w formacie PDF
+
—
—

Generowanie raportów w formacie JSONCSV
+
+
—

Wsparcie dla języka rosyjskiego
—
—
—

Możliwości integracyjne

Integracja
Nexus IQ
Dependency Check
Dependency Track

Integracja z LDAP/Active Directory
+
—
+

Integracja z systemem ciągłej integracji (continuous integration) Bamboo
+
—
—

Integracja z systemem ciągłej integracji (continuous integration) TeamCity
+
—
—

Integracja z systemem ciągłej integracji (continuous integration) GitLab
+
+- (w postaci wtyczki do GitLab)
+

Integracja z systemem ciągłej integracji (continuous integration) Jenkins
+
+
+

Obecność wtyczek do IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Wsparcie dla dostosowanej integracji przez usługi sieciowe (API) narzędzia
+
—
+

Dependency Check

Pierwsze uruchomienie

Uruchomimy Dependency Check na celowo podatnej aplikacji DVJA.

W tym celu skorzystamy z Dependency Check Maven Plugin:

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

W rezultacie w katalogu target pojawi się dependency-check-report.html.

Otwórzmy plik. Po podsumowaniu ogólnej liczby luk możemy zobaczyć informacje o lukach o wysokim poziomie krytyczności i pewności, z informacjami o pakiecie, CPE, liczbie CVE.

Następnie mamy bardziej szczegółowe informacje, w tym wskazówki, na podstawie których podjęto decyzję (dowody), czyli jakiś BOM.

Dalej idzie CPE, PURL i opis CVE. Należy zauważyć, że zalecenia dotyczące naprawy nie są dołączone z powodu ich braku w bazie NVD.

Aby systematycznie przeglądać wyniki skanowania, można skonfigurować Nginx z minimalnymi ustawieniami lub przesłać wykryte defekty do systemu zarządzania defektami, które obsługują konektory do Dependency Check. Na przykład, Defect Dojo.

Dependency Track

Instalacja

Dependency Track jest z kolei platformą internetową z wykresami, dlatego problem z przechowywaniem defektów w zewnętrznym rozwiązaniu tutaj nie występuje.
Do instalacji istnieją następujące wspierane scenariusze: Docker, WAR, Executable WAR.

Pierwsze uruchomienie

Przechodzimy do adresu URL uruchomionej usługi. Logujemy się przez admin/admin, zmieniamy login i hasło, po czym trafiamy na Dashboard. Następnym krokiem będzie stworzenie projektu dla aplikacji testowej w Java w Home/Projects → Create Project . Jako przykład weźmiemy DVJA.

Ponieważ Dependency Track może przyjmować jako dane wejściowe tylko BOM, należy go najpierw uzyskać. Skorzystamy z CycloneDX Maven Plugin:

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

Otrzymujemy bom.xml i przesyłamy plik w stworzonym projekcie DVJA → Zależności → Prześlij BOM.

Przechodzimy do Administracji → Analityka. Zauważamy, że mamy włączony tylko Internal Analyzer, który zawiera NVD. Podłączymy również Sonatype OSS Index.

W ten sposób uzyskamy następujący obraz naszego projektu:

Wykaz contains również jedną lukę, która dotyczy Sonatype OSS:

Największym rozczarowaniem było to, że Dependency Track już nie przyjmuje raportów xml z Dependency Check. Ostatnie wspierane wersje integracji z Dependency Check to były 1.0.0 – 4.0.2, podczas gdy testowałem 5.3.2.

Oto wideo (i oto), kiedy to jeszcze było możliwe.

Nexus IQ

Pierwsze uruchomienie

Instalacja Nexus IQ odbywa się z archiwów przy pomocy dokumentacji, ale dla tych celów stworzyliśmy obraz Docker.

Po zalogowaniu do konsoli należy stworzyć Organizację i Aplikację.

Jak widać, konfiguracja w przypadku IQ jest nieco bardziej skomplikowana, ponieważ musimy również stworzyć polityki odpowiednie dla różnych „etapów” (dev, build, stage, release). Jest to konieczne, aby blokować podatne komponenty w miarę postępu w pipeline w kierunku produkcji lub blokować je, gdy tylko trafią do Nexus Repo podczas pobierania przez deweloperów.

Aby odczuć różnicę między open source a enterprise, wykonamy takie samo skanowanie przez Nexus IQ, analogicznie do wtyczki Maven, wcześniej tworząc aplikację testową w interfejsie 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=

Przechodzimy pod URL do wygenerowanego raportu w interfejsie webowym IQ:

Tutaj można zobaczyć wszystkie naruszenia polityki z różnym poziomem znaczenia (od Info do Krytycznej Bezpieczeństwa). Litera D obok komponentu oznacza, że komponent jest Zależnością Bezpośrednią, a litera T obok komponentu oznacza, że komponent jest Zależnością Przenośną, czyli jest zależnością pośrednią.

Zresztą, raport State of Open Source Security Report 2020 od Snyk informuje, że ponad 70% luk w oprogramowaniu open source odkrytych w Node.js, Java i Ruby znajduje się w zależnościach przenośnych.

Jeśli otworzymy jedno z naruszeń polityki Nexus IQ, możemy zobaczyć opis komponentu oraz Wykres wersji, który pokazuje położenie bieżącej wersji na osi czasowej oraz moment, w którym podatność przestaje być istotna. Wysokość słupków na wykresie pokazuje popularność użycia tego komponentu.

Jeśli przejdziemy do sekcji podatności i rozwinemy CVE, możemy przeczytać opis tej podatności, zalecenia dotyczące usunięcia oraz powód, dla którego dany komponent został uznany za naruszający, czyli obecność klasy DiskFileitem.class.

Podsumujmy tylko te dotyczące zewnętrznych komponentów Java, pomijając komponenty js. W nawiasach podamy liczbę podatności, które zostały znalezione poza NVD.

Łącznie Nexus IQ:

Skanowane zależności: 62
Podatne zależności: 16
Znalezione podatności: 42 (8 baz danych sonatype)

Łącznie Dependency Check:

Skanowane zależności: 47
Podatne zależności: 13
Znalezione podatności: 91 (14 sonatype oss)

Łącznie Dependency Track:

Skanowane zależności: 59
Podatne zależności: 10
Znalezione podatności: 51 (1 sonatype oss)

W następnym kroku przeanalizujemy uzyskane wyniki i dowiemy się, które z tych podatności są rzeczywistymi defektami, a które fałszywymi alarmami.

Wyłączenie odpowiedzialności

Ta recenzja nie jest niekwestionowaną prawdą. Autorem nie kierowała intencja wyróżnienia jednego narzędzia spośród innych. Celem recenzji było pokazanie mechanizmów działania narzędzi SCA oraz sposobów weryfikacji ich wyników.

Porównanie wyników

Warunki:

Fałszywym alarmem w odniesieniu do podatności zewnętrznych komponentów jest:

Niezgodność CVE z wykrytą komponentą
Na przykład, jeśli podatność została wykryta w frameworku struts2, a narzędzie wskazuje na komponent frameworku struts-tiles, do którego ta podatność się nie odnosi, to jest to fałszywy alarm.
Niezgodność CVE z wykrytą wersją komponentu
Na przykład, jeśli podatność jest przypisana do wersji python > 3.5, a narzędzie wskazuje na podatną wersję 2.7 — to jest fałszywy alarm, ponieważ podatność odnosi się tylko do gałęzi produktu 3.x.
Duplikacja CVE
Na przykład, jeśli SCA wskazał na CVE, która umożliwia realizację RCE, a następnie SCA wskazuje dla tej samej komponenty CVE, które dotyczy produktów Cisco, podatnych na tę RCE. W takim przypadku będzie to fałszywy alarm.
Na przykład, CVE została znaleziona w komponencie spring-web, po czym SCA wskazuje na tę samą CVE w innych komponentach frameworka Spring Framework, podczas gdy CVE nie ma związku z innymi komponentami. W takim przypadku mamy do czynienia z fałszywym alarmem.

Obiektem badania został projekt Open Source DVJA. W badaniu uwzględniono jedynie komponenty java (bez js).

Podsumowanie wyników

Przejdźmy od razu do wyników ręcznego przeglądu zidentyfikowanych podatności. Pełny raport dla każdej CVE jest dostępny w Załączniku.

Podsumowanie wyników dotyczących wszystkich podatności:

Parametr
Nexus IQ
Dependency Check
Dependency Track

Ogółem zidentyfikowano podatności
42
91
51

Błędnie zidentyfikowane podatności (fałszywy alarm)
2(4.76%)
62(68,13%)
29(56.86%)

Nie znaleziono odpowiednich podatności (fałszywy brak)
10
20
27

Podsumowanie wyników według komponentów:

Parametr
Nexus IQ
Dependency Check
Dependency Track

Ogółem zidentyfikowano komponenty
62
47
59

Ogółem podatnych komponentów
16
13
10

Błędnie zidentyfikowane podatne komponenty (fałszywy alarm)
1
5
0

Błędnie zidentyfikowane podatne komponenty (fałszywy alarm)
0
6
6

Stwórzmy wizualne wykresy, aby ocenić stosunek fałszywych alarmów i fałszywych braków do ogólnej liczby podatności. Na osi poziomej oznaczone są komponenty, a na osi pionowej zidentyfikowane w nich podatności.

Dla porównania, podobne badanie zostało przeprowadzone przez zespół Sonatype na próbce 1531 komponentów przy użyciu OWASP Dependency Check. Jak możemy zauważyć, stosunek szumów do poprawnych aktywacji jest porównywalny z naszymi wynikami.

Źródło: www.sonatype.com/why-precision-matters-ebook

Przyjrzyjmy się niektórym CVE z wyników naszego skanowania, aby zrozumieć przyczyny takich rezultatów.

Dowiedz się więcej

Nr 1

Zacznijmy od omówienia kilku interesujących punktów dotyczących Sonatype Nexus IQ.

Nexus IQ wskazuje na problem z deserializacją, co może prowadzić do wykonania RCE w Spring Framework, wielokrotnie. CVE-2016-1000027 w spring-web:3.0.5 po raz pierwszy oraz CVE-2011-2894 w spring-context:3.0.5 i spring-core:3.0.5. Na początku wydaje się, że mamy do czynienia z powtórzeniem podatności w kilku CVE. Jeśli spojrzymy na CVE-2016-1000027 i CVE-2011-2894 w bazie NVD, wszystko wydaje się być oczywiste.

Komponent
Luka

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Opis CVE-2011-2894 z NVD:

Opis CVE-2016-1000027 z NVD:

CVE-2011-2894 jest sama w sobie dość znana. W raporcie White Source z 2011 roku ta CVE była uznawana za jedną z najczęściej występujących. Opis dla CVE-2016-100027 jest zasadniczo nieco ograniczony w NVD, a wydaje się, że jest zastosowana jedynie w Spring Framework 4.1.4. Przyjrzyjmy się reference i w tym momencie staje się to bardziej zrozumiałe. Z artykułu Tenable rozumiemy, że poza podatnością w RemoteInvocationSerializingExporter w CVE-2011-2894, podatność występuje w HttpInvokerServiceExporter. O tym mówi nam Nexus IQ:

Jednak nic takiego nie ma w NVD, przez co Dependency Check i Dependency Track otrzymują fałszywe negatywy.

Z opisu CVE-2011-2894 można wnioskować, że podatność rzeczywiście występuje również w spring-context:3.0.5 i spring-core:3.0.5. Potwierdzenie tego można znaleźć w artykule od osoby, która odkryła tę podatność.

№2

Komponent
Luka
Wynik

struts2-core:2.3.30
CVE-2016-4003
FAŁSZ

Jeżeli zbadamy podatność CVE-2016-4003, zrozumiemy, że została naprawiona już w wersji 2.3.28, a mimo to Nexus IQ o niej informuje. W opisie podatności znajduje się uwaga:

Oznacza to, że podatność istnieje tylko w połączeniu ze starszą wersją JRE, o czym postanowiono nas ostrzec. Mimo to uznajemy to za fałszywy pozytyw, choć nie najgroźniejszy.

№ 3

Komponent
Luka
Wynik

xwork-core:2.3.30
CVE-2017-9804
PRAWDA

xwork-core:2.3.30
CVE-2017-7672
FAŁSZ

Jeżeli spojrzymy na opis CVE-2017-9804 i CVE-2017-7672, zrozumiemy, że problem dotyczy klasy URLValidator, przy czym CVE-2017-9804 wynika z CVE-2017-7672. Obecność drugiej podatności nie niesie ze sobą żadnych przydatnych informacji oprócz tego, że jej powaga wzrosła do wysokiej, więc można uznać to za zbędny hałas.

Ogólnie nie znaleziono innych fałszywych pozytywów dla Nexus IQ.

№4

Jest kilka kwestii, które wyróżniają IQ na tle innych rozwiązań.

Komponent
Luka
Wynik

spring-web:3.0.5
CVE-2020-5398
PRAWDA

CVE w NVD informuje, że dotyczy tylko wersji 5.2.x do 5.2.3, 5.1.x do 5.1.13 oraz wersji 5.0.x do 5.0.16, jednak jeśli spojrzymy na opis CVE w Nexus IQ, zobaczymy coś innego:
Advisory Deviation Notice: Zespół badawczy ds. bezpieczeństwa Sonatype odkrył, że ta podatność została wprowadzona w wersji 3.0.2.RELEASE, a nie 5.0.x, jak podano w poradniku.

Po tym następuje PoC dotyczący tej podatności, który informuje, że występuje ona w wersji 3.0.5.

Fałszywy negatyw jest wysyłany do Dependency Check i Dependency Track.

№5

Spójrzmy na fałszywe pozytywy dla Dependency Check i Dependency Track.

Dependency Check wyraźnie zwraca uwagę na te CVE, które odnoszą się do całego frameworka w NVD, w odniesieniu do komponentów, do których te CVE nie mają zastosowania. Dotyczy to CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, które Dependency Check "przywiązał" do struts-taglib:1.3.8 i struts-tiles-1.3.8. Te komponenty nie mają nic wspólnego z tym, co opisano w CVE – obsługa zapytań, walidacja stron itd. To wynika z faktu, że wspólne dla tych CVE i komponentów jest tylko framework, co sprawia, że Dependency Check uznał to za podatność.

Sytuacja jest podobna w przypadku spring-tx:3.0.5 oraz w przypadku struts-core:1.3.8. Dla struts-core narzędzia Dependency Check i Dependency Track wykryły wiele podatności, które tak naprawdę dotyczą struts2-core, który w zasadzie jest odrębnym frameworkiem. W tym przypadku Nexus IQ poprawnie zrozumiał sytuację i w CVE, które podał, wskazał, że struts-core osiągnął koniec wsparcia i należy przejść do struts2-core.

Nr 6

W niektórych sytuacjach interpretowanie oczywistego błędu przez Dependency Check i Dependency Track jest niesprawiedliwe. W szczególności CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, które Dependency Check i Dependency Track przypisały do spring-core:3.0.5, tak naprawdę odnoszą się do spring-web:3.0.5. Część z tych CVE została też wykryta przez Nexus IQ, jednak IQ poprawnie przypisał je do innego komponentu. To, że te podatności nie zostały wykryte w spring-core, nie oznacza, że ich tam nie ma, a narzędzia open source słusznie wskazały na te podatności (po prostu trochę się pomyliły).

Wnioski

Jak widać, ocena prawdziwości wykrytych podatności podczas przeglądu ręcznego nie daje jednoznacznych wyników, co prowadzi do kontrowersji. Wyniki pokazują, że rozwiązanie Nexus IQ ma najmniejszy wskaźnik fałszywych alarmów i największą dokładność.

Przede wszystkim jest to związane z tym, że zespół Sonatype rozszerzył opis każdej podatności CVE z NVD w swoich bazach, precyzując co do klasy lub funkcji podatności dla danej wersji komponentu, przeprowadzając dodatkowe badania (na przykład sprawdzając podatności na starszych wersjach oprogramowania).

Znaczenie mają również te podatności, które nie znalazły się w NVD, ale mimo to występują w bazie Sonatype z oznaczeniem SONATYPE. Zgodnie z raportem Stan podatności bezpieczeństwa open source 2020 około 45% odkrytych podatności w oprogramowaniu open source nie jest zgłaszanych do NVD. Zgodnie z bazą danych WhiteSource, tylko 29% wszystkich podatności open source, zarejestrowanych poza NVD, ostatecznie jest w niej publikowanych, dlatego tak ważne jest poszukiwanie podatności także w innych źródłach.

W efekcie Dependency Check generuje dużą ilość szumów, pomijając część podatnych komponentów. Dependency Track generuje mniejszy szum i identyfikuje dużą liczbę komponentów, co wizualnie nie razi w oczy w interfejsie webowym.

Niemniej jednak praktyka pokazuje, że to właśnie open source powinien stać się pierwszym krokiem w kierunku dojrzałego DevSecOps. Pierwszą rzeczą, nad którą należy się zastanowić w kontekście implementacji SCA w rozwój, są procesy, a mianowicie wspólne rozmyślania z kierownictwem i pokrewnymi działami na temat tego, jak powinny wyglądać idealne procesy w organizacji. Może się okazać, że dla Twojej organizacji na początkowym etapie Dependency Check lub Dependency Track pokryją wszystkie istotne potrzeby biznesowe, a rozwiązania Enterprise będą logicznym przedłużeniem w związku ze wzrastającą złożonością rozwijanych aplikacji.

Aplikacja A. Wyniki dotyczące komponentów
Oznaczenia:

High — luki o wysokim i krytycznym poziomie w komponencie
Medium — Luka o średnim poziomie krytyczności w komponencie
TRUE — Prawidłowo zidentyfikowana luka (True positive issue)
FALSE — Fałszywe alarm (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Wynik

dom4j: 1.6.1
Wysoki
Wysoki
Wysoki
PRAWDA

log4j-core: 2.3
Wysoki
Wysoki
Wysoki
PRAWDA

log4j: 1.2.14
Wysoki
Wysoki
—
PRAWDA

commons-collections:3.1
Wysoki
Wysoki
Wysoki
PRAWDA

commons-fileupload:1.3.2
Wysoki
Wysoki
Wysoki
PRAWDA

commons-beanutils:1.7.0
Wysoki
Wysoki
Wysoki
PRAWDA

commons-codec:1:10
Medium
—
—
PRAWDA

mysql-connector-java:5.1.42
Wysoki
Wysoki
Wysoki
PRAWDA

spring-expression:3.0.5
Wysoki
komponent nie znaleziony

PRAWDA

spring-web:3.0.5
Wysoki
komponent nie znaleziony
Wysoki
PRAWDA

spring-context:3.0.5
Medium
komponent nie znaleziony
—
PRAWDA

spring-core:3.0.5
Medium
Wysoki
Wysoki
PRAWDA

struts2-config-browser-plugin:2.3.30
Medium
—
—
PRAWDA

spring-tx:3.0.5
—
Wysoki
—
FAŁSZ

struts-core:1.3.8
Wysoki
Wysoki
Wysoki
PRAWDA

xwork-core: 2.3.30
Wysoki
—
—
PRAWDA

struts2-core: 2.3.30
Wysoki
Wysoki
Wysoki
PRAWDA

struts-taglib:1.3.8
—
Wysoki
—
FAŁSZ

struts-tiles-1.3.8
—
Wysoki
—
FAŁSZ

Aplikacja B. Wyniki dotyczące luk
Oznaczenia:

High — luki o wysokim i krytycznym poziomie w komponencie
Medium — Luka o średnim poziomie krytyczności w komponencie
TRUE — Prawidłowo zidentyfikowana luka (True positive issue)
FALSE — Fałszywe alarm (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Severity
Wynik
Komentarz

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Wysoki
PRAWDA

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Wysoki
PRAWDA

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Wysoki
PRAWDA

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Niski
PRAWDA

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Wysoki
PRAWDA

—
CVE-2020-9488
—
Niski
PRAWDA

SONATYPE-2010-0053
—
—
Wysoki
PRAWDA

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Wysoki
FAŁSZ
Duplikat RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Wysoki
FAŁSZ
Duplikat RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Wysoki
PRAWDA

commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Wysoki
PRAWDA

SONATYPE-2014-0173
—
—
Medium
PRAWDA

commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Wysoki
PRAWDA

—
CVE-2019-10086
CVE-2019-10086
Wysoki
FAŁSZ
Luka dotyczy tylko wersji 1.9.2+

commons-codec:1:10
SONATYPE-2012-0050
—
—
Medium
PRAWDA

mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Wysoki
PRAWDA

CVE-2019-2692
CVE-2019-2692
—
Medium
PRAWDA

—
CVE-2020-2875
—
Medium
FAŁSZ
Ta sama luka co CVE-2019-2692, ale z dopiskiem "ataki mogą znacząco wpłynąć na dodatkowe produkty"

—
CVE-2017-15945
—
Wysoki
FAŁSZ
Nie dotyczy mysql-connector-java

—
CVE-2020-2933
—
Niski
FAŁSZ
Duplikat CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
—
Medium
PRAWDA

spring-expression:3.0.5
CVE-2018-1270
komponent nie znaleziony
—
Wysoki
PRAWDA

CVE-2018-1257
—
—
Medium
PRAWDA

spring-web:3.0.5
CVE-2016-1000027
komponent nie znaleziony
—
Wysoki
PRAWDA

CVE-2014-0225
—
CVE-2014-0225
Wysoki
PRAWDA

CVE-2011-2730
—
—
Wysoki
PRAWDA

—
—
CVE-2013-4152
Medium
PRAWDA

CVE-2018-1272
—
—
Wysoki
PRAWDA

CVE-2020-5398
—
—
Wysoki
PRAWDA
Przykład wspierający IQ: "Zespół badań bezpieczeństwa Sonatype odkrył, że ta luka została wprowadzona w wersji 3.0.2.RELEASE, a nie w 5.0.x, jak podano w komunikacie."

CVE-2013-6429
—
—
Medium
PRAWDA

CVE-2014-0054
—
CVE-2014-0054
Medium
PRAWDA

CVE-2013-6430
—
—
Medium
PRAWDA

spring-context:3.0.5
CVE-2011-2894
komponent nie znaleziony
—
Medium
PRAWDA

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Wysoki
PRAWDA

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
PRAWDA

—
—
CVE-2013-4152
Medium
FAŁSZ
Duplikat tej samej luki w spring-web

—
CVE-2013-4152
—
Medium
FAŁSZ
Luka dotyczy komponentu spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
FAŁSZ
Luka dotyczy komponentu spring-web

—
CVE-2013-6430
—
Medium
FAŁSZ
Luka dotyczy komponentu spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
FAŁSZ
SPLIT z CVE-2013-4152. + Luka dotyczy komponentu spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
FAŁSZ
Luka dotyczy komponentu spring-web

—
CVE-2014-0225
—
Wysoki
FAŁSZ
Luka dotyczy komponentu spring-web

—
—
CVE-2014-0225
Wysoki
FAŁSZ
Duplikat tej samej luki w spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
FAŁSZ
Luka dotyczy komponentu spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
FAŁSZ
Luka dotyczy komponentu spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Wysoki
FAŁSZ
Luka dotyczy komponentu spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Wysoki
FAŁSZ
Dla spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medium
FAŁSZ
Luka dotyczy komponentu spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Wysoki
PRAWDA

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medium
PRAWDA

SONATYPE-2015-0327
—
—
Niski
PRAWDA

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Medium
PRAWDA

spring-tx:3.0.5
—
CVE-2011-2730
—
Wysoki
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2011-2894
—
Wysoki
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2013-4152
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2013-6429
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2013-6430
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2013-7315
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2014-0054
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2014-0225
—
Wysoki
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2014-1904
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2014-3625
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2016-9878
—
Wysoki
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2018-1270
—
Wysoki
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2018-1271
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

—
CVE-2018-1272
—
Medium
FAŁSZ
Luka nie dotyczy spring-tx

struts-core:1.3.8
—
CVE-2011-5057 (OSSINDEX)

Medium
FASLE
Luka dotycząca Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Wysoki
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Wysoki
FAŁSZ
Luka dotycząca Struts 2

CVE-2016-1182
3VE-2016-1182
—
Wysoki
PRAWDA

—
—
CVE-2011-5057
Medium
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Wysoki
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FAŁSZ
Luka dotycząca Struts 2

CVE-2015-0899
CVE-2015-0899
—
Wysoki
PRAWDA

—
CVE-2012-0394
CVE-2012-0394
Medium
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Wysoki
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Wysoki
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Wysoki
FASLE
Luka dotycząca Struts 2

—
CVE-2013-2115
CVE-2013-2115
Wysoki
FASLE
Luka dotycząca Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Wysoki
FASLE
Luka dotycząca Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Wysoki
FASLE
Luka dotycząca Struts 2

CVE-2014-0114
CVE-2014-0114
—
Wysoki
PRAWDA

—
CVE-2015-2992
CVE-2015-2992
Medium
FAŁSZ
Luka dotycząca Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Wysoki
FAŁSZ
Luka dotycząca Struts 2

CVE-2016-1181
CVE-2016-1181
—
Wysoki
PRAWDA

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Wysoki
FAŁSZ
Luka dotycząca Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Wysoki
PRAWDA

SONATYPE-2017-0173
—
—
Wysoki
PRAWDA

CVE-2017-7672
—
—
Wysoki
FAŁSZ
Duplikat do CVE-2017-9804

SONATYPE-2016-0127
—
—
Wysoki
PRAWDA

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Wysoki
PRAWDA

—
CVE-2017-9787
CVE-2017-9787
Wysoki
PRAWDA

—
CVE-2017-9791
CVE-2017-9791
Wysoki
PRAWDA

—
CVE-2017-9793
—
Wysoki
FAŁSZ
Duplikat do CVE-2018-1327

—
CVE-2017-9804
—
Wysoki
PRAWDA

—
CVE-2017-9805
CVE-2017-9805
Wysoki
PRAWDA

CVE-2016-4003
—
—
Medium
FAŁSZ
Dotyczy Apache Struts 2.x przed 2.3.28, a to jest wersja 2.3.30. Niemniej jednak, na podstawie opisu, CVE działa przy wszystkich wersjach Struts 2, jeśli używana jest JRE 1.7 i niższe. Wygląda na to, że postanowili się tu zabezpieczyć, ale bardziej przypomina to FAŁSZ.

—
CVE-2018-1327
CVE-2018-1327
Wysoki
PRAWDA

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Wysoki
PRAWDA
To ta sama luka, której użyli przestępcy w Equifax w 2017 roku.

CVE-2017-12611
CVE-2017-12611
—
Wysoki
PRAWDA

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Wysoki
PRAWDA

struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
FAŁSZ
Do struts2-core

—
CVE-2013-2115
—
Wysoki
FAŁSZ
Do struts2-core

—
CVE-2014-0114
—
Wysoki
FAŁSZ
Do commons-beanutils

—
CVE-2015-0899
—
Wysoki
FAŁSZ
Nie dotyczy taglib

—
CVE-2015-2992
—
Medium
FAŁSZ
Dotyczy struts2-core

—
CVE-2016-1181
—
Wysoki
FAŁSZ
Nie dotyczy taglib

—
CVE-2016-1182
—
Wysoki
FAŁSZ
Nie dotyczy taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FAŁSZ
Do struts2-core