1、State of Open SourceSecurity Report2020 Table of contentsThe open source universe 9Ecosystem growth 10The security implications of open source development 12Addressing infrastructure and container security risk 31 Security in Linux distributions 32Guest commentary:Red Hat 33Docker images 34Kubernete

2、s security 36Helm security 38Detailed open sourcevulnerability analysis 14High-level vulnerability trends 15Spotlight:Whats old is new again 19Vulnerability impacts in 2019 20Spotlight:Snyk discovers prototype pollution in Lodash 24Ecosystem vulnerability analysis 25Security and vulnerability manage

3、ment practices 39 Security as a culture 40Guest analysis:CircleCI 42Spotlight:Creating a culture of shared security responsibility at Segment 44Evaluating package health 45Container image health 46Security practices 47Vulnerability remediation 50Maintainer security performance 531234Introduction 3Ke

4、y takeaways and trends 4About out survey 5Report conclusions&recommendations 55All rights reserved.2020 Snyk3IntroductionThe use of open source software has become almost ubiquitous in the software development community.Development ecosystems have grown in their dependence on third-party libraries a

5、nd packages to streamline development.Awareness of how the increased prevalence of open source software impacts the security posture of enterprise organizations appears to be growing as well.For their part,the open source community is responding.In November of 2019,GitHub(acquired in 2018 by Microso

6、ft)announced the launch of the GitHub Security Lab with free access to its CodeQL code review tool and the opening of its Advisory database to public access.However,the question remainsis this increased awareness translating into improved security and practices related to the use of open source soft

7、ware?As part of our annual report on the state of open source securityand our desire to help the development community leverage open source securelywe sought to answer many of these questions.Once again,this year we gathered information from a few key sources including the following:A survey created

8、 and distributed by Snyk and our partners that was completed by over 500 developers,security practitioners,and operations technologists.Internal data from the Snyk vulnerability database,as well as correlated data from the hundreds of thousands of projects currently monitored and protected by Snyk.R

9、esearch and data published by various sources that include aggregated data from scanning the millions of repositories in GitHub,GitLab,Bitbucket,and others.Through our analysis,Snyk was able to identify some key themes and trends that shed new light on the current state of security across open sourc

10、e ecosystems.Lets begin by looking at some of those.4All rights reserved.2020 SnykKey takeaways and trends Open source universe Open source ecosystems continue to expand,led by npm which grew over 33%in 2019,now spanning over 1,300,000 packages to this date.The majority of open source vulnerabilitie

11、s continue to be discovered in indirect dependencies:npm-86%Ruby-81%Java-74%Container&orchestration challenges Official base images tagged as latest include known vulnerabilities.Over 30%of survey participants do not review Kubernetes manifests for insecure configurations.Requirements for security-r

12、elated resource controls in Kubernetes are not widely implemented.Vulnerability trends New vulnerabilities were down almost 20%across the most popular ecosystems in 2019.Cross-site scripting vulnerabilities were the most commonly reported.Two prevalent prototype pollution vulnerabilities resulted in

13、 an impact on over 25%of scanned projects.New vulnerabilities reported in common Linux distributions demonstrate the need for comprehensive monitoring for new vulnerabilities in container images.SQL Injection vulnerabilities,while decreasing in prevalence in most ecosystems,have increased over the l

14、ast three years in PHP packages.Security culture Increasingly,survey respondents feel that security for software and infrastructure should be shared among development,security,and operations roles.However,few organizations have programs in place to develop shared responsibility across the Dev,Sec,an

15、d Ops personnel.All rights reserved.2020 Snyk5A word about our surveyIn an effort to gain additional perspectives on the data we researched regarding open source software,we reached out to the community at large.Over the course of several months,we surveyed over 500 industry professionals to ask abo

16、ut their use and maintenance of open source packages in their software,as well as cloud native technologies.Throughout this report,we reference various findings from that survey.However,to put those findings into perspective,it is important to understand the survey itself better.The survey was made

17、available via social media,a number of select partners,and direct outreach to communities in software development and security.Respondents were not scientifically chosen so,there may be biases in some of the results that need to be considered.For instance,we asked each respondent what their primary

18、role was.Maybe not too surprising,66%work in software development.Responses from Security and Infrastructure/Operations personnel amounted to a combined 29.4%.So,while we were able to gain important security and operations perspectives,the final results will be slanted toward the view of software de

19、velopers.13%5%16%66%Survey participants job responsibilitiesSecuritySoftware DevelopmentOtherInfrastructure/OperationsSecuritySoftware DevelopmentAll rights reserved.2020 Snyk6We also wanted to understand the relative position of our participants within their organization.We asked the respondents to

20、 identify what best described their role in terms of general titles.The response set was weighted more heavily toward individual contributors than leadership.Survey participants-job roleDeveloper29%Engineer25%Architect19%Executive Leader7%Senior Leader7%Analyst4%Project Manager3%First-Level Manager2

21、%Other4%All rights reserved.2020 Snyk7Understanding what industries are providing their perspectives is also crucial,see below the breakdown of the top five industries represented in our report.You can see that Technology and Financial Services were the most highly represented.Response by top 5 indu

22、stries030%GovernmentTechnologyFinancial Services10%20%40%Healthcare33%19%9%5%Education4%All rights reserved.2020 Snyk8Finally,we believe it is important to understand the size of the organizations that our participants represented.While there was significant influence from small organizations or ind

23、ividuals in our response set,the remaining participants provided pretty equal representation across organizational sizes.Organization size41%23%6%11%19%5000+-900100-4991-1001The open source universeThe trend of incredible growth in the use and contribution of open source software across

24、various software development ecosystems continued in 2019.In the State of the Octoverse report,GitHub reported that over 10 million new users joined GitHub last year bringing the total number of developers on that platform to over 40 Million.All rights reserved.2020 Snyk10Ecosystem growthOur researc

25、h across multiple ecosystems and repositories was consistent with the overall growth trends seen across the open source community.In terms of development ecosystems,we continued to track the progress of five of the most common open source ecosystems.The growth in open source packages is driven large

26、ly by the continued popularity and growth of the JavaScript ecosystem.Conversely,fewer new packages were created for Java and Ruby than in the previous year.Overall,across these five ecosystems,the total number of packages grew significantly.In particular,npm grew by over 33%from the end of 2018 to

27、the end of 2019.New packages created by ecosystem per year0100k200k300k400k200182019RubygemsPyPINuGetnpmMaven Central0100k200k300k400k200182019RubygemsPyPINuGetnpmMaven CentralAll rights reserved.2020 Snyk11The growth in JavaScript and Node.js packages is consistent with the re

28、sponses we received from our survey participants regarding the ecosystems they use.Over 70%of the participants said they use Node.js/JavaScript as a primary development ecosystem in their organization.Rust5%Ruby13%Node.js orJavascript73%.Net26%Java or otherJVM language62%Other25%Go27%Python55%PHP29%

29、All rights reserved.2020 Snyk12The security implications of open source developmentA key risk factor when organizations consider the security of their open source software utilization,centers around the idea of maintaining a Software Bill of Materials.Organizations are challenged with understanding

