🥇DevSecOps: arbetsprinciper och jämförelse av SCA. Del ett

Betydelsen av analys av tredjepartsprogramvara (på engelska Software Composition Analysis — SCA) under utvecklingsprocessen ökar i takt med årliga rapporter om sårbarheter i öppen källkod som publiceras av företag som Synopsys, Sonatype, Snyk, White Source. Enligt rapporten Tillståndet för sårbarheter inom öppen källkod 2020 ökar antalet identifierade sårbarheter inom öppen källkod 2019 nästan 1,5 gånger jämfört med föregående år, medan komponenter med öppen källkod används i 60 % till 80 % av projekten. Om man hänvisar till oberoende åsikter är SCA-processer en separat praxis inom OWASP SAMM och BSIMM som en indikator för mognad, och under första halvan av 2020 publicerade OWASP en ny standard, OWASP Software Component Verification Standard (SCVS), som tillhandahåller bästa praxis för kontroll av tredjeparts komponenter i mjukvaruleveranskedjan.

Ett av de mest illustrativa fallen inträffade med företaget Equifax i maj 2017. Okända angripare fick tillgång till information om 143 miljoner amerikaner, inklusive fullständiga namn, adresser, socialförsäkringsnummer och körkort. I 209 000 fall förekom även information om de drabbades bankkort i dokumenten. Denna läcka inträffade till följd av utnyttjandet av en kritisk sårbarhet i Apache Struts 2 (CVE-2017-5638), trots att en fix hade släppts redan i mars 2017. Företaget hade två månader på sig att installera uppdateringen, men ingen tog sig an detta.

I denna artikel kommer vi att diskutera frågan om val av verktyg för att genomföra SCA ur perspektivet av analysens kvalitet. Vi kommer också att ge en funktionell jämförelse av verktygen. Processen för integration i CI/CD och integrationsmöjligheterna lämnar vi åt framtida publikationer. En omfattande lista med verktyg presenterades av OWASP på sin webbplats, men inom ramen för denna översikt kommer vi att beröra endast det mest populära open source-verktyget Dependency Check, den något mindre kända open source-plattformen Dependency Track och företagslösningen Sonatype Nexus IQ. Vi kommer också att undersöka hur dessa lösningar fungerar och jämföra resultaten gällande falska positiva resultat.

Arbetsprincip.

Dependency Check — är ett verktyg (CLI, maven, jenkins modul, ant) som analyserar projektfiler, samlar fragment av information om beroenden (paketnamn, groupid, specifications titel, version…), bygger en CPE-sträng — (Common Platform Enumeration), Package URL (PURL) och identifierar sårbarheter för CPE/PURL från databaser (NVD, Sonatype OSS Index, NPM Audit API…), och skapar en engångsrapport i formatet HTML, JSON, XML…

Låt oss titta på hur en CPE ser ut:

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

Part: Ange om komponenten tillhör en applikation (a), operativsystem (o), hårdvara (h) (Obligatoriskt fält)
Vendor: Namnet på produktens tillverkare (Obligatoriskt fält)
Product: Produktnamn (Obligatoriskt fält)
Version: Version av komponenten (Utdaterat fält)
Update: Paketuppdatering
Edition: Arvversion (Utdaterat fält)
Language: Språk som definieras i RFC-5646
SW Edition: Programvaruversion
Target SW: Den programmiljö där produkten körs
Target HW: Den hårdvarumiljö där produkten körs
Other: Information om leverantören eller produkten

Exemplet på CPE ser ut så här:

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

Strängen betyder att CPE version 2.3 beskriver en applikationskomponent från tillverkaren pivotal_software med namnet spring_framework version 3.0.0. Om vi öppnar sårbarheten CVE-2014-0225 i NVD kan vi se referensen till denna CPE. Det första problemet som omedelbart bör märkas — CVE i NVD, enligt CPE, meddelar om ett problem i ramverket, inte i den specifika komponenten. Det innebär att om utvecklarna är starkt kopplade till ramverket och den identifierade sårbarheten inte rör de moduler som utvecklarna använder, kommer säkerhetsspecialisten på något sätt att behöva granska denna CVE och tänka på en uppdatering.

URL:en används också av SCA-verktyg. Formatet för paketets URL är som följer:

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

