DevSecOps: arbejdsprincipper og sammenligning af SCA. Del 1

Vigtigheden af analyse af tredjeparts softwarekomponenter (engelsk: Software Composition Analysis — SCA) i udviklingsprocessen vokser i takt med de årlige rapporter om sårbarheder i open source-biblioteker, som offentliggøres af virksomheder som Synopsys, Sonatype, Snyk og White Source. Ifølge rapporten Status for sikkerhedssårbarheder i open source 2020 er antallet af identificerede sårbarheder i open source steget med næsten 1,5 gange i 2019 sammenlignet med året før, mens komponenter med åben kildekode anvendes i 60% til 80% af projekterne. Ifølge uafhængig vurdering er SCA-processer en separat praksis i OWASP SAMM og BSIMM som et mål for modenhed, og i første halvdel af 2020 udgav OWASP den nye standard OWASP Software Component Verification Standard (SCVS), der giver bedste praksis til kontrol af tredjeparts komponenter i softwareforsyningskæden.

Et af de mest illustrative tilfælde skete er med virksomheden Equifax i maj 2017. Ukendte angribere fik fat i oplysninger om 143 millioner amerikanere, herunder fulde navne, adresser, social sikringsnumre og kørekortsnumre. I 209.000 tilfælde var der også oplysninger om ofrenes bankkort i dokumenterne. Denne lækage opstod som følge af udnyttelse af en kritisk sårbarhed i Apache Struts 2 (CVE-2017-5638), mens en korrektiv løsningspakke blev offentliggjort allerede i marts 2017. Virksomheden havde to måneder til at installere opdateringen, men ingen tog sig af dette.

I denne artikel vil vi diskutere valget af værktøjer til at udføre SCA set fra analysekvaliteten. Vi vil også give en funktionsmæssig sammenligning af værktøjerne. Processen for integration i CI/CD og integrationsmuligheder vil blive efterladt til kommende publikationer. En omfattende liste over værktøjer blev præsenteret af OWASP på deres hjemmeside, men i denne oversigt vil vi kun berøre det mest populære open source-værktøj, Dependency Check, den lidt mindre kendte open source-platform, Dependency Track, og enterprise-løsningen Sonatype Nexus IQ. Vi vil også undersøge, hvordan disse løsninger fungerer og sammenligne de opnåede resultater med hensyn til falske positiver.

Arbejdets princip

Dependency Check — er et værktøj (CLI, maven, jenkins modul, ant), som analyserer projektfiler, indsamler fragmenter af information om afhængigheder (pakke navn, groupid, specifikation titel, version…), opbygger en CPE-streng — (Common Platform Enumeration), Package URL (PURL) og identificerer sårbarheder for CPE/PURL fra databaser (NVD, Sonatype OSS Index, NPM Audit API…), hvorefter det genererer en engangsrapport i formatet HTML, JSON, XML…

Lad os se på, hvordan CPE ser ud:

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

• Part: Angiver, at komponenten tilhører en applikation (a), operativsystem (o), hardware (h) (Obligatorisk felt)
• Vendor: Navnet på produktets producent (Obligatorisk felt)
• Product: Navnet på produktet (Obligatorisk felt)
• Version: Version af komponenten (Forældet felt)
• Opdatering: Pakkens opdatering
• Edition: Arvet version (Forældet felt)
• Language: Sprog defineret i RFC-5646
• SW Edition: Version af software
• Target SW: Den softwaremiljø, hvor produktet kører
• Target HW: Den hardwaremiljø, hvor produktet kører
• Other: Information om leverandøren eller produktet

Et eksempel på CPE ser således ud:

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

Strengen betyder, at CPE version 2.3 beskriver en komponent applikation fra producenten pivotal_software med navnet spring_framework version 3.0.0. Hvis vi åbner sårbarheden CVE-2014-0225 i NVD, kan vi se henvisningen til denne CPE. Det første problem, som straks skal bemærkes — CVE i NVD rapporterer ifølge CPE om et problem i rammeværket og ikke i en specifik komponent. Det vil sige, hvis udviklerne er stærkt afhængige af rammeværket, og den identificerede sårbarhed vedrører ikke de moduler, som udviklerne bruger, må sikkerhedsspecialisten så eller så måtte analysere denne CVE og overveje opdatering.