30、what open source libraries and packages are included in the software they produce.This challenge comes from the difficulty in understanding not only the direct open source dependencies defined in their code but the indirect dependencies that are introduced as a result.In our survey,we asked the part

31、icipants about their ability to track open source dependencies in their software.Over 60%said they do not have a good view into the full dependency trees of their software.As a result,it would be extremely difficult to identify if a newly discovered vulnerability in an open source package affects th

32、eir code or not.How do you track open source dependencies?28%Strong controls and confidence of all dependencies33%Direct dependencies,but struggle with indirect7%I dont know32%We dont havegood controls60%of organizations surveyed do not fully inventory the dependency trees in their softwareAll right

33、s reserved.2020 Snyk13When you consider this information in light of the growth and wide-spread use of ecosystems like Node.js,the risk that open source development poses to organizations becomes all too real.Each year we analyze the vulnerabilities that Snyk has identified in hundreds of thousands

34、of projects.We continue to find that the majority of Node.js,Java,and Ruby vulnerabilities identified are introduced via indirect dependencies.Vulnerabilities from direct versus indirect dependenciesIndirectDirectOver 70%of vulnerabilities discovered in Node.js,Java and Ruby are found in indirect de

35、pendencies0%25%50%75%100%npmPyPIRubyGemsMavenCentralPHPPackagist11%89%27%73%14%26%19%74%81%86%2Detailed open sourcevulnerability analysisWhat would any discussion of the state of open source security be without taking a look at the vulnerabilities being discovered and disclosed in open source packag

36、es and libraries?This year we are taking an even deeper look at vulnerability and ecosystem-level trends that affect the overall security posture of the open source community.All rights reserved.2020 Snyk15High-level vulnerability trendsIn past years,we have seen that in terms of total vulnerabiliti

37、es identified in open source packages across the ecosystems,Node.js and Java have traditionally shown the greatest number of new vulnerabilities each year.That trend continued in 2019,perhapsat least to some extentdue to the relative popularity of those ecosystems.One potentially encouraging sign is

38、 that across all six popular ecosystems we looked at,there were fewer new vulnerabilities reported in 2019 than in 2018.While one year is hardly enough data to draw a significant conclusion if this trend continues,it could be a positive sign that efforts to improve the security of open source softwa

39、re are starting to pay off.Vulnerabilities identified in ecosystems since 20019300400Maven CentralnpmMaven CentralNuGetnpmMaven CentralPyPINuGetnpmMaven CentralPHP PackagistPyPINuGetnpmMaven CentralAll rights reserved.2020 Snyk16Unfortunately,not all the high-level a

40、nalysis of vulnerabilities in the open source ecosystems paints the same optimistic picture.It is good to see that the number of new vulnerabilities disclosed this year in those popular ecosystems went down.However,the overall number of vulnerabilities reported across all ecosystems increased in 201

41、9 after having shown a decrease in 2018.Compounding that concern is that,once again in 2019,the majority of the vulnerabilities identified were considered high severity.Note:One may notice that our numbers for previous years do not match the numbers presented in last years report.Those discrepancies

42、 are due to vulnerabilities that were reported but not confirmed until after the end of the year,new or additional sources of vulnerability data we included to our vulnerability database,as well as the addition of new ecosystems to our vulnerability database.Vulnerability severities by year025050075

43、0720776082620212501500HighMediumLowAll rights reserved.2020 Snyk17Looking at the numbers of new vulnerabilities,it is easy to assume that the discovery of new attack vectors is behind the large number of new vulnerabilities reported.However,a deeper analys

44、is of the vulnerabilities shows that is simply not the case.We analyzed the types of vulnerabilities that have been reported in open source software dating back to 2014.The data shows that well-understood vulnerabilities continue to contribute significantly to the totals.For instance,cross-site scri

45、pting which has been a category on every OWASP Top 10 list since the very first list was created in 2003is the most common vulnerability discovered since 2014 and,year over year,it is in the top 3 of reported vulnerabilities.Top vulnerabilities since 200420500750250623646524022

46、7Code ExecutionXSSDenial-of-ServiceDirectory TraversalMalicious PackagesInformation ExposureAccess RestrictionBypassCSRFXXEAuthentication Bypass20000001420192019All rights reserved.2020 Snyk18Given the number of controls and framework

47、s available in the various ecosystems to prevent exactly these types of attacks,it is somewhat concerning that these numbers continue to progress in this way.The introduction of Content Security Policies(CSP)is one of the latest attempts to thwart these types of attacks.However,based on the current

48、vulnerability trends,it is clear that more work needs to be done.In the end,it is up to the developer to implement proper validation,whileit is incumbent upon security professionals to help enable the discovery of potential flaws that lead to these types of attacks and assist in designing remediatio

49、ns.Equally concerning is the number of code execution vulnerabilities being discovered.This category includes both remote code execution and arbitrary code execution exposures that can lead to a variety of high severity exploits.These types of vulnerabilities can often be leveraged to spread malware

50、/ransomware.Since malware is a significant contributor to many of the high-profile breaches being reported,the prevalence of these vulnerabilities should raise some eyebrows as well.19Whats old is new againThe Open Web Application Security Project(OWASP)was founded in 2001 with the goal of helping d

51、evelopers and organizations create secure applications that could be trusted.In 2003,OWASP published its first Top 10 list of common web application security risks.The list provided categories of common types of vulnerabilities that impact web applications.Since that time,OWASP have published period

52、ic updates to the list,most recently releasing a version in 2017.A number of the categories that appeared on that first list in 2003 remain on the list today,among them is cross-site scripting(XSS).Cross-site scripting has been one of the most commonly discovered vulnerabilities across applications

53、for more than a decade.As we see in this report,that trend continues even today.XSS is a vulnerability that can have a wide range of impacts.It allows attackers to inject malicious browser-side script that is executed when unsuspecting users visit a site.These attacks can vary from simple defacement

54、 or functionality manipulation to theft of session identifiers leading to session hijacking.The primary strategy for preventing and/or remediating XSS vulnerabilities in applications has not changed since it first was reported on the OWASP Top10 list in 2003.Properly validating and/or sanitizing all

55、 data received from the users browser is the most effective way to ensure that applications are free from these vulnerabilities.However,that is a solution that is much easier stated than it is implemented.Numerous safeguards have been implemented in development ecosystems and newer browsers to help

56、prevent successful attacks based on XSS vulnerabilities.However,the presence of XSS vulnerabilities as the most reported form of application weakness in 2019 is evidence that these controls are not being implemented consistently or not completely effective.Therefore,it is still incumbent on the deve

57、loper to be aware of these attack vectors and not assume that their dependencies have enabled proper protections.All rights reserved.2020 Snyk20Vulnerability impacts in 2019Understanding the prevalence of various forms of security vulnerabilities within open source packages and libraries is only one

58、 piece of the security picture.We dug deeper to look at the overall impact of vulnerabilities across the open source community and within projects that rely on open source dependencies.Looking at vulnerabilities reported in 2019,the top ten vulnerability titles follow pretty closely to what we see i