Scheme: Kommer alltid att vara 'pkg', som indikerar att det är en paket-URL (Obligatoriskt fält)
Type: "Typ" av paket eller "protokoll" av paket, till exempel maven, npm, nuget, gem, pypi osv. (Obligatoriskt fält)
Namespace: Ett visst prefix av namn, såsom Maven-grupp-ID, ägare av Docker-bild, användare eller organisation på GitHub. Valfritt och varierar beroende på typ.
Namn: Paketnamn (Obligatoriskt fält)
Version: Paketversion
Qualifiers: Ytterligare kvalifikationsuppgifter för paketet, såsom operativsystem, arkitektur, distribution osv. Obligatorisk och beroende av typ av punkt.
Underkatalog: Ytterligare sökväg i paketet i förhållande till paketets rot

Till exempel:

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 — en plattform för lokala installationer som tar emot färdiga Bill of Materials (BOM) skapade CycloneDX och SPDX, det vill säga färdiga specifikationer över befintliga beroenden. Detta är en XML-fil med beskrivning av beroenden — namn, hash, paket-url, utgivare, licens. Därefter analyserar Dependency Track BOM:en, kontrollerar förekomsten av identifierade beroenden mot CVE-databasen (NVD, Sonatype OSS Index…), därefter bygger den grafer, beräknar mätvärden och uppdaterar kontinuerligt information om sårbarhetsstatusen för komponenterna.

Exempel på hur en BOM kan se ut i XML-format:

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 kan användas inte bara som inparametrar för Dependency Track, utan också för att inventera programkomponenter i leveranskedjan, till exempel för att tillhandahålla programvara till kunden. År 2014 lades till och med ett lagförslag fram i USA «Cyber Supply Chain Management and Transparency Act of 2014», vilket angav att när programvara köptes skulle varje statlig myndighet begära en BOM för att förhindra användning av sårbara komponenter, men på grund av detta trädde lagen aldrig i kraft.

Återkommande till SCA har Dependency Track färdiga integrationer med meddelandeplattformar som Slack och sårbarhetshanteringssystem som Kenna Security. Det bör också nämnas att Dependency Track dessutom identifierar föråldrade versioner av paket och tillhandahåller information om licenser (genom stöd för SPDX).

När det gäller kvaliteten på SCA finns det en grundläggande skillnad.

Dependency Track tar inte emot projekt som indata, utan tar emot BOM. Det innebär att om vi vill kontrollera projektet måste vi först generera bom.xml, till exempel med hjälp av CycloneDX. På så sätt är Dependency Track direkt beroende av CycloneDX. Samtidigt ger det möjligheter till anpassning. Till exempel har OZON-teamet skrivit modulen CycloneDX för att bygga BOM-filer för projekt i Golang med syfte att senare skanna via Dependency Track.

Nexus IQ är en kommersiell SCA-lösning från Sonatype, som är en del av Sonatype-ekosystemet där även Nexus Repository Manager ingår. Nexus IQ kan ta emot både war-arkiv (för Java-projekt) via webbgränssnitt eller API, samt BOM, om din organisation inte har fått tid att omstrukturera från CycloneDX till den nya lösningen. Till skillnad från open source-lösningar tar IQ hänsyn till inte bara CP/PURL för den identifierade komponenten och motsvarande sårbarhet i databasen, utan även egna undersökningar, till exempel namnet på den sårbara funktionen eller klassen. Mekanismerna för IQ kommer att behandlas senare när vi analyserar resultaten.

Låt oss sammanfatta några slutsatser angående funktionella egenskaper samt gå igenom de stödda språken för analys:

Språk
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Funktionella möjligheter

Funktionella möjligheter
Nexus IQ
Dependency Check
Dependency Track

Möjlighet att säkerställa granskning av komponenter som används i källkoden för licensrenhet
+
—
+

Möjlighet till skanning och analys av sårbarheter och licensrenhet för Docker-avbilder
+ Integration med Clair
—
—

Möjlighet att konfigurera säkerhetspolicyer för att använda bibliotek med öppen källkod
+
—
—

Möjlighet att skanna offentliga källkodsförvar efter sårbara komponenter
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Närvaro av en specialiserad forskargrupp
+
—
—

Arbete i ett slutet system
+
+
+

Användning av externa databaser
+ Sluten databas från Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, stöd för egen sårbarhetsdatabas