URL-adressen bruges også af SCA-værktøjer. Formatet for URL-adressen på pakken er som følger:

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

• Scheme: Vil altid være ‘pkg’, der angiver, at dette er URL-adressen påpakken (Obligatorisk felt)
• Type: »Type« af pakken eller »protokol« for pakken, som f.eks. maven, npm, nuget, gem, pypi osv. (Obligatorisk felt)
• Namespace: En form for præfiks af navnet, såsom Maven-gruppe-id, ejer af Docker-billede, bruger eller organisation på GitHub. Valgfrit og afhænger af typen.
• Navn: Pakkenavn (Obligatorisk felt)
• Version: Version af pakken
• Qualifiers: Yderligere kvalifikationsoplysninger for pakken, såsom OS, arkitektur, distribution osv. Valgfrit og afhængigt af typen.
• Substi Yderligere sti i pakken relativt til roden af pakken.

For eksempel:

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 on-premise webplatform, der modtager klare Bill of Materials (BOM) dannet CycloneDX og SPDX, altså klare specifikationer af de tilgængelige afhængigheder. Dette er en XML-fil, der beskriver afhængigheder — navn, hashes, paket-URL, udgiver, licens. Derefter analyserer Dependency Track BOM, ser på de eksisterende CVE’er for identificerede afhængigheder fra databasen med sårbarheder (NVD, Sonatype OSS Index …), hvorefter den bygger grafer, beregner målinger og opdaterer oplysninger om komponenternes sårbarhedsstatus regelmæssigt.

Et eksempel på, hvordan en BOM i XML-format kan se ud:

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 bruges ikke kun som inputparametre til Dependency Track, men også til at opgøre softwarekomponenter i forsyningskæden, for eksempel til at levere til kunden. I 2014 blev der endda foreslået en lov i USA, «Cyber Supply Chain Management and Transparency Act of 2014», som sagde, at ved indkøb af software skulle enhver offentlig institution anmode om en BOM for at forhindre brugen af sårbare komponenter, men loven trådte aldrig i kraft.

Når vi vender tilbage til SCA, har Dependency Track klare integrationer med meddelelsesplatforme som Slack og systemer til sårbarhedsstyring som Kenna Security. Det skal også nævnes, at Dependency Track desuden identificerer forældede versioner af pakker og giver oplysninger om licenser (takket være understøttelsen af SPDX).

Når det kommer til kvaliteten af SCA, er der en væsentlig forskel her.

Dependency Track modtager ikke projektet som input, men tager faktisk imod BOM. Det betyder, at hvis vi ønsker at kontrollere projektet, skal vi først generere bom.xml, såsom ved at bruge CycloneDX. På den måde afhænger Dependency Track direkte af CycloneDX. Samtidig giver det muligheder for tilpasning. Så teamet fra OZON skrev modulet CycloneDX til opbygning af BOM-filer for projekter i Golang med henblik på senere scanning gennem Dependency Track.

Nexus IQ er en kommerciel SCA-løsning fra Sonatype, som er en del af Sonatype-økosystemet, der også inkluderer Nexus Repository Manager. Nexus IQ kan tage både war-arkiver (til java-projekter) som input via webgrænsefladen eller API, men også BOM, hvis din organisation ikke har haft tid til at omlægge fra CycloneDX til den nye løsning. I modsætning til open source-løsninger tager IQ ikke kun højde for CP/PURL til den identificerede komponent og den relevante sårbarhed i databasen, men overvejer også egne undersøgelser, for eksempel navnet på den sårbare funktion eller klasse. Mekanismerne i IQ vil blive gennemgået senere, når vi analyserer resultaterne.

Lad os opsummere nogle af de funktionelle egenskaber samt se på understøttede sprog til analyse:

Sprog
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Funktionelle muligheder

Funktionelle muligheder
Nexus IQ
Dependency Check
Dependency Track

Mulighed for at sikre verificering af komponenter brugt i kildekoden for licensmæssig renhed
+
—
+

Mulighed for scanning og analyse af sårbarheder og licensmæssig renhed for Docker-billeder
+ Integration med Clair
—
—

Mulighed for at tilpasse sikkerhedspolitikker for brug af open source-biblioteker
+
—
—