59、n terms of the overall trends discussed in the previous section.In 2019,cross-site scripting vulnerabilities remained at the top of the list as the most commonly reported vulnerabilities.However,what is particularly interesting to note,is that the second most common vulnerability identified were mal

60、icious packages.These are situations where a typically known and trusted package has been contaminated with an attack payload or a package intentionally designed and released with an attack payload built into it.We will talk more later about how developers and organizations attempt to understand the

61、 health and trustworthiness of their software dependencies.For now,this trend suggests that the threats are significant and efforts to improve our understanding of package health are important.Top 10 vulnerabilities of 201920%0%10%15%5%13%3%5%3%18%5%Malicious PackageDenial-of-Service(DoS)Cross-site

62、Scripting(XSS)Arbitrary Code Execution7%Information Exposure2%2%3%Cross-site RequestForgery(CSRF)Remote CodeExecution(RCE)Insufficiently ProtectedCredentialsDirectory TraversalDeserialization ofUntrusted DataMalicious packages,either intentionally designed as malicious or trusted packages that have

63、been contaminated,were the second most reported vulnerability in 2019All rights reserved.2020 Snyk21How do these vulnerabilities translate into their impact on software projects?Analyzing this question is of particular importance as it demonstrates how widespread the attack exposures are in the soft

64、ware community.Vulnerabilities are less of a risk if the affected packages are only used in a handful of projects.However,when a vulnerability is reported in a highly popular package affecting thousands of projects,that creates a higher probability of that vulnerability being exploited by attackers.

65、To that end,we examined the number of vulnerabilities that were identified in the hundreds of thousands of projects that have been scanned and monitored by Snyk.The results were quite interesting in the story they tell.Despite the high prevalence of cross-site scripting vulnerabilities being reporte

66、d,those vulnerabilities only impacted about 6.7%of the projects scanned.Prototype pollution is one potential vector through which attackers can introduce malicious code into otherwise trustworthy packages.The prevalence of prototype pollution across so many projects is likely a result of multiple hi

67、gh-profile vulnerabilities discovered in 2019.The first vulnerability was discovered in jQuery and disclosed via HackerOne.Given the relative popularity of jQuery,a significant number of projects were affected.Conversely,the top vulnerability currently impacting scanned projects is prototype polluti

68、on in nearly 27%of all projects.All rights reserved.2020 Snyk22In July of last year,Snyk researchers discovered a prototype pollution vulnerability in the extremely popular Lodash package.The vulnerability,CVE-2019-10744,affected all versions of the package at the time of discovery and as a result,i

69、ts impact was very widespread resulting in a very high number of impacted projects.Top 10 vulnerabilities of 2019 by project impact20%Deserialization ofUntrusted DataRegular ExpressionDenial-of-Service(ReDoS)Prototype PollutionArbitrary Code Execution17%Denial-of-Service(DoS)0%10%15%5%18%7%10%5%27%9

70、%4%3%4%Information ExposureCross-site Scripting(XSS)Arbitrary File OverwriteRemote Code ExecutionAccess Control Bypass30%25%All rights reserved.2020 Snyk23The differences between which types of vulnerabilities were reported most often and which types impacted the most projects brings up an interesti

71、ng question.If we understand both the prevalence and impact of each type of vulnerability,could that help us better determine which are the biggest threats to software?We analyzed the top five vulnerabilities from the previous two analyses and plotted them according to both their prevalence and thei

72、r impact on projects.Maybe somewhat surprising,there were no vulnerabilities that stood out as having both high prevalence and high impact.For instance,while there are a lot of malicious packages reported,very few projects were impacted by those packages.Conversely,while there are relatively few rep

73、orts of deserialization vulnerabilities,the ones that have been reported affected a high number of projects.Vulnerabilities reported vs projects impactedWhile fewer than 25 prototype pollution vulnerabilities were reported in 2019,they impacted over 115,000 projects scanned05010020k40k60k80k100kXSSM

74、alicious PackageInformation ExposureDoSRCEArbitraty CodeExecutionDeserialization ofUntrusted DataPrototypePollutionReDoS250120k150200Number of projects impactedNumber of vulnerabilities24Snyk discovers prototype pollution in LodashOn July 2nd,2019,we published a high severity prototype pollution sec

75、urity vulnerability(CVE-2019-10744)affecting all versions of Lodash,as the result of an on-going analysis led by the Snyk Security Research team.An updated version of Lodash(4.17.12)was subsequently released on July 9th which included fixes submitted by Snyk to remediate the vulnerability.Needless t

76、o say,a high severity vulnerability in a library as popular as Lodash affects a large proportion of npm users.The team proactively opened thousands of automatic fix pull requests for its users to remediate the vulnerability.The news of this Lodash security vulnerability came to light merely three mo

77、nths after a similar prototype pollution vulnerability was reported in the ever-popular jQuery JavaScript frontend library.Similar to other prototype pollution vulnerabilities,the implementation of unsafe recursive JSON merge may result in the ability to tamper with JavaScripts Object which influenc

78、es other data-types through the prototype chain.The implications of such vulnerabilities can range from property injection to code injection and Denial-of-Service,depending on the affected use-case and whether this vulnerability can be exploited.In the case of the Lodash vulnerability,the function d

79、efaultsDeep could be tricked into adding or modifying properties ofObject.prototype using a constructor payload.The fix included a safety check to ensure that the global object was not being polluted.A test case was also added to ensure no future regressions occur.This vulnerability serves as an exa

80、mple of how direct and indirect dependencies can amplify the impact of a single security flaw across a wide population of projects.At the time,the popular npm library was used by 4.35 million projects on GitHub alone.The project had just shy of 40k GitHub project stars,and the library had been downl

81、oaded over 80 million times each month.All rights reserved.2020 Snyk25Ecosystem vulnerability analysisHaving established a broad understanding of vulnerabilities across the open source community,it also makes sense to understand how those top ten vulnerabilities impact individual ecosystems.We looke

82、d at the numbers for the top five vulnerability types across some of the most popular ecosystems.Cross-site scripting(XSS)Cross-site scripting vulnerabilities topped the list of newly reported vulnerabilities in 2019.How did that play out across the ecosystems?As you might expect,PHP leads the way w

83、ith the newest vulnerabilities.Considering the relative lack of anti-XSS controls built into the ecosystem,it is far easier for developers to make mistakes or simply neglect to implement sufficient countermeasures.Since XSS is largely a web application attack,it is no surprise that Python and Ruby h

84、ave relatively low numbers.Since they are far less commonly used to implement web applications,it simply stands to reason that there would be relatively few instances.The small number of instances identified in.NET packages available through NuGet is likely a sign of the significant work that has be

85、en done inside the.NET Framework to prevent these types of vulnerabilities.Additionally,the low use of open source dependencies in.NET is also reflected in the overall number of XSS vulnerabilities reported.New XSS vulnerabilities by year2000PyPIPHP PackagistMaven Centralnpm862

86、33757713071NuGet2144125RubyGems1696All rights reserved.2020 Snyk26Code execution vulnerabilitiesJust when one thought it might be safe to talk about the security posture of.NET applications,we bring forward the number two leading category of security vulnerabilities since 2014,code execut