Möjlighet att filtrera komponenter med öppen källkod vid försök att ladda upp till utvecklingskonturen enligt konfigurerade policyer
+
—
—

Rekommendationer för att åtgärda sårbarheter, inklusive länkar för åtgärder
+
+- (beror på beskrivningen i offentliga databaser)
+- (beror på beskrivningen i offentliga databaser)

Rankning av upptäckta sårbarheter efter kritikalitet
+
+
+

Rollmodell för åtkomst
+
—
+

Stöd för kommandoradsgränssnitt (CLI)
+
+
+- (endast för CycloneDX)

Utdragning / sortering av sårbarheter enligt angivna kriterier
+
—
+

Dashboard för appstatus
+
—
+

Generera rapporter i PDF-format
+
—
—

Generera rapporter i JSONCSV-format
+
+
—

Stöd för ryska språket
—
—
—

Integrationsmöjligheter

Integration
Nexus IQ
Dependency Check
Dependency Track

Integration med LDAP/Active Directory
+
—
+

Integration med kontinuerlig integrationssystem (continous integration) Bamboo
+
—
—

Integration med kontinuerlig integrationssystem (continous integration) TeamCity
+
—
—

Integration med kontinuerlig integrationssystem (continous integration) GitLab
+
+- (i form av en plugin för GitLab)
+

Integration med kontinuerlig integrationssystem (continous integration) Jenkins
+
+
+

Tillgång till plugins för IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Stöd för anpassad integration via webbtjänster (API)
+
—
+

Dependency Check

Första körning

Vi kör Dependency Check på en avsiktligt sårbar applikation DVJA.

För detta använder vi Dependency Check Maven Plugin:

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

Som ett resultat kommer dependency-check-report.html att visas i target-katalogen.

Vi öppnar filen. Efter sammanfattningen av det totala antalet sårbarheter kan vi se information om sårbarheter med hög severitet och förtroende med referens till paket, CPE, och antal CVE.

Därefter följer mer detaljerad information, särskilt den grund på vilken beslutet fattades (evidence), det vill säga någon form av BOM.

Vidare finns CPE, PURL och beskrivning av CVE. Rekommendationer för åtgärder härmed bifogas tyvärr inte på grund av deras frånvaro i NVD-databasen.

För att systematiskt granska resultaten av skanningen kan Nginx konfigureras med minimala inställningar, eller så kan de upptäckta defekterna skickas till ett defektstyrningssystem som har anslutningar till Dependency Check. Till exempel, Defect Dojo.

Dependency Track

Installation

Dependency Track är i sin tur en webbplattform med visande grafer, så den brännande frågan om lagring av defekter i en extern lösning är här inte aktuell.
För installation finns följande stödda scenarier: Docker, WAR, Executable WAR.

Första körning

Vi går till URL:en för den startade tjänsten. Loggar in med admin/admin, ändrar sitt användarnamn och lösenord, och hamnar på Dashboard. Nästa steg är att skapa ett projekt för den testapplikationen på Java i Home/Projects → Create Project . Som exempel tar vi DVJA.

Eftersom Dependency Track endast kan ta emot BOM som indata måste vi få tag på denna BOM. Vi använder CycloneDX Maven Plugin:

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

Vi får bom.xml och laddar upp filen i det skapade projektet DVJA → Dependencies → Ladda upp BOM.

Vi går till Administration → Analyzers. Vi inser att endast Internal Analyzer är aktiverad, som inkluderar NVD. Vi kopplar även in Sonatype OSS Index.

På så sätt får vi följande bild för vårt projekt:

I listan finns också en sårbarhet kopplad till Sonatype OSS:

Den största besvikelsen var att Dependency Track inte längre accepterar xml-rapporter från Dependency Check. De senaste stödda versionerna för integration med Dependency Check var 1.0.0 – 4.0.2, medan jag testade 5.3.2.

Här är video (och här), när detta fortfarande var möjligt.

Nexus IQ

Första körning

Installation av Nexus IQ sker från arkiv genom dokumentationen, men för dessa ändamål har vi byggt en Docker-bild.

Efter inloggning i konsolen måste en Organisation och en Applikation skapas.

Som man kan se är inställningarna för IQ något mer komplicerade, eftersom vi också måste skapa policyer som är tillämpliga för olika 'steg' (dev, build, stage, release). Detta är nödvändigt för att blockera sårbara komponenter när vi går framåt i pipelinen mot produktion, eller blockera dem så snart de hamnar i Nexus Repo vid nedladdning av utvecklarna.