Mulighed for at scanne open source-repositorier for sårbare komponenter
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Eksistensen af en specialiseret forskningsgruppe
+
—
—

Arbejder i et lukket kontur
+
+
+

Brug af tredjeparts databaser
+ Lukket Sonatype DB
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, støtte til egen sårbarheds-DB

Mulighed for at filtrere open source-komponenter ved forsøg på at uploade i udviklingskonturen i henhold til konfigurerede politikker
+
—
—

Anbefalinger til afhjælpning af sårbarheder, med links til rettelser
+
+- (afhængigt af beskrivelsen i offentlige databaser)
+- (afhængigt af beskrivelsen i offentlige databaser)

Rangering af opdagede sårbarheder efter alvorlighedsgrad
+
+
+

Adgangsrollemodel
+
—
+

Understøttelse af kommandolinjegrænseflade (CLI)
+
+
+- (kun for CycloneDX)

Udvælgelse / sortering af sårbarheder efter bestemte kriterier
+
—
+

Dashboard over applikationernes tilstand
+
—
+

Generering af rapporter i PDF-format
+
—
—

Generering af rapporter i JSON og CSV-format
+
+
—

Understøttelse af dansk sprog
—
—
—

Integrationsmuligheder

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
+
+- (som plugin til GitLab)
+

Integration med kontinuerlig integrationssystem (Continous Integration) Jenkins
+
+
+

Tilgængelighed af plugins til IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Understøttelse af tilpasset integration gennem webservices (API) værktøj
+
—
+

Dependency Check

Første opstart

Lad os køre Dependency Check på en med vilje sårbar applikation DVJA.

For dette vil vi bruge Dependency Check Maven Plugin:

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

Som resultat vil der i mappen target blive oprettet dependency-check-report.html.

Lad os åbne filen. Efter den overordnede information om det samlede antal sårbarheder kan vi se information om sårbarheder med høj alvorlighedsgrad og tillid, angivet på pakken, CPE, antal CVE.

Derefter følger mere detaljeret information, herunder hvad beslutningen er baseret på (evidence), altså en slags BOM.

Dernæst kommer CPE, PURL og beskrivelse af CVE. Anbefalinger til rettelse følger faktisk ikke, da de mangler i NVD-databasen.

For systematisk gennemgang af scanningsresultater kan man konfigurere Nginx med minimal konfiguration, eller sende de indsamlede fejl til et fejlstyringssystem, som understøtter forbindelser til Dependency Check. For eksempel Defect Dojo.

Dependency Track

Installation

Dependency Track er i øvrigt en webplatform med grafisk visualisering, så problemet med opbevaring af fejl i en ekstern løsning er ikke relevant her.
Der er følgende understøttede installationsscenarier: Docker, WAR, Executable WAR.

Første opstart

Vi går til URL'en for den kørende tjeneste. Logger ind via admin/admin, ændrer brugernavn og kodeord, hvorefter vi kommer til Dashboard. Næste skridt bliver at oprette et projekt for den testapplikation i Home / Projects → Opret Projekt . Som eksempel bruger vi DVJA.

Da Dependency Track kun kan modtage BOM som input, skal denne BOM opnås. Vi vil bruge CycloneDX Maven Plugin:

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

Vi får bom.xml og uploader filen i det oprettede projekt DVJA → Afhængigheder → Upload BOM.

Lad os gå ind i Administration → Analyzers. Vi forstår, at vi kun har den interne analyser aktiveret, som inkluderer NVD. Vi tilslutter også Sonatype OSS Index.

Dermed får vi følgende oversigt over vores projekt:

Også på listen kan man finde en sårbarhed, der gælder for Sonatype OSS:

Den største skuffelse var, at Dependency Track ikke længere accepterer xml-rapporter fra Dependency Check. De seneste understøttede versioner til integration med Dependency Check var 1.0.0 – 4.0.2, mens jeg testede 5.3.2.

Her er en video (og her), da det stadig var muligt.

Nexus IQ

Første opstart

Installation af Nexus IQ sker fra arkiverne ved dokumentationen, men vi har oprettet et Docker-billede til disse formål.

Efter login til konsollen skal der oprettes en Organisation og en Applikation.