87、ion vulnerabilities.Vulnerability reports in 2018 were dominated heavily,especially in the.NET ecosystem,by prominent remote code execution vulnerabilities.While things improved in 2019 considerably(even in comparison to 2017 when over 75 vulnerabilities were reported)it is clear that this ecosystem

88、 has had a significant contribution in making arbitrary and remote code execution a prominent category.Java and PHP for their part are not immune to these issues either,while Node.js and Python experienced far less activity in reports for this vulnerability type.New code execution vulnerabilities by

89、 year0255075100PyPIPHP Packagist181028128Maven Centralnpm293626416NuGet20019All rights reserved.2020 Snyk27Denial-of-Service vulnerabilitiesDenial-of-Service(DoS)attacks are one of the more frustrating risks that organizations face.They can be some of the most diffic

90、ult to defend against and hardest to troubleshoot when they occur.Over the past three years and,in particular,in 2018,there were significant discoveries of Regular Expression DoS attacks in the Node.js ecosystem.Thankfully the number of new vulnerabilities in 2019 fell considerably.Java saw a simila

91、r decline after some notable flaws in 2018 and.NET has shown similar reductions as wellgood news for the operations folks who are trying to keep pace with what can be an overwhelming threat landscape.New Denial-of-Service vulnerabilities by year0255075100PyPIPHP PackagistRubyGems13811211Maven Centra

92、lnpm4234131924NuGet7332401620182019All rights reserved.2020 Snyk28Information exposureAs the name would suggest,this category describes application vulnerabilities that lead to the exposure of sensitive information.The Java ecosystem,over the last couple of years,has been hit b

93、y a number of vulnerabilities related to Jenkins plugins that have created potential exposure of sensitive information.New information exposure vulnerabilities by year200pipcomposerrubygems71399261217mavennpm37296656golang6210All rights reserved.2020 Snyk29Directory

94、traversalAttacks that exploit directory traversal can be particularly damaging as the impact of such an attack can be varied and extensive.In some cases,such an attack simply arms the attacker with additional information about the system that they can leverage to build more complex exploits.In more

95、serious instances,however,when an attacker is able to exploit a directory traversal vulnerability,it can lead to significant exposurespotentially including system-level credentials.As you can see,vulnerabilities in Node.js disclosed in 2017 and 2018 account for the bulk of these vulnerabilities and

96、why this category is prominent over the last several years.Outside of those large spikes in activity,the overall numbers of new vulnerabilities within this category are fairly low and,as a result,potentially indicative of improved countermeasures and overall developer awareness,as well.New directory

97、 traversal vulnerabilities by year050100150200pipcomposerrubygems02361533mavennpm237204118nuget620182019All rights reserved.2020 Snyk30SQL injectionIt is interesting to notice that SQL injection is not in the top ten(let alone the top five).However,given the potential impact of

98、 successful SQL injection exploitsand some notable past breaches that leveraged SQL injection vulnerabilitiesits absence from the top ten is potentially very encouraging.For that reason,we decided to take a look quickly to understand if the data paints the same happy picture as one might expect.The

99、reality of the data is a mixed set.The continuing reduction of SQL injection vulnerabilities in the Java ecosystem is certainly a very good sign.However,not so when it comes to PHP where the number of new vulnerabilities is increasing.While the overall numbers are still very low,this could point to

100、a trend that will be worth watching in 2020.In a somewhat encouraging sign,other ecosystems we investigated did not have significant numbers of SQL injection vulnerabilities reported,and therefore,were not included in our analysis.New SQLi vulnerabilities by year05101520PHP PackagistMaven Centralnpm

101、30445826720Addressing infrastructure and container security riskContainers have become almost ubiquitous in cloud environments,especially within DevSecOps pipelines.The distinct advantages of running software in dedicated,often Linux-based containers have given developers more

102、flexibility and control over the deployment of their applications and microservices.Orchestration with Kubernetes has further enhanced those advantages by creating operational environments that are easily launched in highly resilient configurations.Of course,as is the case with all technologies,cont

103、ainers have introduced their own unique challenges and threats from a security perspective.As the open source community creates and shares images and Kubernetes configurations,vulnerabilities that exist within them become a part of our operational environments.Last year we highlighted some key conce

104、rns in this space,so for this year,we revisited those findings to see how things have changed.All rights reserved.2020 Snyk32Security in Linux distributionsMost popular container images are based on some flavor of Linux meaning that vulnerabilities that impact popular Linux distributions have a dire

105、ct impact on the security posture of the containers that leverage them.For this years report,we turned to the MITRE CVE Database and looked at the number of reported vulnerabilities that impacted four of the more popular Linux distributions.Unfortunately,we had to omit RedHat from this particular an

106、alysis as a result of limitations of the data that we could retrieve from the CVE database.New vulnerabilities impacting Debian have shown a significant decline over the last two years,after peaking at over 1,300 in 2017.Where the reverse is true for Fedora and SUSE whose count of new vulnerabilitie

107、s has grown over the past couple years.The important lesson from these numbers,however,is not really in the trends.The overall number of vulnerabilities being reported each year serves as a reminder of how diligent operations and security teams need to be in monitoring what Linux distributions are i

108、n use across their environment.Obviously,with developers pulling,customizing,or in some cases building container images,this is an increasingly difficult task.This highlights the need for tooling and processes that can comprehensively identify and monitor for new vulnerabilities in all installed lib

109、raries within each container image.New Linux vulnerabilities by year0500620500DebianFedoraDebianSUSEUbuntuFedoraDebianSUSESUSE33The security cost of open sourceAs one of the largest commercial vendors of open source software,Red Hat is aware of the many security challenges arou

110、nd consuming and using open software.In 2019,there were over 1400 vulnerabilities reported in Red Hat Enterprise Linux alone 1;for reference that is versions 5 through 8,and version 8 ships with over 2300 packages itself1.This is why Red Hat puts considerable effort into the security tracking,triage

111、 and assessment of those packages shipped in our products.It narrows the aperture for Red Hat users to focus on those third-party components someone might install on top of our platforms,meaning there is less to track,triage,and understand.Open source software doesnt sit idle.Every day there is new

112、software created that can be used to extend or enable new functionality.This is the beautiful thing about open sourceit continues to grow and improve,allowing consumers to build more useful and sophisticated technologies with reduced overhead in development.There is a cost though,and that is diligen

113、ce.With the rate of change and improvement to open source software,that new code being created every day has the potential to introduce new vulnerabilities.You see that in communities that explode in popularity,such as npm for example,or other communities that undertake audits or begin to report mor

114、e diligently on security issues.This is where you will often see surges or spikes in vulnerabilities in a particular ecosystem.It doesnt mean the software is bad or insecure,typically it means its active as discovered vulnerabilities are often the sign of a healthy ecosystem.Guest analysis by Vincen

115、t Danen,Senior Director,Product Security at Red Hat1 https:/ All rights reserved.2020 Snyk34Docker imagesExploring deeper into the open source container community,we looked at the security posture of 10 of the most popular container images on Docker Hub.These official images are some of the most oft