För att förstå skillnaden mellan öppen källkod och enterprise, kommer vi att göra en liknande skanning genom Nexus IQ som vi gjorde genom Maven-plugin, efter att först ha skapat en testapplikation i NexusIQ-gränssnittet dvja-test-and-compare:

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

Vi går till URL:en för den genererade rapporten i IQ:s webbgränssnitt:

Här kan vi se alla policyöverträdelser med angivande av olika nivåer av allvarlighet (från Info till Security Critical). Bokstaven D bredvid komponenten innebär att komponenten är en Direct Dependency, medan bokstaven T bredvid komponenten betyder att den är en Transitive Dependency.

Förresten, rapporten State of Open Source Security Report 2020 från Snyk rapporterar att över 70% av de öppen källkods-sårbarheter som upptäckts i Node.js, Java och Ruby finns i transitiva beroenden.

Om vi öppnar ett av brotten mot Nexus IQs policy kan vi se en beskrivning av komponenten samt Version Graph, som visar var den aktuella versionen ligger på tidslinjen, samt när sårbarheten slutar vara sårbar. Höjden på staplarna i grafen visar populariteten av att använda denna komponent.

Om vi går till avsnittet för sårbarheter och vecklar ut CVE, kan vi läsa beskrivningen av denna sårbarhet, rekommendationerna för åtgärd samt orsaken till att denna komponent klassificerades som ett brott, det vill säga förekomsten av klassen DiskFileitem.class.

Låt oss sammanfatta enbart de som rör tredjeparts Java-komponenter och ta bort js-komponenterna. I parentes anger vi antalet sårbarheter som har hittats utanför NVD.

Totalt Nexus IQ:

Genomgångna beroenden: 62
Sårbara beroenden: 16
Hittade sårbarheter: 42 (8 sonatype db)

Totalt Dependency Check:

Genomgångna beroenden: 47
Sårbara beroenden: 13
Hittade sårbarheter: 91 (14 sonatype oss)

Totalt Dependency Track:

Genomgångna beroenden: 59
Sårbara beroenden: 10
Hittade sårbarheter: 51 (1 sonatype oss)

I nästa steg kommer vi att analysera de resultat vi har fått och ta reda på vilka av dessa sårbarheter som är verkliga defekter och vilka som är falska positiva.

Disclaimer

Denna granskning är inte en oemotsäglig sanning. För författaren var målet inte att lyfta fram ett enskilt verktyg i förhållande till andra. Syftet med granskningen var att visa hur SCA-verktygen fungerar och hur man verifierar deras resultat.

Jämförelse av resultat

Villkor:

En falsk positiv i förhållande till sårbarheter i tredjeparts komponenter är:

Mismatch mellan CVE och den identifierade komponenten
Till exempel, om en sårbarhet har identifierats i struts2-ramverket, men verktyget pekar på komponenten struts-tiles, som inte är relevant för denna sårbarhet, då är det en falsk positiv.
Mismatch mellan CVE och den identifierade versionen av komponenten
Till exempel, om sårbarheten är knuten till versionen python > 3.5 och verktyget markerar version 2.7 som sårbar, är det en falsk positiv, eftersom sårbarheten faktiskt enbart gäller produktversionen 3.x.
Duplicering av CVE
Till exempel, om SCA pekade på en CVE som möjliggör RCE och sedan anger samma komponent med en CVE som är tillämplig på Cisco-produkter som är sårbara för denna RCE, då är det en falsk positiv.
Till exempel, CVE hittades i komponenten spring-web, varefter SCA pekar på samma CVE i andra komponenter av ramverket Spring Framework, medan CVE inte har något att göra med andra komponenter. I så fall blir det en falsk positiv.

Forskningsobjektet valdes till Open Source-projektet DVJA. Endast java-komponenter deltog i studien (utan js).

Sammanfattande resultat

Låt oss gå direkt till resultaten av den manuella genomgången av de identifierade sårbarheterna. Den fullständiga rapporten för varje CVE kan ses i Bilagan.

Sammanfattande resultat för alla sårbarheter:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Totalt upptäckta sårbarheter
42
91
51

Felaktigt identifierade sårbarheter (falsk positiv)
2(4.76%)
62(68,13%)
29(56.86%)

