Betydelsen av analys av tredjeparts programvarukomponenter (Software Composition Analysis - SCA) i utvecklingsprocessen växer i takt med att årliga rapporter om sårbarheter i bibliotek med öppen källkod publiceras, som publiceras av Synopsys, Sonatype, Snyk och White Source . Enligt rapporten antalet identifierade sårbarheter med öppen källkod under 2019 ökade nästan 1.5 gånger jämfört med föregående år, medan komponenter med öppen källkod används av 60 % till 80 % av projekten. På oberoende basis är SCA-processer en separat praxis för OWASP SAMM och BSIMM som en indikator på mognad, och under första halvåret 2020 släppte OWASP den nya OWASP Software Component Verification Standard (SCVS), som ger bästa praxis för att verifiera tredje- partskomponenter i leveranskedjan BY.
Ett av de mest illustrativa fallen med Equifax i maj 2017. Okända angripare fick information om 143 miljoner amerikaner, inklusive fullständiga namn, adresser, personnummer och körkort. I 209 000 fall innehöll handlingarna även information om offrens bankkort. Denna läcka uppstod som ett resultat av utnyttjandet av en kritisk sårbarhet i Apache Struts 2 (CVE-2017-5638), medan korrigeringen släpptes i mars 2017. Företaget hade två månader på sig att installera uppdateringen, men ingen brydde sig om den.
Denna artikel kommer att diskutera frågan om att välja ett verktyg för att genomföra SCA utifrån kvaliteten på analysresultaten. En funktionell jämförelse av verktygen kommer också att tillhandahållas. Processen att integrera i CI/CD och integrationsmöjligheter kommer att lämnas till efterföljande publikationer. Ett brett utbud av verktyg presenterades av OWASP , men i den aktuella recensionen kommer vi bara att beröra det mest populära open source-verktyget Dependency Check, den lite mindre välkända open source-plattformen Dependency Track och Enterprise-lösningen Sonatype Nexus IQ. Vi kommer också att förstå hur dessa lösningar fungerar och jämföra resultaten som erhållits för falska positiva resultat.
Funktionsprincip
är ett verktyg (CLI, maven, jenkins modul, ant) som analyserar projektfiler, samlar in information om beroenden (paketnamn, gruppid, specifikationstitel, version...), bygger en CPE-linje (Common Platform Enumeration) , Package URL ( PURL) och identifierar sårbarheter för CPE/PURL från databaser (NVD, Sonatype OSS Index, NPM Audit API...), varefter den bygger en engångsrapport i HTML, JSON, XML-format...
Låt oss titta på hur CPE ser ut:
cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other- Del: Indikation på att komponenten relaterar till applikationen (a), operativsystem (o), hårdvara (h) (Obligatoriskt)
- Leverantör: Produkttillverkarens namn (obligatoriskt)
- Produkt: Produktnamn (obligatoriskt)
- Version: Komponentversion (föråldrad artikel)
- Uppdatering: Paketuppdatering
- Upplaga: Äldre version (utfasad artikel)
- språk: Språk definierat i RFC-5646
- SW Edition: Mjukvaru-version
- Mål SW: Programvarumiljö där produkten fungerar
- Mål HW: Hårdvarumiljön där produkten fungerar
- Andra: Leverantörs- eller produktinformation
Ett exempel på CPE ser ut så här:
cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*
Linjen betyder att CPE version 2.3 beskriver applikationskomponenten från tillverkaren pivotal_software med namnet spring_framework version 3.0.0. Om vi öppnar en sårbarhet i NVD kan vi se ett omnämnande av denna CPE. Det första problemet som du omedelbart bör uppmärksamma är att CVE i NVD, enligt CPE, rapporterar ett problem i ramverket, och inte i en specifik komponent. Det vill säga, om utvecklare är hårt bundna till ramverket, och den identifierade sårbarheten inte påverkar de moduler som utvecklarna använder, kommer en säkerhetsspecialist på ett eller annat sätt att behöva plocka isär denna CVE och tänka på att uppdatera.
URL:en används också av SCA-verktyg. Paketets URL-format är följande:
scheme:type/namespace/name@version?qualifiers#subpath- Schema: Det kommer alltid att finnas "pkg" som indikerar att detta är en paket-URL (obligatoriskt)
- Typ: "Typen" av paketet eller "protokollet" för paketet, såsom maven, npm, nuget, gem, pypi, etc. (Obligatoriskt föremål)
- Namnrymd: Vissa namnprefix, till exempel ett Maven-grupp-ID, Docker-bildägare, GitHub-användare eller organisation. Valfritt och beror på typ.
- Namn: Paketnamn (obligatoriskt)
- Version: Paketversion
- Qualifiers: Ytterligare kvalifikationsdata för paketet, såsom OS, arkitektur, distribution etc. Valfritt och typspecifikt.
- Undersökväg: Ytterligare sökväg i paketet i förhållande till paketroten
Till exempel:
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/[email protected]
pkg:pypi/[email protected]— en lokal webbplattform som accepterar färdiga stycklistor (BOM) genererade и , det vill säga färdiga specifikationer om befintliga beroenden. Detta är en XML-fil som beskriver beroenden - namn, hash, paket-url, utgivare, licens. Därefter analyserar Dependency Track BOM, tittar på de CVE:er som är tillgängliga för de identifierade beroenden från sårbarhetsdatabasen (NVD, Sonatype OSS Index...), varefter det bygger grafer, beräknar mätvärden, uppdaterar regelbundet data om komponenters sårbarhetsstatus .
Ett exempel på hur en BOM kan se ut i XML-format:
<?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 kan användas inte bara som indataparametrar för Dependency Track, utan också för inventering av mjukvarukomponenter i försörjningskedjan, till exempel för att tillhandahålla mjukvara till en kund. 2014 föreslogs till och med en lag i USA , som angav att när man köper programvara, någon stat. Institutionen ska begära en stycklista för att förhindra användning av sårbara komponenter, men lagen har ännu inte trätt i kraft.
Tillbaka till SCA har Dependency Track färdiga integrationer med Notification Platforms som Slack, sårbarhetshanteringssystem som Kenna Security. Det är också värt att säga att Dependency Track bland annat identifierar föråldrade versioner av paket och ger information om licenser (på grund av SPDX-stöd).
Om vi pratar specifikt om kvaliteten på SCA, så finns det en grundläggande skillnad.
Dependency Track accepterar inte projektet som input, utan snarare BOM. Det betyder att om vi vill testa projektet måste vi först generera bom.xml, till exempel med CycloneDX. Dependency Track är alltså direkt beroende av CycloneDX. Samtidigt möjliggör det anpassning. Detta är vad OZON-teamet skrev för sammansättning av BOM-filer för Golang-projekt för vidare skanning genom Dependency Track.
är en kommersiell SCA-lösning från Sonatype, som är en del av Sonatypes ekosystem, som även inkluderar Nexus Repository Manager. Nexus IQ kan acceptera som indata både krigsarkiv (för java-projekt) via webbgränssnittet eller API, och BOM, om din organisation ännu inte har bytt från CycloneDX till en ny lösning. Till skillnad från lösningar med öppen källkod hänvisar IQ inte bara till CP/PURL till den identifierade komponenten och motsvarande sårbarhet i databasen, utan tar även hänsyn till sin egen forskning, till exempel namnet på den sårbara funktionen eller klassen. Mekanismerna för IQ kommer att diskuteras senare i analysen av resultaten.
Låt oss sammanfatta några av de funktionella funktionerna och även överväga de språk som stöds för analys:
språk
Nexus IQ
Beroendekontroll
Beroendespår
java
+
+
+
C / C ++
+
+
-
C#
+
+
-
. Net
+
+
+
Erlang
-
-
+
JavaScript (NodeJS)
+
+
+
PHP
+
+
+
Python
+
+
+
Rubin
+
+
+
Perl
-
-
-
Skala
+
+
+
Mål C
+
+
-
Snabb
+
+
-
R
+
-
-
Go
+
+
+
funktionalitet
funktionalitet
Nexus IQ
Beroendekontroll
Beroendespår
Möjligheten att säkerställa att komponenter som används i källkoden kontrolleras för licensierad renhet
+
-
+
Möjlighet att skanna och analysera för sårbarheter och licensrenhet för Docker-bilder
+ Integration med Clair
-
-
Möjlighet att konfigurera säkerhetspolicyer för att använda bibliotek med öppen källkod
+
-
-
Möjlighet att skanna arkiv med öppen källkod 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
Tillgänglighet för en specialiserad forskargrupp
+
-
-
Drift med sluten slinga
+
+
+
Använda tredjepartsdatabaser
+ Stängd Sonatype-databas
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, stöd för sin egen sårbarhetsdatabas
Möjlighet att filtrera komponenter med öppen källkod när man försöker ladda in i utvecklingsslingan enligt konfigurerade policyer
+
-
-
Rekommendationer för att åtgärda sårbarheter, tillgänglighet av länkar till korrigeringar
+
+- (beror på beskrivningen i offentliga databaser)
+- (beror på beskrivningen i offentliga databaser)
Rangordning av upptäckta sårbarheter efter svårighetsgrad
+
+
+
Rollbaserad åtkomstmodell
+
-
+
CLI-stöd
+
+
+- (endast för CycloneDX)
Provtagning/sortering av sårbarheter enligt definierade kriterier
+
-
+
Instrumentpanel efter applikationsstatus
+
-
+
Generera rapporter i PDF-format
+
-
-
Genererar rapporter i JSONCSV-format
+
+
-
Ryska språkstöd
-
-
-
Integrationsmöjligheter
Интеграция
Nexus IQ
Beroendekontroll
Beroendespår
LDAP/Active Directory-integration
+
-
+
Integration med kontinuerligt integrationssystem Bamboo
+
-
-
Integration med kontinuerligt integrationssystem TeamCity
+
-
-
Integration med kontinuerligt integrationssystem GitLab
+
+- (som ett plugin för GitLab)
+
Integration med kontinuerligt integrationssystem Jenkins
+
+
+
Tillgänglighet av plugins för IDE
+ IntelliJ, Eclipse, Visual Studio
-
-
Stöd för anpassad integration via webbtjänster (API) av verktyget
+
-
+
Beroendekontroll
Första start
Låt oss köra beroendekontroll på en medvetet sårbar applikation .
För detta kommer vi att använda :
mvn org.owasp:dependency-check-maven:checkSom ett resultat kommer dependency-check-report.html att visas i målkatalogen.
Låt oss öppna filen. Efter sammanfattande information om det totala antalet sårbarheter kan vi se information om sårbarheter med en hög grad av allvarlighetsgrad och konfidens, som indikerar paketet, CPE och antalet CVE.
Därefter kommer mer detaljerad information, i synnerhet på vilket underlag beslutet fattades (bevisning), det vill säga en viss BOM.
Därefter kommer beskrivningen av CPE, PURL och CVE. Förresten, rekommendationer för korrigering ingår inte på grund av deras frånvaro i NVD-databasen.
För att systematiskt se skanningsresultat kan du konfigurera Nginx med minimala inställningar, eller skicka de resulterande defekterna till ett defekthanteringssystem som stöder kopplingar till beroendekontroll. Till exempel Defect Dojo.
Beroendespår
Installation
Dependency Track är i sin tur en webbaserad plattform med visningsdiagram, så den akuta frågan om att lagra defekter i en tredjepartslösning uppstår inte här.
De skript som stöds för installation är: Docker, WAR, Executable WAR.
Första start
Vi går till webbadressen till den körande tjänsten. Vi loggar in via admin/admin, ändrar inloggning och lösenord och kommer sedan till Dashboard. Nästa sak vi kommer att göra är att skapa ett projekt för en testapplikation i Java i Hem/Projekt → Skapa projekt . Låt oss ta DVJA som ett exempel.
Eftersom Dependency Track endast kan acceptera BOM som indata, måste denna BOM hämtas. Låt oss dra fördel :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBomVi hämtar bom.xml och laddar filen i det skapade projektet DVJA → Beroenden → Ladda upp stycklista.
Låt oss gå till Administration → Analysatorer. Vi förstår att vi bara har aktiverat Internal Analyzer, vilket inkluderar NVD. Låt oss också koppla Sonatype OSS Index.
Således får vi följande bild för vårt projekt:
I listan kan du också hitta en sårbarhet som är tillämplig på Sonatype OSS:
Den största besvikelsen var att Dependency Track inte längre accepterar Dependency Check xml-rapporter. De senaste stödda versionerna av Dependency Check-integrationen var 1.0.0 - 4.0.2, medan jag testade 5.3.2.
Här (och ) när det fortfarande var möjligt.
Nexus IQ
Första start
Installation av Nexus IQ kommer från arkiven av , men vi byggde en Docker-bild för dessa ändamål.
När du har loggat in på konsolen måste du skapa en organisation och en applikation.
Som du kan se är upplägget i fallet med IQ något mer komplicerat, eftersom vi också behöver skapa policyer som är tillämpliga för olika "stadier" (dev, build, stage, release). Detta är nödvändigt för att blockera sårbara komponenter när de rör sig genom pipelinen närmare produktion, eller för att blockera dem så snart de kommer in i Nexus Repo när de laddas ner av utvecklare.
För att känna skillnaden mellan öppen källkod och företag, låt oss utföra samma skanning genom Nexus IQ på samma sätt genom , efter att tidigare 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=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>
Följ webbadressen till den genererade rapporten i IQ-webbgränssnittet:
Här kan du se alla policyöverträdelser som indikerar olika signifikansnivåer (från Info till Säkerhetskritisk). Bokstaven D bredvid komponenten betyder att komponenten är Direct Dependency, och bokstaven T bredvid komponenten betyder att komponenten är Transitive Dependency, det vill säga den är transitiv.
Förresten, rapporten från Snyk rapporterar att mer än 70 % av sårbarheter med öppen källkod som upptäckts i Node.js, Java och Ruby är i transitiva beroenden.
Om vi öppnar en av Nexus IQ-policyöverträdelserna kan vi se en beskrivning av komponenten, samt en versionsgraf, som visar platsen för den aktuella versionen i tidsdiagrammet, samt vid vilken tidpunkt sårbarheten upphör att vara sårbar. Höjden på ljusen på grafen visar hur populärt det är att använda denna komponent.
Om du går till sårbarhetssektionen och utökar CVE kan du läsa en beskrivning av denna sårbarhet, rekommendationer för eliminering, såväl som anledningen till att denna komponent kränktes, det vill säga närvaron av klassen DiskFileitem.class.
Låt oss bara sammanfatta de som är relaterade till Java-komponenter från tredje part, och tar bort js-komponenterna. Inom parentes anger vi antalet sårbarheter som hittades utanför NVD.
Total Nexus IQ:
- Skannade beroenden: 62
- Sårbara beroenden: 16
- Sårbarheter hittade: 42 (8 sonatype db)
Total beroendekontroll:
- Skannade beroenden: 47
- Sårbara beroenden: 13
- Sårbarheter hittade: 91 (14 sonatype oss)
Totalt beroende spår:
- Skannade beroenden: 59
- Sårbara beroenden: 10
- Sårbarheter hittade: 51 (1 sonatype oss)
I nästa steg kommer vi att analysera resultaten och ta reda på vilken av dessa sårbarheter som är en verklig defekt och vilken som är en falsk positiv.
varning
Denna recension är inte en obestridlig sanning. Författaren hade inte som mål att lyfta fram ett separat instrument mot andras bakgrund. Syftet med granskningen var att visa funktionsmekanismerna för SCA-verktyg och sätt att kontrollera deras resultat.
Jämförelse av resultat
Regler och villkor:
En falsk positiv för sårbarheter i tredjepartskomponenter är:
- CVE-fel överensstämmer med identifierad komponent
- Till exempel, om en sårbarhet identifieras i ramverket för struts2, och verktyget pekar på en komponent i ramverket för struts-tiles, som denna sårbarhet inte gäller, är detta en falsk positiv
- CVE-fel överensstämmer med den identifierade versionen av komponenten
- Till exempel är sårbarheten kopplad till python version > 3.5 och verktyget markerar version 2.7 som sårbar - detta är en falsk positiv, eftersom sårbarheten i själva verket bara gäller produktgrenen 3.x
- Duplicera CVE
- Till exempel, om SCA specificerar en CVE som möjliggör en RCE, då specificerar SCA en CVE för samma komponent som gäller Cisco-produkter som påverkas av den RCE. I det här fallet blir det falskt positivt.
- Till exempel hittades en CVE i en spring-web-komponent, varefter SCA pekar på samma CVE i andra komponenter i Spring Framework, medan CVE inte har något att göra med andra komponenter. I det här fallet blir det falskt positivt.
Målet för studien var Open Source-projektet DVJA. Studien involverade endast java-komponenter (utan js).
Sammanfattande resultat
Låt oss gå direkt till resultatet av en manuell granskning av identifierade sårbarheter. Den fullständiga rapporten för varje CVE finns i bilagan.
Sammanfattningsresultat för alla sårbarheter:
Parameter
Nexus IQ
Beroendekontroll
Beroendespår
Totala sårbarheter identifierade
42
91
51
Felaktigt identifierade sårbarheter (falskt positivt)
2 (4.76%)
62 (68,13%)
29 (56.86%)
Inga relevanta sårbarheter hittades (falsk negativ)
10
20
27
Sammanfattning av resultat per komponent:
Parameter
Nexus IQ
Beroendekontroll
Beroendespår
Totalt identifierade komponenter
62
47
59
Totalt sårbara komponenter
16
13
10
Felaktigt identifierade sårbara komponenter (falskt positivt)
1
5
0
Felaktigt identifierade sårbara komponenter (falskt positivt)
0
6
6
Låt oss bygga visuella grafer för att utvärdera förhållandet mellan falskt positivt och falskt negativt till det totala antalet sårbarheter. Komponenter är markerade horisontellt och sårbarheter som identifieras i dem är markerade vertikalt.
Som jämförelse utfördes en liknande studie av Sonatype-teamet som testade ett projekt med 1531 komponenter med hjälp av OWASP Dependency Check. Som vi kan se är förhållandet mellan brus och korrekta svar jämförbart med våra resultat.
Källa:
Låt oss titta på några CVE från våra skanningsresultat för att förstå orsaken till dessa resultat.
Mer
№ 1
Låt oss först titta på några intressanta punkter om Sonatype Nexus IQ.
Nexus IQ påpekar ett problem med deserialisering med möjligheten att utföra RCE i Spring Framework flera gånger. CVE-2016-1000027 i spring-web:3.0.5 första gången, och CVE-2011-2894 i spring-context:3.0.5 och spring-core:3.0.5. Till en början verkar det som att det finns en dubblering av sårbarhet över flera CVE:er. För om du tittar på CVE-2016-1000027 och CVE-2011-2894 i NVD-databasen verkar det som att allt är uppenbart
komponent
Sårbarhet
spring-web:3.0.5
CVE-2016-1000027
spring-context:3.0.5
CVE-2011-2894
fjäderkärna:3.0.5
CVE-2011-2894
beskrivning från NVD:
beskrivning från NVD:
CVE-2011-2894 i sig är ganska känd. I rapporten denna CVE erkändes som en av de vanligaste. Beskrivningarna för CVE-2016-100027 är i princip få i NVD, och det verkar bara vara tillämpligt för Spring Framework 4.1.4. Låt oss ta en titt på och här blir allt mer eller mindre klart. Från Vi förstår att förutom sårbarheten i RemoteInvocationSerializingExporter i CVE-2011-2894 observeras sårbarheten i HttpInvokerServiceExporter. Detta är vad Nexus IQ säger till oss:
Det finns dock inget liknande i NVD, varför Dependency Check och Dependency Track får var och en falsk negativ.
Även från beskrivningen av CVE-2011-2894 kan det förstås att sårbarheten verkligen finns i både spring-context:3.0.5 och spring-core:3.0.5. Bekräftelse på detta finns i en artikel från personen som hittade denna sårbarhet.
№ 2
komponent
Sårbarhet
Resultat
fjäderben2-kärna:2.3.30
CVE-2016-4003
FALSK
Om vi studerar sårbarheten CVE-2016-4003 kommer vi att förstå att den åtgärdades i version 2.3.28, men Nexus IQ rapporterar det till oss. Det finns en notering i beskrivningen av sårbarheten:
Det vill säga, sårbarheten existerar endast i samband med en föråldrad version av JRE, som de bestämde sig för att varna oss för. Ändå anser vi detta som falskt positivt, även om det inte är det värsta.
Nej. 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å beskrivningarna av CVE-2017-9804 och CVE-2017-7672 kommer vi att förstå att problemet är URLValidator class, med CVE-2017-9804 härrörande från CVE-2017-7672. Förekomsten av den andra sårbarheten har ingen användbar belastning förutom det faktum att dess svårighetsgrad har ökat till Hög, så vi kan betrakta det som onödigt brus.
Sammantaget hittades inga andra falska positiva resultat för Nexus IQ.
№ 4
Det finns flera saker som gör att IQ sticker ut från andra lösningar.
komponent
Sårbarhet
Resultat
spring-web:3.0.5
CVE-2020-5398
SANN
CVE i NVD anger att det endast gäller versioner 5.2.x före 5.2.3, 5.1.x före 5.1.13 och versioner 5.0.x före 5.0.16, dock om vi tittar på CVE-beskrivningen i Nexus IQ , då ser vi följande:
Meddelande om rådgivande avvikelse: Sonatypes säkerhetsforskningsteam upptäckte att denna sårbarhet introducerades i version 3.0.2.RELEASE och inte 5.0.x som anges i meddelandet.
Detta följs av en PoC för denna sårbarhet, som anger att den finns i version 3.0.5.
Falskt negativ skickas till beroendekontroll och beroendespår.
№ 5
Låt oss titta på falskt positivt för beroendekontroll och beroendespår.
Dependency Check utmärker sig genom att den återspeglar de CVE:er som gäller för hela ramverket i NVD för de komponenter som dessa CVE:er inte gäller. Detta gäller CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, vilket beroendekontroll ” till struts-taglib:1.3.8 och struts-tiles-1.3.8. Dessa komponenter har ingenting att göra med vad som beskrivs i CVE - begäran bearbetning, sida validering, och så vidare. Detta beror på att det som dessa CVE:er och komponenter har gemensamt endast är ramverket, varför Dependency Check ansåg att det var en sårbarhet.
Samma situation är 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 faktiskt är tillämpliga på struts2-core, som i huvudsak är ett separat ramverk. I det här fallet förstod Nexus IQ bilden korrekt och i de CVE som den utfärdade indikerade det att struts-core hade nått slutet av livet och att det var nödvändigt att flytta till struts2-core.
№ 6
I vissa situationer är det orättvist att tolka ett uppenbart beroendekontroll- och beroendespårningsfel. I synnerhet CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, vilka spårningskontroll och beroendekontroll tillskriven spring-core:3.0.5 tillhör faktiskt spring-web:3.0.5. Samtidigt hittades några av dessa CVEs också av Nexus IQ, men IQ identifierade dem korrekt till en annan komponent. Eftersom dessa sårbarheter inte hittades i spring-core kan det inte hävdas att de inte är i ramverket i princip och open source-verktyg påpekade med rätta dessa sårbarheter (de missade bara lite).
Resultat
Som vi kan se ger det inte entydiga resultat att fastställa tillförlitligheten hos identifierade sårbarheter genom manuell granskning, varför kontroversiella frågor uppstår. Resultaten är att Nexus IQ-lösningen har den lägsta falska positiva frekvensen och den högsta noggrannheten.
Först och främst beror detta på det faktum att Sonatype-teamet utökade beskrivningen för varje CVE-sårbarhet från NVD i sina databaser, vilket indikerar sårbarheterna för en viss version av komponenterna ner till klassen eller funktionen, utför ytterligare forskning (till exempel , kontrollera sårbarheter i äldre programversioner).
En viktig inverkan på resultaten spelas också av de sårbarheter som inte ingick i NVD, men som ändå finns i Sonatype-databasen med SONATYPE-märket. Enligt rapporten 45 % av upptäckta sårbarheter med öppen källkod rapporteras inte till NVD. Enligt WhiteSource-databasen hamnar endast 29 % av alla sårbarheter med öppen källkod som rapporteras utanför NVD publicerade där, varför det är viktigt att även leta efter sårbarheter i andra källor.
Som ett resultat producerar Dependency Check mycket brus och saknar några sårbara komponenter. Dependency Track producerar mindre brus och upptäcker ett stort antal komponenter, vilket inte visuellt skadar ögonen i webbgränssnittet.
Praxis visar dock att öppen källkod bör bli de första stegen mot mogna DevSecOps. Det första du bör tänka på när du integrerar SCA i utvecklingen är processer, nämligen att tillsammans med ledning och relaterade avdelningar tänka på hur idealiska processer ska se ut i din organisation. Det kan visa sig att för din organisation till en början kommer Dependency Check eller Dependency Track att täcka alla affärsbehov, och Enterprise-lösningar kommer att vara en logisk fortsättning på grund av den växande komplexiteten hos de applikationer som utvecklas.
Bilaga A: Komponentresultat
legend:
- Hög-hög och kritisk nivå sårbarheter i komponenten
- Medium — Sårbarheter på medelhög kritiskhetsnivå i komponenten
- TRUE — Sann positiv fråga
- FALSK — Falsk positiv fråga
komponent
Nexus IQ
Beroendekontroll
Beroendespår
Resultat
dom4j: 1.6.1
Hög
Hög
Hög
SANN
log4j-kärna: 2.3
Hög
Hög
Hög
SANN
log4j: 1.2.14
Hög
Hög
-
SANN
allmänningar-samlingar: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
fjäder-uttryck:3.0.5
Hög
komponent hittades inte
SANN
spring-web:3.0.5
Hög
komponent hittades inte
Hög
SANN
spring-context:3.0.5
Medium
komponent hittades inte
-
SANN
fjäderkärna: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
fjäderbenskärna:1.3.8
Hög
Hög
Hög
SANN
xwork-core: 2.3.30
Hög
-
-
SANN
fjäderben2-kärna: 2.3.30
Hög
Hög
Hög
SANN
struts-taglib:1.3.8
-
Hög
-
FALSK
stag-plattor-1.3.8
-
Hög
-
FALSK
Bilaga B: Sårbarhetsresultat
legend:
- Hög-hög och kritisk nivå sårbarheter i komponenten
- Medium — Sårbarheter på medelhög kritiskhetsnivå i komponenten
- TRUE — Sann positiv fråga
- FALSK — Falsk positiv fråga
komponent
Nexus IQ
Beroendekontroll
Beroendespår
Svårighetsgraden
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-kärna: 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
allmänningar-samlingar:3.1
-
CVE-2015-6420
CVE-2015-6420
Hög
FALSK
Duplicerar RCE(OSSINDEX)
-
CVE-2017-15708
CVE-2017-15708
Hög
FALSK
Duplicerar 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 version 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 anteckningen "attacker kan avsevärt påverka ytterligare produkter"
-
CVE-2017-15945
-
Hög
FALSK
Inte relevant för mysql-connector-java
-
CVE-2020-2933
-
Låg
FALSK
Duplikat av CVE-2020-2934
CVE-2020-2934
CVE-2020-2934
-
Medium
SANN
fjäder-uttryck:3.0.5
CVE-2018-1270
komponent hittades inte
-
Hög
SANN
CVE-2018-1257
-
-
Medium
SANN
spring-web:3.0.5
CVE-2016-1000027
komponent 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 belysande exempel till förmån för IQ: "Sonatypes säkerhetsforskningsteam upptäckte att denna sårbarhet introducerades i version 3.0.2.RELEASE och inte 5.0.x som anges i rådgivningen."
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
komponent hittades inte
-
Medium
SANN
fjäderkärna: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
Duplikat av samma sårbarhet i spring-web
-
CVE-2013-4152
-
Medium
FALSK
Sårbarheten relaterar till spring-web-komponenten
-
CVE-2013-6429
CVE-2013-6429
Medium
FALSK
Sårbarheten relaterar till spring-web-komponenten
-
CVE-2013-6430
-
Medium
FALSK
Sårbarheten relaterar till spring-web-komponenten
-
CVE-2013-7315
CVE-2013-7315
Medium
FALSK
SPLIT från CVE-2013-4152. + Sårbarheten relaterar till spring-web-komponenten
-
CVE-2014-0054
CVE-2014-0054
Medium
FALSK
Sårbarheten relaterar till spring-web-komponenten
-
CVE-2014-0225
-
Hög
FALSK
Sårbarheten relaterar till spring-web-komponenten
-
-
CVE-2014-0225
Hög
FALSK
Duplikat av samma sårbarhet i spring-web
-
CVE-2014-1904
CVE-2014-1904
Medium
FALSK
Sårbarheten relaterar till spring-web-mvc-komponenten
-
CVE-2014-3625
CVE-2014-3625
Medium
FALSK
Sårbarheten relaterar till spring-web-mvc-komponenten
-
CVE-2016-9878
CVE-2016-9878
Hög
FALSK
Sårbarheten relaterar till spring-web-mvc-komponenten
-
CVE-2018-1270
CVE-2018-1270
Hög
FALSK
För vår-uttryck/vår-meddelanden
-
CVE-2018-1271
CVE-2018-1271
Medium
FALSK
Sårbarheten relaterar till spring-web-mvc-komponenten
-
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 är inte specifik för spring-tx
-
CVE-2011-2894
-
Hög
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2013-4152
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2013-6429
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2013-6430
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2013-7315
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2014-0054
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2014-0225
-
Hög
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2014-1904
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2014-3625
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2016-9878
-
Hög
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2018-1270
-
Hög
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2018-1271
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
-
CVE-2018-1272
-
Medium
FALSK
Sårbarheten är inte specifik för spring-tx
fjäderbenskärna:1.3.8
-
CVE-2011-5057 (OSSINDEX)
Medium
FASLE
Sårbarhet för stöttor 2
-
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Hög
FALSK
Sårbarhet för stöttor 2
-
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSK
Sårbarhet för stöttor 2
-
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Hög
FALSK
Sårbarhet för stöttor 2
CVE-2016-1182
3VE-2016-1182
-
Hög
SANN
-
-
CVE-2011-5057
Medium
FALSK
Sårbarhet för stöttor 2
-
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Hög
FALSK
Sårbarhet för stöttor 2
-
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSK
Sårbarhet för stöttor 2
CVE-2015-0899
CVE-2015-0899
-
Hög
SANN
-
CVE-2012-0394
CVE-2012-0394
Medium
FALSK
Sårbarhet för stöttor 2
-
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Hög
FALSK
Sårbarhet för stöttor 2
-
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Hög
FALSK
Sårbarhet för stöttor 2
-
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Hög
FASLE
Sårbarhet för stöttor 2
-
CVE-2013-2115
CVE-2013-2115
Hög
FASLE
Sårbarhet för stöttor 2
-
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Hög
FASLE
Sårbarhet för stöttor 2
-
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Hög
FASLE
Sårbarhet för stöttor 2
CVE-2014-0114
CVE-2014-0114
-
Hög
SANN
-
CVE-2015-2992
CVE-2015-2992
Medium
FALSK
Sårbarhet för stöttor 2
-
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Hög
FALSK
Sårbarhet för stöttor 2
CVE-2016-1181
CVE-2016-1181
-
Hög
SANN
-
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Hög
FALSK
Sårbarhet för stöttor 2
xwork-core:2.3.30
CVE-2017-9804
-
-
Hög
SANN
SONATYPE-2017-0173
-
-
Hög
SANN
CVE-2017-7672
-
-
Hög
FALSK
Duplikat av CVE-2017-9804
SONATYPE-2016-0127
-
-
Hög
SANN
fjäderben2-kärna: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 av CVE-2018-1327
-
CVE-2017-9804
-
Hög
SANN
-
CVE-2017-9805
CVE-2017-9805
Hög
SANN
CVE-2016-4003
-
-
Medium
FALSK
Gäller för Apache Struts 2.x upp till 2.3.28, vilket är version 2.3.30. Baserat på beskrivningen är CVE dock giltig för alla versioner av Struts 2 om JRE 1.7 eller mindre används. Tydligen bestämde de sig för att återförsäkra oss här, men det ser mer ut som FALKT
-
CVE-2018-1327
CVE-2018-1327
Hög
SANN
CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Hög
SANN
Samma sårbarhet som Equifax hackare utnyttjade 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 fjäderben 2-kärna
-
CVE-2013-2115
-
Hög
FALSK
För fjäderben 2-kärna
-
CVE-2014-0114
-
Hög
FALSK
För commons-beanutils
-
CVE-2015-0899
-
Hög
FALSK
Gäller inte taglib
-
CVE-2015-2992
-
Medium
FALSK
Avser struts2-core
-
CVE-2016-1181
-
Hög
FALSK
Gäller inte taglib
-
CVE-2016-1182
-
Hög
FALSK
Gäller inte taglib
stag-plattor-1.3.8
-
CVE-2012-0394
-
Medium
FALSK
För fjäderben 2-kärna
-
CVE-2013-2115
-
Hög
FALSK
För fjäderben 2-kärna
-
CVE-2014-0114
-
Hög
FALSK
Under commons-beanutils
-
CVE-2015-0899
-
Hög
FALSK
Gäller inte kakel
-
CVE-2015-2992
-
Medium
FALSK
För fjäderben 2-kärna
-
CVE-2016-1181
-
Hög
FALSK
Gäller inte taglib
-
CVE-2016-1182
-
Hög
FALSK
Gäller inte taglib
Källa: will.com