116、en pulled,and provide developers with a quick and easy way to run those applications.The most popular images tend to be those tagged latest and these images are often designed to handle the broadest set of use cases for a particular language or application.With that in mind,they often come with a ra

117、nge of packages and development tools that make it very easy to install and run your code and all its dependencies.Last years analysis showed that these popular base images had many vulnerabilities,and so,in revisiting the analysis this year,we wanted to make the comparison to see how things had cha

118、nged.We pulled the image tagged latest for each of these containers and scanned them using Snyk.Vulnerabilities in official container images6007008969nginxnodepostgresmongohttpdmysqlrediscouchbasememcachedubuntu306283726606750575020192018All rights reserved.2020 Snyk35The resul

119、ts closely matched what we discovered last year and,in some cases,the results showed even more vulnerabilities this year.The latest node image(14.3.0-buster at the time of our analysis),for instance,has 642 known vulnerabilities.Breaking it down further,the base image contains 17 high and 139 medium

120、 severity vulnerabilities.The high severity vulnerabilities stem,in large part,from the version of Debian on which the image is based and span many different libraries,including image processing and database connectors.All of these included packages likely make the latest image easy to use,but may n

121、ot make it the best to use.Further analysis shows that slimmer base images that include fewer libraries also have fewer overall vulnerabilities.For instance,the node base image 14.3.0-buster-slim has only 47 vulnerabilities,of which 0 are high severity and only 4 are medium severity since it does no

122、t include many of the vulnerable libraries that are in the 14.3.0-buster image.These findings mimic what we saw in last years report.For developers,the implications are pretty clear.It is important that developers are aware of the risks that are inherent to using images retrieved from public reposit

123、ories,even when they are listed as official images.And developers should follow container best practices,which include using slimmer base images;ensuring you rebuild your images when the official images get updated so you get the latest security fixes;and using processes like multi-stage builds that

124、 can help separate development packages from production packages and slim down the final image in an automated fashion.Project name:docker-image|nodeDocker image:node:latestBase image:node:latestLicenses:enabledTested 412 dependencies for known issues,found 642 issues.Base Image Vulnerabilities Seve

125、ritynode:latest 642 17 high,139 medium,486 lowRecommendations for base image upgrade:Alternative image typesBase Image Vulnerabilities Severitynode:14.3.0-buster-slim 47 0 high,4 medium,43 lownode:14-buster 291 2 high,60 medium,229 lownode:14-slim 68 6 high,7 medium,55 lowAll rights reserved.2020 Sn

126、yk36Kubernetes securityAs many organizations look to leverage container-based infrastructure solutions,using Kubernetes to orchestrate and manage those containers is a likely next step.In our survey,over 44%of the participants indicated that they are currently using Kubernetes to orchestrate their c

127、ontainers.But how are they ensuring the security of their Kubernetes manifestswe wondered.So we asked!Only 28%of those that use Kubernetes stated they have any form of automated tooling to review the configurations of their Kubernetes clusters.Worse,over 32%said they didnt know or dont have any prac

128、tices in place.Manual configuration reviews of their YAML/JSON manifests or Helm Charts was the most common practice.Securing Kubernetes ClustersDoesnt use KubernetesUses Kubernetes0%20%40%30%28%42%Manual review of YAML/JSONor Helm ChartsManual audits ofproduction clustersAutomated configurationrevi

129、ewsOtherI dont know/None of these7%31%10%30%44%56%50%44%of survey participantsindicated that they use Kubernetes to orchestrate their containers.All rights reserved.2020 Snyk37There are numerous key configuration decisions that can be made when defining a Kubernetes cluster that have a direct impact

130、 on the security of that cluster.The impact of failing to implement key controls can also be felt in terms of the costs associated with cloud environments in which these clusters are hosted.Validation that these configurations are in place can be easily achieved by automated reviews of the configura

131、tion files before deployment in a production environment.Additionally,tooling is available that can analyze active clusters for insecure configurations as well.Given the potential impact of insecure configurations,the importance of those reviews cannot be overstated.In our survey,we asked the partic

132、ipants about some of the more common configuration strategies that can be employed to help secure containers managed via Kubernetes.Of those that reported they use Kubernetes over 50%reported using both memory and CPU limits to manage their containers.However,restrictions on the use of vulnerable or

133、 unnecessary kernel modules were not very common.Audit logging was also not particularly common.Nearly 32%reported they were not sure or did not leverage any of the possible controls we asked about.The results seem to indicate a greater focus on the aspects of the configuration that affect availabil

134、ity and capacity while the more security-related features receive less attention.This would mirror a common progression of behaviors in new technology when the security of the technology is not made a primary concern early in the adoption of that technology.Kubernetes resource controls40%36%55%54%Me

135、mory limitsCPU limitsNon-root container contextRestricted network accessAudit loggingKernel module blacklists32%15%I dont know/none of these32%Less than 40%of survey respondents verify common security-related Kubernetes configuration options.Multiple responses allowed.All rights reserved.2020 Snyk38

136、Helm securityHelm is the most popular package manager for Kubernetes.As part of moving to Kubernetes,many organizations use Helm as the tool for deploying in-house or third-party applications.In our survey,over 40%of the respondents who said they use Kubernetes also indicated that they leverage Helm

137、.But what are the security implications of using Helm?A common risk that must be considered when installing a third-party Helm chart is the potential of introducing a vulnerable image in your cluster.In our 2019 Helm report,we found that 68%of stable Helm Charts contain an image with a high severity

138、 vulnerability.Here are the different types of vulnerabilities we found:Helm vulnerability types9%30%4%7%35%7%8%OtherCryptographic IssuesImproper Input ValidationResource ManagementErrorsNULL Pointer DereferenceAccess Restriction BypassOut-of-Bounds4Security and vulnerability management practicesAs

139、development ecosystems evolve and the use of open source packages becomes increasingly prevalent in software development,organizations need to employ key strategies for how they become aware of and react to vulnerabilities.Analysis of the state of open source security would be incomplete if we did n

140、ot consider how organizations are addressing the threats that the use of open source introduces.All rights reserved.2020 Snyk40Security as a cultureSoftware development has evolved considerably over the past decade.The adoption of DevOps/DevSecOps software delivery pipelines has forced software deve

141、lopment organizations to think very differently about the development lifecycle.In particular,security practitioners have been challenged with ensuring secure practices while not inhibiting the improved efficiency of software delivery that sits at the very core of the DevOps model.In DevOps/DevSecOp

142、s software delivery we have multiple motions.Developers pushing further right into the delivery pipeline,owning tasks from development through deployment.The ability to define the infrastructure on which their software will run via containers and other code defined infrastructure has enabled this tr

143、ansition.Meanwhile,as has been the case for decades,security continues pushing further left.Bringing security considerations to the development process early is recognized for its ability to,not only reduce risks but costs as well.Finally,the operations are being driven to move up higher in the infr

144、astructure stack as a result of increased use of virtualization technologies,software-defined infrastructure,and orchestration platforms.As technology changes and development accelerates,delivering secure software requires a culture that emphasizes shared responsibility for the security,stability,an