Inga relevanta sårbarheter upptäcktes (falsk negativ)
10
20
27

Sammanfattande resultat per komponent:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Totalt upptäckta komponenter
62
47
59

Totalt sårbara komponenter
16
13
10

Felaktigt identifierade sårbara komponenter (falska positiva)
1
5
0

Felaktigt identifierade sårbara komponenter (falska positiva)
0
6
6

Vi bygger visuella grafer för att bedöma förhållandet mellan falska positiva och falska negativa i förhållande till det totala antalet sårbarheter. Horisontellt visas komponenterna, och vertikalt de identifierade sårbarheterna.

För jämförelse har ett liknande forskningsprojekt genomförts av Sonatype för att testa ett projekt som består av 1531 komponenter med hjälp av OWASP Dependency Check. Som vi kan se är förhållandet mellan brus och korrekta träffar överensstämmande med våra resultat.

Källa: www.sonatype.com/why-precision-matters-ebook

Låt oss titta på några CVE från resultaten av vår skanning för att förstå orsaken till dessa resultat.

Läs mer

Nr 1

Låt oss först gå igenom några intressanta punkter från Sonatype Nexus IQ.

Nexus IQ indikerar ett problem med deserialisering som möjliggör RCE i Spring Framework flera gånger. CVE-2016-1000027 i spring-web:3.0.5 för första gången, och CVE-2011-2894 i spring-context:3.0.5 och spring-core:3.0.5. Inledningsvis verkar det som om sårbarheten duppliceras över flera CVE. Om man tittar på CVE-2016-1000027 och CVE-2011-2894 i NVD-databasen verkar allt uppenbart.

Komponent
Sårbarhet

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Beskrivning CVE-2011-2894 från NVD:

Beskrivning CVE-2016-1000027 från NVD:

CVE-2011-2894 är ganska känd i sig. I rapporten White Source för 2011 erkändes denna CVE som en av de vanligaste. Det finns ganska lite information för CVE-2016-100027 i NVD, och den verkar bara vara tillämplig på Spring Framework 4.1.4. Låt oss titta på referens och här blir det mer eller mindre klart. Från artikeln Tenable förstår vi att utöver sårbarheten i RemoteInvocationSerializingExporter i CVE-2011-2894 finns det också en sårbarhet i HttpInvokerServiceExporter. Det här säger Nexus IQ till oss:

Ändå finns inget liknande i NVD, vilket gör att Dependency Check och Dependency Track får falska negativa.

Även från beskrivningen av CVE-2011-2894 kan vi förstå att sårbarheten faktiskt finns i spring-context:3.0.5 och spring-core:3.0.5. Bekräftelse på detta kan hittas i artikeln av den som upptäckte sårbarheten.

Nr 2

Komponent
Sårbarhet
Resultat

struts2-core:2.3.30
CVE-2016-4003
FALSK

Om vi studerar sårbarheten CVE-2016-4003, så förstår vi att den åtgärdades redan i version 2.3.28, men ändå rapporterar Nexus IQ om den. I sårbarhetsbeskrivningen finns en anmärkning:

Det vill säga, sårbarheten finns endast i samband med en föråldrad version av JRE, vilket vi fick information om. Ändå anser vi att detta är en falsk positiv, även om det inte är det mest alarmerande.

Nr 3

Komponent
Sårbarhet
Resultat

xwork-core:2.3.30
CVE-2017-9804
SANN

xwork-core:2.3.30
CVE-2017-7672
FALSK

Om vi tittar på beskrivningen för CVE-2017-9804 och CVE-2017-7672, så förstår vi att problemet ligger i URLValidator class, och CVE-2017-9804 härstammar från CVE-2017-7672. Förekomsten av den andra sårbarheten medför ingen nyttig belastning förutom att dess allvarlighetsgrad ökade till hög, så detta kan ses som onödig störning.

Generellt har inga andra falska positiva för Nexus IQ hittats.

Nr 4

Det finns några punkter som särskiljer IQ från andra lösningar.

Komponent
Sårbarhet
Resultat

spring-web:3.0.5
CVE-2020-5398
SANN