Som man kan se, er opsætningen i forhold til IQ noget mere kompleks, da vi også skal oprette politikker, der gælder for forskellige "faser" (dev, build, stage, release). Dette er nødvendigt for at blokere sårbare komponenter, efterhånden som de bevæger sig gennem pipeline tættere på produktionen, eller blokere dem så snart de kommer ind i Nexus Repo ved download af udviklerne.

For at mærke forskellen mellem open source og enterprise, lad os udføre den samme scanning gennem Nexus IQ tilsvarende gennem Maven plugin, efter først at have oprettet en testapplikation i NexusIQ-grænsefladen 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 navigerer til URL'en til den genererede rapport i IQ webgrænsefladen:

Her kan man se alle politikovertrædelser med angivelse af forskellige niveauer af alvorlighed (fra Info til Security Critical). D-brevet ved komponenten betyder, at komponenten er en Direct Dependency, mens T-brevet ved komponenten betyder, at komponenten er en Transitive Dependency, det vil sige er transitive.

For resten rapporterer State of Open Source Security Report 2020 fra Snyk, at over 70% af de sårbarheder i open source, der findes i Node.js, Java og Ruby, ligger i transitive afhængigheder.

Hvis man åbner en af politikovertrædelserne i Nexus IQ, kan vi se beskrivelsen af komponenten samt Version Graph, der viser placeringen af den nuværende version i tidsgrafen, og hvornår sårbarheden ikke længere er sårbar. Højden af søjlerne på grafen viser populariteten af brugen af denne komponent.

Hvis du går til sektionen for sårbarheder og åbner CVE, kan du læse beskrivelsen af denne sårbarhed, anbefalinger til afhjælpning samt årsagen til, at denne komponent er blevet identificeret som en overtrædelse, nemlig tilstedeværelsen af en klasse DiskFileitem.class.

Lad os opsummere, men kun vedrørende tredjeparts Java-komponenter, uden at inkludere js-komponenter. I parentes angiver vi antallet af sårbarheder, der er fundet uden for NVD.

I alt Nexus IQ:

• Scannede afhængigheder: 62
• Sårbare afhængigheder: 16
• Findede sårbarheder: 42 (8 sonatype db)

I alt Dependency Check:

• Scannede afhængigheder: 47
• Sårbare afhængigheder: 13
• Findede sårbarheder: 91 (14 sonatype oss)

I alt Dependency Track:

• Scannede afhængigheder: 59
• Sårbare afhængigheder: 10
• Findede sårbarheder: 51 (1 sonatype oss)

Næste skridt vil være at analysere de opnåede resultater og finde ud af, hvilke af disse sårbarheder der er virkelige defekter, og hvilke der er falske positiver.

Fraskrivelse

Denne gennemgang er ikke en uomtvistelig sandhed. Forfatteren havde ikke til hensigt at fremhæve et bestemt værktøj i forhold til andre. Formålet med gennemgangen var at vise, hvordan SCA-værktøjerne fungerer og måderne at verificere deres resultater på.

Sammenligning af resultater

Betingelser:

Et falsk positivt resultat i forhold til sårbarheder i tredjeparts komponenter er:

• Ikke-overensstemmelse mellem CVE og den identificerede komponent
• For eksempel, hvis en sårbarhed er identificeret i struts2-rammen, men værktøjet angiver komponenten struts-tiles, som denne sårbarhed ikke vedrører, så er det en falsk positiv.
• Ikke-overensstemmelse mellem CVE og den identificerede version af komponenten
• For eksempel, hvis sårbarheden er knyttet til versionen python > 3.5, og værktøjet angiver version 2.7 som sårbar, så er det en falsk positiv, da sårbarheden faktisk kun vedrører 3.x produktlinjen.
• Dublering af CVE
• For eksempel, hvis SCA angivet en CVE, der muliggør RCE, hvorefter SCA angiver den samme CVE for denne komponent, der gælder for Cisco-produkter, som er sårbare overfor denne RCE. I sådanne tilfælde vil det være en falsk positiv.
• For eksempel, hvis CVE blev fundet i komponenten spring-web, hvorefter SCA angiver denne samme CVE i andre komponenter i Spring Framework, mens CVE ikke vedrører de andre komponenter. I så fald vil det være en falsk positiv.

Undersøgelsen fokuserer på det Open Source-projekt DVJA. Undersøgelsen involverede kun Java-komponenter (uden js).

Sammenfattende resultater