145、d efficiency of the software.In last years report,we asked survey participants to identify who is responsible for security in their organization.As one might expect,81%identified developers as having a responsibility for security.Surprisingly,however,only 28%identified the security team as having re

146、sponsibility,while only 23%said the responsibility lies with operations.Perhaps cynically,12%of the participants said the responsibility to security belongs to nobody.This year we decided to dig a little deeper into how organizations are doing in driving a culture shift that embodies security as a c

147、ore responsibility for all members of the organization.We asked our survey participants who they felt should be responsible for designing and implementing security controls in their software,as a multi-answer question.The results were more encouraging this time around but curiously a lot of weight c

148、ontinues to be put on the developers shoulders.All rights reserved.2020 Snyk41Not only is it not fair to ask developers to shoulder so much responsibility for software security,it is also counterproductive.Developers need to be enabled to do their part,but security teams need to drive that enablemen

149、t,and operations needs to be a part of actively monitoring it as well.So,while this years results are encouraging and do show growth,there is clearly more work to be done in this area.When we asked the participants about the security of their infrastructure,however,we found that the results were muc

150、h more balancedOperations teams were commonly identified butso were Developer and Security teams in almost equal numbers.However,the fact on this multi-answer question the responses were all less than 65%still indicates that respondents did not typically identify all three groups as being responsibl

151、e.Again,this indicates that more work can be done in shifting toward a shared-responsibility culture.Who should be responsible for security?2%63%56%0%25%50%75%100%56%3%OperationsDevelopersSecurity teamNobodyOther85%55%35%3%2%InfrastructureSoftwareMultiple responses allowed.42Securing the pipelineCon

152、tinuous integration(CI)is the foundation of software development.CI defines the automated steps for building,testing,and deploying software.It is essential for developing software in a time when constant change is the norm.CI provides the ability to automate in minutes what was historically a proces

153、s requiring manual approval steps that could take months to execute.Teams using CI measure the success of their development process by four key metrics:lead time for changes deployment frequency mean time to recovery change fail percentageAll of these metrics reflect an emphasis on speed.Speed is in

154、credibly valuable in software delivery,but should it come at any cost?Speed without reliable,consistent quality is not helpful.And speed without security is even worse.We noticed two things from Snyks State of Open Source Security Report 2020 that stood out to us.The first is that,increasingly,surve

155、y respondents feel that security for software and infrastructure should be shared among development,security,and operations teams.This cultural shift in the ownership of security is represented in the shift from DevOps to DevSecOps and CI is the centralized place where these teams are able to come t

156、ogether.By adding security to DevOps,teams are able to reap the benefit of speed that comes with automation,and they dont have to sacrifice security in the process.The second thing that stood out to us was the number of vulnerabilities in official base images.Containers are a central technology for

157、CI.In a CI pipeline,when a codebase is updated,the applications are run in clean containers that use images that contain all the tools and packages needed for the app.To benefit from CI,managing vulnerabilities in images is an absolute necessity.Even for organizations that create their own custom im

158、ages,Snyks State of Open Source Security Report 2020 has identified that official base imagesthe image from which custom images are createdhave many vulnerabilities.The official Node image with the latest tag has almost 700 known vulnerabilities!While speed is certainly a valuable metric to consider

159、 when developing software,consistent quality and security are also necessary for ensuring that the software we develop meets the expectations we set for ourselves and the expectations of our users.Guest analysis by Ron Powell,Technical Content Marketing Manager at CircleCIAll rights reserved.2020 Sn

160、yk43There are many different approaches that organizations may use to create a culture of shared responsibility.One of the more commonly discussed approaches is establishing a Security Champions program.The goal of such a program is to bring security expertise to the development organization.These p

161、rograms establish roles in the development team to create a community of security-minded developers.Security Champions programs are even referenced as security practices at the base maturity level in the OWASP SAMM model.We asked our survey participants about some of the more common approaches to es

162、tablishing this type of culture and bringing security into the development conversation.Despite the increasing adoption of DevOps/DevSecOps software delivery,a staggering 47%of organizations indicated that they have not implemented any of these practices.Programs to drive shared responsibility cultu

163、re0%20%40%16%5%Stand up meetings withDev,Sec and OpsCross training acrossDev,Sec and OpsSecurity champions programNo,none of these15%47%10%30%50%17%Dotted line reporting betweenDev,Sec and OpsMultiple responses allowed.44Creating a culture of shared securityresponsibility at SegmentOn a recent episo

164、de of The Secure Developer podcast,Leif Dreizler and Eric Ellett talked about the importance that customer data platform provider,Segment,places on the collaboration between development,security,and operations resources.Segment does not do sprints across their organizationinstead,teams operate indep

165、endently.However,through a consultative model,the security team is still integrated early in the development process to provide threat model and design review capabilities.At Segment,the idea of establishing empathy is baked into the culture of the security team.Within the team,Segment has employed

166、a concept of“Walk a mile in the developers shoes”.Ellett explained that the security team goes to great effort to understand how their security processes impact other areas of the organization.For instance,when they sought to roll out Multi-Factor Authentication,Dreizler spent a quarter embedded wit

167、h the development team.This provides the security team with invaluable context on the challenges that the development team faces in terms of what they are trying to protect.However,the collaboration focus doesnt end there.Ellett explained that there is the intention that similar initiatives would ha

168、ppen in the other direction.The plan is to bring people from other areas of the organization to sit with the security team and understand their world as well.Dreizler stated,“I think that this is what the goal of DevSecOps should be.Similar to DevOps,where you have operations people learning how to

169、code and now everything at Segments infrastructure is code.”Segment also firmly believes in creating the“paved road”.A guiding principle that the Segment security team operates under is“would this tool be used by the developer?”.In other words,there is a keen focus on ensuring that the adoption of s

170、ecurity controls is enabled by the ease of use.The ultimate focus,according to Dreizler,is“just make it as easy as possible for people to do what the right thing is.”Through this cooperative and empathetic approach,Segment has been able to grow a strong culture of collaboration in their organization

171、an example of how the promise of DevSecOps can be realized by ensuring all functions are aligned in their goal to do what is right for the organization.All rights reserved.2020 Snyk45Evaluating package healthA topic of growing conversation across the open source community is how to determine the hea

172、lth of packages.Understanding how actively and attentively a package is being maintained and updated timely with security fixes sounds like an easy task.However,when the possible metrics for measuring health are considered and analyzed,it becomes clear that this is a harder question to answer than i

173、t would seem.The various code repositories have attempted to help with this and do offer some useful tools that can provide some indication of which packages are trustworthy.Publishing things like issue counts,revision histories,pull request details,and even user feedback mechanisms all provide some

174、 level of reassurance.However,none of these by themselves tells a reliable story.For instance,while frequent updates to a package can be an indication of an actively maintained package(which is a good thing),excessively frequent package updates could have a negative impact.Maintenance of application

175、s that are dependent on that package could be complicated by having to initiate more frequent changes to apply the latest versions of the updated package.This is of particular concern where the updates introduce security-related fixes that need to be applied in a timely fashion.In our survey,we expl