CVE i NVD rapporterar att det endast är tillämpligt för versioner 5.2.x upp till 5.2.3, 5.1.x upp till 5.1.13, och versioner 5.0.x upp till 5.0.16, men om vi ser på CVE-beskrivningen i Nexus IQ kommer vi att se följande:
Advisory Deviation Notice: Sonatype säkerhetsforskningsgrupp upptäckte att denna sårbarhet introducerades i version 3.0.2.RELEASE och inte 5.0.x som anges i meddelandet.

Efter detta följer en PoC för denna sårbarhet, som rapporterar att den finns i version 3.0.5.

Falska negativa skickas till Dependency Check och Dependency Track.

Nr 5

Låt oss titta på falska positiva för Dependency Check och Dependency Track.

Dependency Check framhävs av att den speglar de CVE som gäller för hela ramverket i NVD, i de komponenter där dessa CVE inte är tillämpliga. Detta gäller CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, som Dependency Check "kopplade" till struts-taglib:1.3.8 och struts-tiles-1.3.8. Dessa komponenter har inget att göra med vad som beskrivs i CVE — hantering av förfrågningar, validering av sidor och så vidare. Detta beror på att det enda som förenar dessa CVE och komponenterna är ramverket, vilket är anledningen till att Dependency Check bedömde detta som en sårbarhet.

Samma situation med spring-tx:3.0.5, och en liknande situation med struts-core:1.3.8. För struts-core har Dependency Check och Dependency Track hittat många sårbarheter som egentligen gäller struts2-core, som i grund och botten är ett separat ramverk. I detta fall förstod Nexus IQ bilden korrekt och angav i de CVE som den gav att struts-core har nått slutet av livet och att man bör övergå till struts2-core.

№6

I vissa situationer är det orättvist att tolka den uppenbara felet i Dependency Check och Dependency Track. Särskilt CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, som Dependency Check och Dependency Track hänför till spring-core:3.0.5, gäller faktiskt spring-web:3.0.5. Samtidigt har Nexus IQ hittat några av dessa CVE, men IQ har korrekt identifierat dem för en annan komponent. Det faktum att dessa sårbarheter inte hittades i spring-core innebär inte att de inte finns i ramverket i allmänhet, och open source-verktyg har rimligt nog pekat på dessa sårbarheter (de missade bara lite).

Slutsatser

Som vi kan se ger en manuell granskning av riktigheten av de identifierade sårbarheterna inget entydigt resultat, vilket skapar tvetydiga situationer. Resultaten visar att Nexus IQ-lösningen har den lägsta graden av falska positiva och den största noggrannheten.

Detta beror främst på att Sonatype-teamet har utökat beskrivningen för varje CVE-sårbarhet från NVD i sina databaser, och angivit med exakthet till klass eller funktion av sårbarheten för varje version av komponenten, efter att ha genomfört ytterligare forskning (till exempel genom att kontrollera sårbarheter i äldre versioner av programvaran).

Även sårbarheterna som inte har kommit in i NVD, men ändå finns i Sonatype-databasen med SONATYPE-märkning, har en betydande inverkan på resultaten. Enligt rapporten Tillståndet för sårbarheter inom öppen källkod 2020 angående 45 % av de upptäckta sårbarheterna med öppen källkod rapporteras inte i NVD. Enligt WhiteSources databas publiceras endast 29 % av alla sårbarheter med öppen källkod, registrerade utanför NVD, i slutändan i den, så det är viktigt att också söka efter sårbarheter i andra källor.

Som ett resultat ger Dependency Check en stor mängd brus, där den missar en del sårbara komponenter. Dependency Track ger mindre brus och identifierar ett stort antal komponenter, vilket visuellt är mindre störande i webbgränssnittet.

Ändå visar praktiken att det är open source som bör vara det första steget mot en mogen DevSecOps. Det första man bör överväga för att integrera SCA i utvecklingen är processerna, det vill säga att tillsammans med ledningen och berörda avdelningar diskutera hur de ideala processerna bör se ut i organisationen. Det kan hända att det visar sig att Dependency Check eller Dependency Track till en början kommer att möta alla affärens behov, medan företagslösningar kommer att vara en logisk fortsättning på grund av den växande komplexiteten hos de utvecklade applikationerna.

Bilaga A. Resultat relaterade till komponenterna
Beteckningar:

High — sårbarheter av hög och kritisk nivå i komponenten
Medium — sårbarheter av medelhög kritikalitet i komponenten
TRUE — Korrekt identifierad sårbarhet (True positive issue)
FALSE — Falsk positiv (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Resultat

dom4j: 1.6.1
Hög
Hög
Hög
SANN

log4j-core: 2.3
Hög
Hög
Hög
SANN

log4j: 1.2.14
Hög
Hög
—
SANN

commons-collections:3.1
Hög
Hög
Hög
SANN

commons-fileupload:1.3.2
Hög
Hög
Hög
SANN

commons-beanutils:1.7.0
Hög
Hög
Hög
SANN

commons-codec:1:10
Medium
—
—
SANN

mysql-connector-java:5.1.42
Hög
Hög
Hög
SANN

spring-expression:3.0.5
Hög
komponenten hittades inte

SANN

spring-web:3.0.5
Hög
komponenten hittades inte
Hög
SANN

spring-context:3.0.5
Medium
komponenten hittades inte
—
SANN

spring-core:3.0.5
Medium
Hög
Hög
SANN

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

spring-tx:3.0.5
—
Hög
—
FALSK

struts-core:1.3.8
Hög
Hög
Hög
SANN

xwork-core: 2.3.30
Hög
—
—
SANN

struts2-core: 2.3.30
Hög
Hög
Hög
SANN

struts-taglib:1.3.8
—
Hög
—
FALSK

struts-tiles-1.3.8
—
Hög
—
FALSK

Bilaga B. Resultat relaterade till sårbarheterna
Beteckningar:

High — sårbarheter av hög och kritisk nivå i komponenten
Medium — sårbarheter av medelhög kritikalitet i komponenten
TRUE — Korrekt identifierad sårbarhet (True positive issue)
FALSE — Falsk positiv (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Svårighetsgrad
Resultat
Kommentar

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Hög
SANN

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Hög
SANN

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Hög
SANN

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Låg
SANN

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Hög
SANN

—
CVE-2020-9488
—
Låg
SANN

SONATYPE-2010-0053
—
—
Hög
SANN

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Hög
FALSK
Dubbelkopiering av RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Hög
FALSK
Dubbelkopiering av RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Hög
SANN

commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Hög
SANN

SONATYPE-2014-0173
—
—
Medium
SANN

commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Hög
SANN

—
CVE-2019-10086
CVE-2019-10086
Hög
FALSK
Sårbarheten gäller endast versioner 1.9.2+

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

mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Hög
SANN

CVE-2019-2692
CVE-2019-2692
—
Medium
SANN

—
CVE-2020-2875
—
Medium
FALSK
Samma sårbarhet som CVE-2019-2692, men med tillägget "attacker kan betydligt påverka ytterligare produkter"

—
CVE-2017-15945
—
Hög
FALSK
Gäller inte mysql-connector-java

—
CVE-2020-2933
—
Låg
FALSK
Dubbelkopiering av CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
—
Medium
SANN

spring-expression:3.0.5
CVE-2018-1270
komponenten hittades inte
—
Hög
SANN

CVE-2018-1257
—
—
Medium
SANN

spring-web:3.0.5
CVE-2016-1000027
komponenten hittades inte
—
Hög
SANN

CVE-2014-0225
—
CVE-2014-0225
Hög
SANN

CVE-2011-2730
—
—
Hög
SANN

—
—
CVE-2013-4152
Medium
SANN

CVE-2018-1272
—
—
Hög
SANN

CVE-2020-5398
—
—
Hög
SANN
Ett exempel som stödjer IQ: "Sonatype säkerhetsforskningsgrupp upptäckte att denna sårbarhet introducerades i version 3.0.2.RELEASE och inte 5.0.x som anges i meddelandet."

CVE-2013-6429
—
—
Medium
SANN

CVE-2014-0054
—
CVE-2014-0054
Medium
SANN

CVE-2013-6430
—
—
Medium
SANN

spring-context:3.0.5
CVE-2011-2894
komponenten hittades inte
—
Medium
SANN

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Hög
SANN

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
SANN

—
—
CVE-2013-4152
Medium
FALSK
Dubbelkopiering av samma sårbarhet i spring-web

—
CVE-2013-4152
—
Medium
FALSK
Sårbarheten gäller komponenten spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
FALSK
Sårbarheten gäller komponenten spring-web

—
CVE-2013-6430
—
Medium
FALSK
Sårbarheten gäller komponenten spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
FALSK
SPLIT från CVE-2013-4152. + Sårbarheten gäller komponenten spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
FALSK
Sårbarheten gäller komponenten spring-web

—
CVE-2014-0225
—
Hög
FALSK
Sårbarheten gäller komponenten spring-web

—
—
CVE-2014-0225
Hög
FALSK
Dubbelkopiering av samma sårbarhet i spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
FALSK
Sårbarheten gäller komponenten spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
FALSK
Sårbarheten gäller komponenten spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Hög
FALSK
Sårbarheten gäller komponenten spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Hög
FALSK
För spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medium
FALSK
Sårbarheten gäller komponenten spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Hög
SANN

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

SONATYPE-2015-0327
—
—
Låg
SANN

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

spring-tx:3.0.5
—
CVE-2011-2730
—
Hög
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2011-2894
—
Hög
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2013-4152
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2013-6429
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2013-6430
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2013-7315
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2014-0054
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2014-0225
—
Hög
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2014-1904
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2014-3625
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2016-9878
—
Hög
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2018-1270
—
Hög
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2018-1271
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

—
CVE-2018-1272
—
Medium
FALSK
Sårbarheten gäller inte spring-tx

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

Medium
FASLE
Sårbarhet angående Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Hög
FALSK
Sårbarhet angående Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSK
Sårbarhet angående Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Hög
FALSK
Sårbarhet angående Struts 2

CVE-2016-1182
3VE-2016-1182
—
Hög
SANN

—
—
CVE-2011-5057
Medium
FALSK
Sårbarhet angående Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Hög
FALSK
Sårbarhet angående Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSK
Sårbarhet angående Struts 2

CVE-2015-0899
CVE-2015-0899
—
Hög
SANN

—
CVE-2012-0394
CVE-2012-0394
Medium
FALSK
Sårbarhet angående Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Hög
FALSK
Sårbarhet angående Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Hög
FALSK
Sårbarhet angående Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Hög
FASLE
Sårbarhet angående Struts 2

—
CVE-2013-2115
CVE-2013-2115
Hög
FASLE
Sårbarhet angående Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Hög
FASLE
Sårbarhet angående Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Hög
FASLE
Sårbarhet angående Struts 2

CVE-2014-0114
CVE-2014-0114
—
Hög
SANN

—
CVE-2015-2992
CVE-2015-2992
Medium
FALSK
Sårbarhet angående Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Hög
FALSK
Sårbarhet angående Struts 2

CVE-2016-1181
CVE-2016-1181
—
Hög
SANN

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Hög
FALSK
Sårbarhet angående Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Hög
SANN

SONATYPE-2017-0173
—
—
Hög
SANN

CVE-2017-7672
—
—
Hög
FALSK
Dubbel till CVE-2017-9804

SONATYPE-2016-0127
—
—
Hög
SANN

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Hög
SANN

—
CVE-2017-9787
CVE-2017-9787
Hög
SANN

—
CVE-2017-9791
CVE-2017-9791
Hög
SANN

—
CVE-2017-9793
—
Hög
FALSK
Duplikat till CVE-2018-1327

—
CVE-2017-9804
—
Hög
SANN

—
CVE-2017-9805
CVE-2017-9805
Hög
SANN

CVE-2016-4003
—
—
Medium
FALSK
Tillämpligt för Apache Struts 2.x upp till 2.3.28, men detta är version 2.3.30. Ändå, enligt beskrivningen, gäller CVE för alla versioner av Struts 2 om JRE 1.7 eller lägre används. Det verkar som att man ville vara på den säkra sidan, men det känns mer som en FALSE

—
CVE-2018-1327
CVE-2018-1327
Hög
SANN

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Hög
SANN
Den sårbarhet som utnyttjades av angriparna i Equifax 2017

CVE-2017-12611
CVE-2017-12611
—
Hög
SANN

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Hög
SANN

struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
FALSK
För struts2-core

—
CVE-2013-2115
—
Hög
FALSK
För struts2-core

—
CVE-2014-0114
—
Hög
FALSK
För commons-beanutils

—
CVE-2015-0899
—
Hög
FALSK
Inte relaterat till taglib

—
CVE-2015-2992
—
Medium
FALSK
Relaterat till struts2-core

—
CVE-2016-1181
—
Hög
FALSK
Inte relaterat till taglib

—
CVE-2016-1182
—
Hög
FALSK
Inte relaterat till taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FALSK
För struts2-core