Lad os straks gå til resultaterne af den manuelle gennemgang af de identificerede sårbarheder. Du kan finde den fulde rapport for hver CVE i Bilag.

Sammenfattende resultater for alle sårbarheder:

Parameter
Nexus IQ
Dependency Check
Dependency Track

I alt identificerede sårbarheder
42
91
51

Forkert identificerede sårbarheder (falsk positiv)
2(4.76%)
62(68,13%)
29(56.86%)

Ingen relevante sårbarheder identificeret (falsk negativ)
10
20
27

Sammenfattende resultater for komponenter:

Parameter
Nexus IQ
Dependency Check
Dependency Track

I alt identificerede komponenter
62
47
59

I alt sårbare komponenter
16
13
10

Forkert identificerede sårbare komponenter (falsk positiv)
1
5
0

Forkert identificerede sårbare komponenter (falsk positiv)
0
6
6

Vi vil bygge visuelle grafer for at vurdere forholdet mellem falske positive og falske negative i forhold til det samlede antal sårbarheder. Komponenterne er angivet vandret, og de identificerede sårbarheder er angivet lodret.

Til sammenligning blev en tilsvarende undersøgelse udført af Sonatype-teamet ved testning af et projekt bestående af 1531 komponenter ved hjælp af OWASP Dependency Check. Som vi kan se, er forholdet mellem støj og korrekte udløser meget sammenligneligt med vores resultater.

Kilde: www.sonatype.com/why-precision-matters-ebook

Lad os se på nogle CVE fra resultaterne af vores scanning for at forstå årsagen til sådanne resultater.

Mere information

Nr. 1

Lad os først gennemgå nogle interessante punkter fra Sonatype Nexus IQ.

Nexus IQ peger på et problem med deserialisering, der potentielt kan udføre RCE i Spring Framework flere gange. CVE-2016-1000027 i spring-web:3.0.5 først, og CVE-2011-2894 i spring-context:3.0.5 og spring-core:3.0.5. I starten ser det ud til, at der er en gentagelse af sårbarheden på tværs af flere CVE. For hvis man ser på CVE-2016-1000027 og CVE-2011-2894 i NVD-databasen, ser det hele ret indlysende ud.

Komponent
Sårbarhed

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Description CVE-2011-2894 fra NVD:


Description CVE-2016-1000027 fra NVD:


CVE-2011-2894 er i sig selv ret kendt. I rapporten White Source fra 2011 blev denne CVE anerkendt som en af de mest almindelige. Beskrivelserne for CVE-2016-100027 er generelt sparsomme i NVD, og den gælder åbenbart kun for Spring Framework 4.1.4. Lad os se på reference og her bliver det mere eller mindre klart. Fra artiklen Tenable forstår vi, at udover sårbarheden i RemoteInvocationSerializingExporter i CVE-2011-2894 er der også en sårbarhed i HttpInvokerServiceExporter. Det fortæller Nexus IQ os:

Alligevel findes der intet lignende i NVD, hvilket betyder, at Dependency Check og Dependency Track får falske negative.

Fra beskrivelsen af CVE-2011-2894 kan man også forstå, at sårbarheden faktisk er til stede både i spring-context:3.0.5 og spring-core:3.0.5. Bevis for dette kan findes i artiklen fra den, der fandt denne sårbarhed.

Nr. 2

Komponent
Sårbarhed
Resultat

struts2-core:2.3.30
CVE-2016-4003
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion

Hvis vi undersøger sårbarheden CVE-2016-4003, forstår vi, at den blev rettet i version 2.3.28, alligevel rapporterer Nexus IQ om den. I beskrivelsen af sårbarheden er der en note:

Det vil sige, at sårbarheden kun eksisterer i kombination med en forældet version af JRE, hvilket vi er blevet advaret om. Vi betragter dog dette som en falsk positiv, omend ikke den mest alvorlige.

Nr. 3

Komponent
Sårbarhed
Resultat

xwork-core:2.3.30
CVE-2017-9804
FALSE

xwork-core:2.3.30
CVE-2017-7672
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion

Hvis vi ser på beskrivelsen for CVE-2017-9804 og CVE-2017-7672, vil vi forstå, at problemet ligger i URLValidator-klassen, idet CVE-2017-9804 udspringer fra CVE-2017-7672. Tilstedeværelsen af den anden sårbarhed bidrager ikke med nogen nyttig information, udover at dens alvorlighed er steget til høj, så det kan betragtes som unødvendig støj.

Generelt var der ikke fundet andre falske positiver for Nexus IQ.

Nr. 4

Der er flere punkter, der adskiller IQ fra andre løsninger.

Komponent
Sårbarhed
Resultat

spring-web:3.0.5
CVE-2020-5398
FALSE

CVE i NVD rapporterer, at den kun gælder for versioner 5.2.x op til 5.2.3, 5.1.x op til 5.1.13 og versioner 5.0.x op til 5.0.16, men hvis vi ser på beskrivelsen af CVE i Nexus IQ, vil vi se følgende:
Advisory Deviation Notice: Sonatype sikkerhedsforskningsteamet opdagede, at denne sårbarhed blev introduceret i version 3.0.2.RELEASE og ikke 5.0.x som angivet i adviseringen.

Efter dette følger PoC for denne sårbarhed, som oplyser, at den findes i version 3.0.5.

Falsk negativ sendes til Dependency Check og Dependency Track.

Nr. 5

Lad os se på falske positiver for Dependency Check og Dependency Track.

Dependency Check adskiller sig ved at afspejle de CVE, der relaterer til hele rammeværket i NVD, til de komponenter, som disse CVE ikke gælder for. Dette gælder CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, som Dependency Check "har tilføjet" til struts-taglib:1.3.8 og struts-tiles-1.3.8. Disse komponenter har ikke noget at gøre med det, der er beskrevet i CVE — behandling af forespørgsler, validering af sider osv. Dette skyldes, at det eneste, der forbinder disse CVE og komponenter, er rammeværket, hvilket fik Dependency Check til at anse det som en sårbarhed.

Den samme situation gælder for spring-tx:3.0.5, og en lignende situation gælder for struts-core:1.3.8. For struts-core fandt Dependency Check og Dependency Track mange sårbarheder, der faktisk gælder for struts2-core, som i virkeligheden er et separat rammeværk. I dette tilfælde forstod Nexus IQ korrekt situationen, og i de CVE, der blev genereret, angav det, at struts-core var nået slutningen af livet og at man skulle skifte til struts2-core.

Nr. 6

I nogle situationer er det uretfærdigt at tolke åbenlyse fejl i Dependency Check og Dependency Track. Især CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, som Dependency Check og Dependency Track henviste til spring-core:3.0.5, faktisk henviser til spring-web:3.0.5. Nogle af disse CVE blev også fundet af Nexus IQ, dog korrekt identificeret til en anden komponent. At disse sårbarheder ikke blev fundet i spring-core, betyder ikke, at de ikke eksisterer i rammeværket generelt, og open source-værktøjer har korrekt peget på disse sårbarheder (de traf blot lidt forkert).

Konklusioner

Som vi kan se, giver manuel gennemgang af pålideligheden af de identificerede sårbarheder ikke entydige resultater, hvorfor der opstår tvivl. Resultaterne viser, at Nexus IQ-løsningen har den laveste falske positive rate og den højeste nøjagtighed.

Dette skyldes primært, at Sonatype-teamet udvidede beskrivelsen for hver CVE-sårbarhed fra NVD i deres databaser ved præcist at angive klasse eller funktion af sårbarheden for en given version af komponenten, efter at have gennemført yderligere undersøgelser (f.eks. ved at kontrollere sårbarheder på ældre versioner af softwaren).

Også de sårbarheder, der ikke er kommet ind i NVD, men alligevel findes i Sonatype-databasen med mærkningen SONATYPE, har en betydelig indflydelse på resultaterne. Ifølge rapporten Status for sikkerhedssårbarheder i open source 2020 om 45% af de opdagede sårbarheder med open source bliver ikke rapporteret i NVD. Ifølge WhiteSource-databasen offentliggøres kun 29% af alle open source-sårbarheder, der er registreret uden for NVD, i sidste ende i den, så det er vigtigt at søge efter sårbarheder også i andre kilder.

Som et resultat giver Dependency Check et stort antal falske positiver og overser en del sårbare komponenter. Dependency Track giver mindre støj og identificerer et større antal komponenter, hvilket visuelt ikke skæmmer webgrænsefladen.