176、ored what factors are commonly used to evaluate and ultimately select open source packages.Our results were also consistent with the idea that there is no single generally accepted answer to this dilemma.It is,however,encouraging to see that numerous practices are being adopted and most participants

177、 indicated that they use more than just one factor on which to base their decisions.How do you vet open source packages?80%Project has an active community0%40%60%20%59%58%65%21%6%53%Repository ratings or download countsFrequencey of releases/commitsCheck for known security vulnerabilitiesOtherCheck

178、for Responsible Disclosure PolicyMultiple responses allowed.All rights reserved.2020 Snyk46Container image healthEarlier we discussed some of the vulnerabilities found in the most popular base images on Docker Hub.So,with more and more organizations turning to container technology,how are organizati

179、ons going about ensuring the base images they select are secure?Many of the same complexities and considerations that affect decisions about package health also come into play with container health.As we saw earlier,simply being labeled as an“official image”on Docker Hub does not mean there are no v

180、ulnerabilities.What about feedback from others?Do ratings offer reliable measures?All of these issues and more need to be considered when attempting to select a secure image for your next deployment.We asked the respondents to our survey about the potential criteria they use when selecting base imag

181、es.The use of well-documented images and smaller lightweight images were the two most common practices.Good documentation assures that developers can understand what components are included in the image which in turn enables the selection of an image with only the appropriate modules necessary to su

182、pport the code that will run in the container.How do you evaluate container security?36%24%56%41%Only use welldocumented imagesPrefer smaller orlightweight imagesRecommendationsfrom others/reviewsOperating SystemPreferencesAbility to authenticatepackages(e.g.,dpkg sig)None of these17%21%Multiple res

183、ponses allowed.All rights reserved.2020 Snyk47Security practicesAlmost every software development organization understands that some level of security focus needs to be included in the development process before code is deployed.There is a wide variety of practices that security practitioners recomm

184、end and different organizations may implement one or many of them.From a security perspective,each practice serves a different purpose and so the recommendation is to implement all of them.However,the reality is that the decision to build a particular security practice into the pipeline is complex a

185、nd involves not only organizational maturity and risk tolerance,but also the ability of the delivery model to adapt to these activities without introducing obstacles to development.The mantra of pushing leftthat has been a part of the application security vocabulary for many yearsoften focuses on th

186、e ability to reduce friction and cost by identifying vulnerabilities early in the development process.To that end,it isnt too surprising to see that the use of Static Application Security Tools(SAST)is the most common activity across our survey participants.Over 1 in 4 responses indicated no common

187、security practices are in place.All rights reserved.2020 Snyk48There are two concerning numbers in these results though.First is that almost 26%of the participants indicated that they do not have any of the listed security practices implemented in their delivery pipeline.With security continuing to

188、be a top-of-mind concern for executives across most industries,it is surprising that over 1 in 4 responses indicated no common security practices are in place.Second is the relatively low use of Software Composition Analysis(SCA).Earlier we detailed the risks that open source dependencies,and in par

189、ticular indirect dependencies,post to software development.SCA is a powerful way to understand the dependencies of an application,identify if there are vulnerabilities in those dependencies,and enable monitoring of future vulnerabilities in an organizations software.Security practices in the deliver

190、y pipleline40%Static Code Analysis(SAST)Security test cases in QA0%20%30%10%20%57%19%28%8%26%19%Software composition analysisDynamic ApplicationSecurity Testing(DAST)Threat modelingNone of theseOther60%50%Multiple responses allowed.All rights reserved.2020 Snyk49As organizations adopt DevSecOps,auto

191、mation and tooling become key topics to help enable efficient delivery.In particular,when attempting to shift security from being a gate between delivery stages to being integrated into those stages,automation becomes crucial.Automated tools help eliminate slow feedback cycles that create friction f

192、or development and fail in adoption because they are simply too inhibitive of efficient development.In our survey,we asked our respondents whether they had enabled any automated security testing capabilities in their delivery pipelines.The results are encouraging in that many identified multiple cap

193、abilities.However,at the same time,over 38%indicated they have no automated capabilities.In light of the 26%who stated they have no security practices in place,this number isnt too shocking.Automated security testing capabilities0%20%40%49%42%Tests for known opensource vulnerabilitiesStatic sourceco

194、de analysisTests for vulnerablecontainer imagesNo automated testing39%27%10%30%50%Multiple responses allowed.38%of survey participants have no automated security capabilities.26%have no security practices in their pipelines at all.All rights reserved.2020 Snyk50Vulnerability remediationIt seems obvi

195、ous,but it is not simply enough to identify vulnerabilities in softwaretimely remediation of vulnerabilities plays a key role in reducing overall security risk.When it comes to open source,however,remediation can be a more complex issue.When vulnerabilities occur in the software youve developed,the

196、answer to remediation is simply to fix the code.However,when the vulnerability is in a direct open source dependency,the answer may be more complex.There may be an updated version of that package in which the vulnerability has been remediated that you can include in your code one-line change in your

197、 dependencies could be all it takes.However,if theres not an updated package with a fix,the options are a little more complicated.One option is to fix the code yourself.Hopefully,you would also submit the changes back in a pull request to the maintainer,thus making the package more secure for all.An

198、other option would be to open an issue with the maintainer and wait for them to make a fix.Of course,these decisions can get even more complicated when the vulnerability is in an indirect dependency.The point of this discussion is not to bemoan the complexity and risk of open source security,but rat

199、her to understand that these various factors and approaches to remediation can have a direct impact on how quickly organizations are able to respond to a vulnerability.Open source vulnerability expectationsIn our survey,we asked participants to share with us what their expectations are for package m

200、aintainers to address security vulnerabilities within their packages.Most said they would expect a fix in a week or less from the time the vulnerability is reported.Expectation for open source vulnerability fixesRelease8%A fewhours18%A day or lessA week or less47%A month or less18%1-3 months6%More t

201、han 3 months3%All rights reserved.2020 Snyk51Remediation performanceThe speed at which vulnerabilities get remediated once they are discovered is a constant concern of any mature vulnerability management program.Shorter vulnerability remediation timelines equate to reduced risk for the organization.

202、We investigated the monitoring of vulnerabilities that were discovered in projects scanned by Snyk to determine just how long it takes organizations to respond and remediate the issues once theyre identified.Of course,as discussed previously,the speed at which a development team can remediate a vuln

203、erability in an open source dependency is reliant on a number of factors,some of which are outside the control of the organization.Still,it is important to understand just how well organizations are able to react when a vulnerability notification comes through.Vulnerabilities fixed in projects scann

204、edFixed after 70 Days36%Fixed 20-70 Days29%Fixed 20 Days34%Fixed same Day1%A little more than one-third of vulnerabilities are fixed within 20 days of being discoveredAll rights reserved.2020 Snyk52What is particularly interesting about the results is the percentage of vulnerabilities that are succe

205、ssfully remediated in under 20 days.For most vulnerability management programs,that is a very high success rate.Its also interesting to note that some vulnerabilities are even remediated on the same day.On average,however,most vulnerabilities take over two months to be remediated,suggesting that the

206、re is more work to be done.Seeing that some have gone as long 16 months before they are remediated,confirms that we can improve as a community in how we address security vulnerabilities.However,it is important to note,when considering these numbers,that the severity of the vulnerability is not taken

207、 into account in this analysis.A common practice in vulnerability management programs is to set remediation timelines based on the severity of the identified vulnerabilities.Therefore,one can hope that those vulnerabilities that took significantly longer to be remediated are lower severity,and were

208、therefore not prioritized for remediation as quickly as higher severity items.However,a much deeper analysis would be needed to confirm if that is the case and such analysis was beyond the scope of this study.All rights reserved.2020 Snyk53Maintainer security performanceIt is no secret that one of t

209、he greatest contributing factors to the state of open source security is the ability of maintainers to produce secure code and to remediate security issues quickly once they are reported.Vulnerability remediationJust as we did last year,once again we looked at the percentage of known vulnerabilities

210、 in key ecosystems that had been remediated in subsequent versions of the package.The results are a mixed bag of good and bad news.In the Node.js space,63%of disclosed vulnerabilities have fixes availableup from 59%in the previous year.That is good news.But what happened with Java?Last year Java boa

211、sted an impressive 97%of vulnerabilities addressed with known fixes.However,in this years analysis,that number has dropped off considerably to slightly less than 81%.Python and Ruby for their part have remained relatively consistent year-over-year.Packages with known fixes0%50%100%63%81%96%84%PyPIRu

212、byGemsnpmMavenCentral25%75%All rights reserved.2020 Snyk54Maintainer vulnerability awarenessPerhaps some explanation for the numbers of vulnerabilities with available fixes can be found in an analysis of how maintainers become aware of vulnerabilities in their software in the first place.In the surv

213、ey,we asked how project maintainers become aware of new vulnerabilities in their code.There are many ways in which new vulnerabilities would be identified.Certainly,the preference would be that maintainers of the code identify the vulnerabilities themselves through some form of code review or analys

214、is.Indeed,the majority of participants indicated that this is one way they find vulnerabilities.External audits were also a popular answer.Disclosure by external parties ranked lower on the survey perhaps suggesting that most maintainers are more proactive about discovering vulnerabilities.Compared

215、to last years results for the same question,there are some positives and some negatives in this data.The percentage that indicated they would find the vulnerabilities on their own dropped from 72 to 67 percent.However,that may be offset by the number that indicated external audits as the source of i

216、nformation which climbed from 30%last year to almost 50%this year.Also encouraging is the percentage of responses that stated they dont find out about vulnerabilities in their code.That number dropped from 17 to 12 percent this year.How do you find out about vulnerabilities in your code?80%When I re

217、view my code0%40%60%20%48%31%67%11%12%25%Someone contacts me direcltyThrough an external auditSomeone opens a public issueI dontOtherMultiple responses allowed.All rights reserved.2020 Snyk55Report conclusionsWhile there were many interesting findings in this years report,the following are the five

218、areas that were the most notable in terms of their impact on the open source community.More than half of survey respondents view security as a shared responsibility across developers,security,and operations which is an improvement over 2019.New vulnerabilities are down 20%across the most popular eco

219、systems;npm saw the greatest reduction in vulnerabilities disclosed,yet retains the worst fix rate of the popular ecosystems.Vulnerabilities that have received attention for many years continue to be reported in high numbers;however,more complex and less understood vulnerability types had higher imp

220、act.Prototype pollution,for instance,affected over 25%of projects scanned by Snyk in 2019.The top ten most popular official container images have significant numbers of known vulnerabilities.Pulling an official image is not a replacement for regular security hygiene.There are still significant impro

221、vements to strive for as many still dont treat security with proper urgency:a third of vulnerabilities in projects were fixed in under 20 days,but another third took 70 days or more.All rights reserved.2020 Snyk56RecommendationsBased on the trends and themes identified in this years report,there are

222、 some key next steps that organizations and package maintainers can take to improve the security of their software.Open source maintainers Greater emphasis is still needed when it comes to inventorying open source.Creating greater visibility into the full dependency tree will drive proactive vulnera

223、bility identification as well as enabling more effective response to emerging threats.Education on new vulnerabilities and exploits for developers must be a priority to reduce the breadth of impact across multiple projects in new vulnerability types.Additionally,continued security hygiene and monito

224、ring is clearly needed regardless of a packages perceived health and popularity.Establish and track metrics regarding vulnerability remediation to ensure that expectations and actual achievement can be reconciled.Container security Pulling an“official”image does not guarantee that it is free from vu

225、lnerabilities.Regular security hygiene should be performed for any new container images used.Minimize container image size.“Latest”tags often pull the most comprehensive version of the image.However,in our research we found that using a“slim”image instead can reduce the number of vulnerabilities in

226、the image by as much as 95%.Kubernetes environments offer standard configuration options that should be default for any new cluster launched.Limiting root level access,ensuring audit logging is enabled,and preventing the installation of known bad modules are key steps that can be taken.Organizationa

227、l security culture Security at all phases of the delivery pipeline should be seen as a shared responsibility across the organization.Establish clear and common goals that apply to developers,operations,and security personnel.Launch formal programs such as security champions,job shadowing,and daily t

228、ask integration that drive empathy and understanding across Dev,Sec,and Ops disciplines.More comprehensive practices are needed in DevSecOps pipelines.Look to enable practices as early as user stories in the backlog and select automated security tooling that integrates with existing development and

229、pipeline management.Developer first securityTheres a lot of talk in the security industry about shifting left.About how its more effective to find vulnerabilities or security problems early in the process.About the need to scale security as digital transformation increases the volume and importance

230、of software to every business.But the reality is,to build a truly effective DevSecOps model,you need an approach that gives developers the ownership for security,and provide developer-first and friendly tools to enable them to successfully implement the security responsibility.You need to enable sec

231、urity teams to both support and govern the development team to manage security effectively.Developer-first SecurityA frictionless and intuitive security-focused developer tool enables developer adoptionEmpower both developer and security teams to tackle the application security challengeAutomated Re

232、mediationActionable fix advice and automated remediation workflows make it easy to fix,and not just find vulnerabilities.Security depthComprehensive,timely,accurate and enriched vulnerability database ensures issues are found quickly and fixed easily.Visibility and ControlReporting and prioritizatio

233、n features enable security teams to monitor security levels,and implement and govern policies.Protected byEnabling more than 400,000 developers to continuously find and fix vulnerabilities in open source libraries and containers.Open Source SecurityContainer SecurityLicense ComplianceSCHEDULE A DEMO

234、London 97 Hackney RoadLondon E2 8ETOffice info Tel Aviv 40 Yavne st.,first floorBoston 200 Berkeley,24th floor Boston,MA 02116Develop fast.Stay secure.Report authorAlyssa Miller(AlyssaM_Infosec)Report contributorsSimon Maple(sjmaple)Ron Powell (whyD0My3y3sHurt)Vincent Danen(vdanen)Report designGrowth Labs(GrowthLabsMKTG)Report editorEirini Eleni Papadopoulou (Esk_Dhg)