Alligevel viser erfaring, at open source bør være det første skridt mod et modent DevSecOps. Det første, man bør overveje for at integrere SCA i udviklingen, er processerne, især overvejelser sammen med ledelsen og relevante afdelinger om, hvordan de ideelle processer bør se ud i ens organisation. Det kan vise sig, at for din organisation vil Dependency Check eller Dependency Track i starten opfylde alle forretningsmæssige behov, mens Enterprise-løsninger vil være et logisk skridt i takt med, at kompleksiteten af de udviklede applikationer vokser.

Applikation A. Resultater relateret til komponenter
Designations:

• Høj — sårbarheder af høj eller kritisk grad i komponenten
• Middel — sårbarheder af mellemgrad i komponenten
• SANDT — korrekt identificeret sårbarhed (True positive issue)
• FALSK — falsk positivet (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Resultat

dom4j: 1.6.1
Høj
Høj
Høj
FALSE

log4j-core: 2.3
Høj
Høj
Høj
FALSE

log4j: 1.2.14
Høj
Høj
—
FALSE

commons-collections:3.1
Høj
Høj
Høj
FALSE

commons-fileupload:1.3.2
Høj
Høj
Høj
FALSE

commons-beanutils:1.7.0
Høj
Høj
Høj
FALSE

commons-codec:1:10
Medium
—
—
FALSE

mysql-connector-java:5.1.42
Høj
Høj
Høj
FALSE

spring-expression:3.0.5
Høj
komponenten ikke fundet

FALSE

spring-web:3.0.5
Høj
komponenten ikke fundet
Høj
FALSE

spring-context:3.0.5
Medium
komponenten ikke fundet
—
FALSE

spring-core:3.0.5
Medium
Høj
Høj
FALSE

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

spring-tx:3.0.5
—
Høj
—
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion

struts-core:1.3.8
Høj
Høj
Høj
FALSE

xwork-core: 2.3.30
Høj
—
—
FALSE

struts2-core: 2.3.30
Høj
Høj
Høj
FALSE

struts-taglib:1.3.8
—
Høj
—
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion

struts-tiles-1.3.8
—
Høj
—
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion

Applikation B. Resultater relateret til sårbarheder
Designations:

• Høj — sårbarheder af høj eller kritisk grad i komponenten
• Middel — sårbarheder af mellemgrad i komponenten
• SANDT — korrekt identificeret sårbarhed (True positive issue)
• FALSK — falsk positivet (False positive issue)

Komponent
Nexus IQ
Dependency Check
Dependency Track
Alvorlighed
Resultat
Kommentar

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Høj
FALSE

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Høj
FALSE

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Høj
FALSE

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Lav
FALSE

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Høj
FALSE

—
CVE-2020-9488
—
Lav
FALSE

SONATYPE-2010-0053
—
—
Høj
FALSE

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikerer RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikerer RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Høj
FALSE

commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Høj
FALSE

SONATYPE-2014-0173
—
—
Medium
FALSE

commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Høj
FALSE

—
CVE-2019-10086
CVE-2019-10086
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder kun for versioner 1.9.2+

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

mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Høj
FALSE

CVE-2019-2692
CVE-2019-2692
—
Medium
FALSE

—
CVE-2020-2875
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Den samme sårbarhed som CVE-2019-2692, men med tilføjelsen ‘angreb kan have en betydelig indvirkning på yderligere produkter’

—
CVE-2017-15945
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Ikke relevant for mysql-connector-java

—
CVE-2020-2933
—
Lav
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikat til CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
—
Medium
FALSE

spring-expression:3.0.5
CVE-2018-1270
komponenten ikke fundet
—
Høj
FALSE

CVE-2018-1257
—
—
Medium
FALSE

spring-web:3.0.5
CVE-2016-1000027
komponenten ikke fundet
—
Høj
FALSE

CVE-2014-0225
—
CVE-2014-0225
Høj
FALSE

CVE-2011-2730
—
—
Høj
FALSE

—
—
CVE-2013-4152
Medium
FALSE

CVE-2018-1272
—
—
Høj
FALSE

CVE-2020-5398
—
—
Høj
FALSE
Et eksempel til fordel for IQ: ‘Sonatype sikkerhedsforskningsholdet opdagede, at denne sårbarhed blev introduceret i version 3.0.2.RELEASE og ikke 5.0.x som angivet i adviseringen.’

CVE-2013-6429
—
—
Medium
FALSE

CVE-2014-0054
—
CVE-2014-0054
Medium
FALSE

CVE-2013-6430
—
—
Medium
FALSE

spring-context:3.0.5
CVE-2011-2894
komponenten ikke fundet
—
Medium
FALSE

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Høj
FALSE

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
FALSE

—
—
CVE-2013-4152
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikat af den samme sårbarhed i spring-web

—
CVE-2013-4152
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web

—
CVE-2013-6430
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
SPLIT fra CVE-2013-4152. + Sårbarheden gælder komponenten spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web

—
CVE-2014-0225
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web

—
—
CVE-2014-0225
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikat af den samme sårbarhed i spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
For spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder komponenten spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Høj
FALSE

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

SONATYPE-2015-0327
—
—
Lav
FALSE

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

spring-tx:3.0.5
—
CVE-2011-2730
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2011-2894
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2013-4152
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2013-6429
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2013-6430
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2013-7315
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2014-0054
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2014-0225
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2014-1904
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2014-3625
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2016-9878
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2018-1270
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2018-1271
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

—
CVE-2018-1272
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden gælder ikke for spring-tx

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

Medium
FALSK
Sårbarheden relaterer til Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

CVE-2016-1182
3VE-2016-1182
—
Høj
FALSE

—
—
CVE-2011-5057
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

CVE-2015-0899
CVE-2015-0899
—
Høj
FALSE

—
CVE-2012-0394
CVE-2012-0394
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Høj
FALSK
Sårbarheden relaterer til Struts 2

—
CVE-2013-2115
CVE-2013-2115
Høj
FALSK
Sårbarheden relaterer til Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Høj
FALSK
Sårbarheden relaterer til Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Høj
FALSK
Sårbarheden relaterer til Struts 2

CVE-2014-0114
CVE-2014-0114
—
Høj
FALSE

—
CVE-2015-2992
CVE-2015-2992
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

CVE-2016-1181
CVE-2016-1181
—
Høj
FALSE

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Sårbarheden relaterer til Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Høj
FALSE

SONATYPE-2017-0173
—
—
Høj
FALSE

CVE-2017-7672
—
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Dublet til CVE-2017-9804

SONATYPE-2016-0127
—
—
Høj
FALSE

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Høj
FALSE

—
CVE-2017-9787
CVE-2017-9787
Høj
FALSE

—
CVE-2017-9791
CVE-2017-9791
Høj
FALSE

—
CVE-2017-9793
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Duplikat til CVE-2018-1327

—
CVE-2017-9804
—
Høj
FALSE

—
CVE-2017-9805
CVE-2017-9805
Høj
FALSE

CVE-2016-4003
—
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Anvendelig til Apache Struts 2.x op til 2.3.28, hvilket er version 2.3.30. Dog, baseret på beskrivelsen, gælder CVE for alle versioner af Struts 2, hvis der bruges JRE 1.7 og lavere. Det ser ud til, at vi her forsøger at være forsigtige, men det ligner mere en FALSE

—
CVE-2018-1327
CVE-2018-1327
Høj
FALSE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Høj
FALSE
Den sårbarhed, som angribere udnyttede i Equifax i 2017

CVE-2017-12611
CVE-2017-12611
—
Høj
FALSE

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Høj
FALSE

struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til struts2-core

—
CVE-2013-2115
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til struts2-core

—
CVE-2014-0114
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til commons-beanutils

—
CVE-2015-0899
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til taglib

—
CVE-2015-2992
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer til struts2-core

—
CVE-2016-1181
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til taglib

—
CVE-2016-1182
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til struts2-core

—
CVE-2013-2115
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til struts2-core

—
CVE-2014-0114
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Under commons-beanutils

—
CVE-2015-0899
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til tiles

—
CVE-2015-2992
—
Medium
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Til struts2-core

—
CVE-2016-1181
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til taglib

—
CVE-2016-1182
—
Høj
. I vores eksempel har vi skrevet en simpel funktion, der ved hjælp af den grundlæggende funktion
Relaterer ikke til taglib

Kilde: habr.com