WIXLIB

LIBRARY SELECTION52.5%“ Unsure” means that either theydon’t have a formal process orthat they are unaware of theprocess they do have and maybe simply ignoring it.28.4%Library selection processCONTAINERS?Veracode State of Software Security: Volume 11 / Open Source EditionWe first asked, “Do you have a formal processfor selecting third-party libraries?”1019.1%It is unsurprising that customers who care enoughabout software security to purchase scanningsoftware, overwhelmingly, have a formal processfor library evaluation, though the large fraction(29 percent) who are unsure is a bit concerning.This means that either they don’t have a formalprocess or that they are unaware of the processthey do have and may be simply ignoring it.Developing, sharing, and following a unified policycan be difficult among large and disparate teams,likely leading to the uncertainty we see in Figure 3.WHAT ABOUT MYUnless you’ve been living undera rock for the past few years,you’ve probably heard terms like“container” and “docker” and“Kubernetes” being tossed aroundthe application development world.Containerization has been a boonto developers much in the sameway third-party libraries are. Itallows them to not only package uptheir applications and libraries torun on some predefined server OS,but also allows them to bring thewhole OS along with them.YesUnsurePERCENT OF RESPONDENTSFigure 3Number of organizations with a formalprocess for selecting libraries (n 1.5k)NoThis type of inclusion requires itsown analysis, and we have someresearch coming down the pipelinelooking into the unique challengespresented by containers.

LIBRARY SELECTIONLibrary evaluation and problemsOK, so you have a process, but what is that process?To that end, we examined whether users who always consideredone of the previous criteria have fewer issues in a particular area.LICENSINGSpecifically, we asked what developers look for when they areconsidering adding a new library. The results can be seen inFigure 4. Unsurprisingly, the leader here is functionality. After all,without the correct functionality, what’s the point of including abig pile of code? Next in line is licensing, followed by security. It isnot surprising that all of these are considered at least frequently by80 percent of respondents; all these things matter when selectinga library. What might be a better split here is whether they arealways considered. This is an indication that a particular needis part of the selection process.When evaluating a third-party library, how often do you consider the following: (n 724)We start with licensing 4 in Figure 5, and we see that repositories are muchmore likely to have license issues on the latest scan of the default branchif survey respondents say they don’t “always” consider the license whenPercent of repositoriesselectinglibraries.is ona prettywithlicense Thisissueslatest stark divide. While known violationsresultingin legalactionsdefaultbranchscanare rare, when they do occur, they can cost bigmoney (up to 150k per instance). Ensuring that you are allowed to use aparticular library and making that part of your evaluation process seemslike a low-cost hedge against major future headaches.PERCENT OF REPOSITORIES WITH LICENSE ISSUES27.0%Veracode State of Software Security: Volume 11 / Open Source EditionAlways11FrequentlyRarely NeverSupport40.9%40.9%15.4%Project nsing62.5%Functionality23.2% 11.0%67.1%25.7%PERCENT OF RESPONSESFigure 4 Priorities when selecting libraries (n 724)Developer always checks license54.2%Developer does not always check licenseFigure 5 Scanning for license issues resolves problemsSECURITYLicensing is certainly an issue, but what about the main event: Security?Figure 6 indicates that having a formal process reduces by a small amountthe percentage of libraries in repositories that have vulnerabilities. TwoPercent of repositoriesissuespresent themselves in this result. First, as we saw last year, almost allwith third-party vulns onrepositorieslibraries with some sort of vulnerability. The other is thatlatest defaultincludebranch scanthe data is biased towards those who do think about security; they boughtVeracode products after all. But even in the face of these two issues thatwould likely obscure any difference, we can still find one of about 3.5 percent.PERCENT OF REPOSITORIES WITH VULNERABILITIES IN THIRD-PARTY LIBRARIES80.7%84.2%Developer always considers securityDeveloper does not always consider securityFigure 6 Formal security process reduces vulnerabilities4We’d start with “functionality,” but Veracode can’t make a library do what you want it to do.

LIBRARY SELECTIONVeracode State of Software Security: Volume 11 / Open Source Edition12Picking libraries is just the start; developers alsoneed to maintain them. Security issues crop up,new functionality is added and old is deprecated,projects are abandoned. Taking care of these librarieswhile they are under development is a challenge.In this section, we examine how developers handlethe changes to the libraries they use.

LIBRARY SELECTIONVeracode State of Software Security: Volume 11 / Open Source Edition13Most libraries arenever updatedOne striking fact is that once developerspick a library/version, they tend to stickwith it. Figure 7 shows that 65 percent oflibraries appear in the first scan of therepository and are never updated, withan additional 14 percent added at somepoint during development and neverupdated to a new version.I know what you are thinking, “Well,some of these repositories might yetbe young, you might not have seen thefull life of the application.” Nope. Evenif we restrict this to repositories thathave relatively long lifespans and manyscans, 73 percent of libraries are addedand never updated (Figure 8). As witheverything in application development,this depends on the language of course.PERCENT OF LIBRARIES65.0%In first scan, never updatedAdded after first scan, never updatedIn first scan, updated or droppedAdded after first scan, updated or dropped14.0%11.4%9.6%Figure 7 How often developers update librariesPERCENT OF LIBRARIES(minimum 100 scans, 1 year of development)46.0%In first scan, never updated27.0%Added after first scan, never updatedAdded after first scan, updated or droppedIn first scan, updated or dropped13.9%13.1%73 percent of libraries areadded and never updated.Figure 8 How often developers update libraries over time

LIBRARY SELECTIONRestricting to repositories we have significant data on (100 scans over one year), we see thatsome languages get more attention than others. We examine the difference in Figure o44.2%Swift38.9%Veracode State of Software Security: Volume 11 / Open Source EditionPython1437.7%PHPPERCENT OF LIBRARY VERSIONS IN FIRST SCAN THAT NEVER UPDATEFigure 9 Libraries never updated by languageAn interesting thing here is that PHP,usually the security black sheep amonglanguages, has the lowest rate of “set itand forget it.” While it shines here, sadlyit won’t last as we’ll see later.

PERCENT OF LIBRARIES NOT YET UPDATEDLIBRARY SELECTIONHow long do they stick aroundbefore being updated?100%Fifty percent of libraries will takelonger than 21 months to update.75%Many libraries have never seen an update, even afterone year, but how long does it take to update thosethat actually do get updated?50%25%0%0 year1 year2 years3 years4 yearsTIME15PERCENT OF LIBRARIES NOT YET UPDATEDVeracode State of Software Security: Volume 11 / Open Source EditionFigure 10 Time to update librariesConsistent with the “most libraries have never beenupdated” stat, survival analysis estimates that librariesstick in applications for a very long time. Fifty percent willtake longer than 21 months to update, with an estimated25 percent not being updated after as long as four years(the time horizon of our data).100%Fifty percent of librarieswithout vulnerabilities willtake 665 days to update.75%50%25%0%0 yearLibraries withno known vulnerabilitiesFifty percent of librarieswith vulnerabilities willtake 414 days to update.1 yearLibraries with vulnerabilities2 yearsWe use a fancy statistical technique called survivalanalysis.5 Survival analysis is a technique developed mainlyto understand the survival time of patients facing varioustypes of diseases and inferring the effects of treatment.6In short, it works like this, we look at the lifetime of thosewe know are updated and use that to estimate how longthe ones that haven’t been updated yet will stick around.The results can be seen in Figure 10.3 yearsTIMEFigure 11 Time to update vulnerable libraries5In particular we are using a Kaplan-Meier estimate to understand the time to update libraries.6True SOSS fans will remember us using this kind of analysis going back years.4 yearsBut we are here to talk about security, so let’s not justthink about how long it takes developers to updateto the next version, but how long it takes them to fixvulnerable libraries, and good news, vulnerable librariesare updated faster!Figure 11 shows that it takes about 665 days for 50 percentof libraries without vulnerabilities to be updated, but only414 for those with vulnerabilities. Programming note, thisdoesn’t mean developers are taking more than a year toupdate or fix once alerted of a vulnerability. Rather, thisincludes the time when the library is used but isn’t knownto have a flaw. In the next section, we examine the reactiontime of developers once they know there is a flaw.

Veracode State of Software Security: Volume 11 / Open Source EditionSECTION FOUR16FIXINGVULNERABILITIES19Severity20Dependency type21Vulnerability type22Language23Developer resources

FIXING VULNERABILITIESThe previous sections asked how long it takes to updatevulnerable libraries (whether the vulnerability is known or not),but this excludes the time the vulnerability was unknown or thetime it was known, but the developers weren’t notified. Oncea developer sees the result of the scan on their repository,how fast do they react?The answer in Figure 12 is pretty darn fast.This chart is going to act as our Rosettastone for the next few charts.Veracode State of Software Security: Volume 11 / Open Source EditionPERCENT OF VULNS17The “50% of vulns” acts as a measure of‘typical’, while 25 percent and 75 percentgive us a good sense of how quickly thecurve descends. SOSS fans will rememberthese ‘interval’ charts appearing inSOSS Volume 9.X-AXISOne last note, time on the horizontal axisis on a ‘log scale’, that means each stepis an order of magnitude increase ratherthan a fixed time period. If that’s too much,don’t worry, we’ll directly label the pointsso you can make your own comparisons.75% ofvulns fixedin 351 DAYS100%PERCENT OF VULNERABILITIES NOT YET ADDRESSEDAs we do more ‘time to update vulnerablelibraries’ curve comparisons, things canget awfully cluttered. So we’ve simplifiedthe curve to the right into a segment.50% ofvulns fixedin 89 DAYS25% ofvulns fixedin 7 DAYS75%50%25%0%1 hour1 day7 days2 monthsDAYS SINCE VULNERABLE LIBRARY SCANNEDFigure 12 Time to fix vulnerable libraries once alerted to the issue1 year4 years

VULNERABILITY SEVERITY LEVELFIXING VULNERABILITIES75% of highseverity vulnsfixed in 287 DAYS50% of highseverity vulnsfixed in 65 DAYS25% of highseverity vulnsfixed in 21 HOURSHighLow107 DAYS7 DAYSMedium28 DAYS8 HOURS263 DAYS25% of all vulns1 hour1 day381 DAYS50%7 days2 months75%1 yearDAYS SINCE VULNERABLE LIBRARY SCANNEDVeracode State of Software Security: Volume 11 / Open Source EditionFigure 13 Library update speed based on flaw severity18In fact, nearly 17 percent of vulnerable libraries are fixed withinan hour of the scan that alerted the developer to the vulnerability;25 percent are fixed within seven days. The bump seen inFigure 13 indicates that many developers probably scan weekly,see the vulnerabilities, and update. After that, 50 percent of vulnsare fixed within three months, and 75 percent within a year.Some vulnerabilities linger, and we’ll look at what causes thatlingering shortly. The kernel of truth in Figure 13 is that oncedevelopers are made aware of flaws they can (and do!) takeaction quickly. Having the right information makes applicationsmore secure, faster.TIME IT TAKES TO FIX VULNERABLE LIBRARIESWithin one hour17%50%Within one weekWithin one year25%Within three months75%

Veracode State of Software Security: Volume 11 / Open Source EditionVeracode tracks vulnerabilityseverity, partially based on CVSSscore, so we can see whetherhigh-severity vulnerabilities getaddressed first. Interestingly, noclear trend emerges in Figure 13.Low-severity vulns are fixedthe fastest, and high-severityvulnerabilities are fixed slightlyfaster than the population atlarge. As a bit of foreshadowing,allow us to speculate thatother factors are driving thereplacement of libraries.19HighSo now we know that mostvulnerable libraries get updatedquickly, but are developersprioritizing the dangerousones first?It’s possible that most developersare unconcerned with severity,but luckily we had the foresightto ask developers if this was afactor, and, lo and behold, some,but not all, respondents do careabout severity. If we look at surveyrespondents and see if theyconsider severity in Figure 14,we find that those developers fixlow- and medium-severity issuesmore slowly, and high-severityissues much more quickly, exactlyas you’d expect.75% ofvulns fixedin 557 DAYS50% ofvulns fixedin 126 DAYS25% ofvulns fixedin 16 DAYSVery important279 DAYS28 DAYS551 DAYSNot very important25% of all vulnsVULNERABILITY SEVERITY IMPORTANCEFIXING VULNERABILITIESSeverity50%75%Medium75% ofvulns fixedin 513 DAYS50% ofvulns fixedin 206 DAYS25% ofvulns fixedin 21 DAYSVery important80 DAYS17 HOURS501 DAYSNot very important25% of all vulns50%75%Low50% ofvulns fixedin 392 DAYS25% ofvulns fixedin 78 DAYS75% ofvulns fixedin 619 DAYSVery important19 DAYS131 DAYS525 DAYSNot very important25% of all vulns1 day7 days50%2 monthsDAYS SINCE VULNERABLE LIBRARY SCANNEDFigure 14 Effect of prioritizing severity of security issues on update time75%1 year

If it’s not severity affectingupdate time, it may besomething else like exactlyhow intertwined a particularlibrary is with your project.Veracode State of Software Security: Volume 11 / Open Source EditionVULNERABLE LIBRARY TYPEFIXING VULNERABILITIESDependency type20So, we next examined how different dependency types affect the speedof updating to non-vulnerable versions. What we see again easily fitsour intuition in Figure 15. Direct dependencies are the easiest (fastest)to fix. Things get trickier with transitive dependencies; it may be that afix will break some functionality in the direct library, meaning a slowerand more difficult fix process.50% ofvulns fixedin 154 DAYS25% ofvulns fixedin 8 DAYS75% ofvulns fixedin 370 DAYSBothDirect90 DAYS7 DAYSTransitive62 DAYS4 DAYS25% of all vulns50%7 days1 month350 DAYS333 DAYS75%1 yearDAYS SINCE VULNERABLE LIBRARY SCANNEDFigure 15 Effect of library dependency type on update timeWhen a library is both a directand a transitive dependency,things get complicated with fixestaking nearly 2.5 times longer.

FIXING VULNERABILITIESVulnerabilitytypeVulnerabilities that we expect to be complex, such as “Arbitrary Code Execution,”take a significantly longer timespan to fix than a typical vuln (187 days asopposed to the 89 days across all vulnerabilities). In contrast, things likePrototype Pollution should be relatively easy for library developers to address,i.e., one additional line that checks to make sure user provided objects don’t tryto modify proto attributes. So why would we expect to see a difference in fixtime for those just using the libraries? If a flaw is complex for library developersto fix, it may require fundamental changes to the way the library operates,making integrating those changes into downstream applications harder.We can imagine things that affect thefundamental functionality of a librarymight take the library developers a whileto address and the patch might alter thefunctionality of the library. The particulartype of vulnerability (here by CWE) is at leasta partial description of this complexity, andFigure 16 looks at the top 10 most commonlyseen vulnerabilities.Another aspect ofcomplexity may beexactly what the natureof the vulnerability is.75% ofvulns fixedin 444 DAYS50% ofvulns fixedin 187 DAYS25% ofvulns fixedin 15 DAYSArbitrary code execution21VULNERABILITY TYPEVeracode State of Software Security: Volume 11 / Open Source EditionDenial of service (DoS)Xml external entity (XXE)Cross-site scripting (XSS)100 DAYS7 DAYS94 DAYS7 DAYS94 DAYS90 DAYS76 DAYS7 DAYSAuthentication bypass61 DAYS2 DAYSDeserialization of untrusted dataInsecure cipher7 DAYS7 DAYSInformation disclosurePrototype pollution104 DAYS7 DAYSRemote code execution60 DAYS2 HOURS41 DAYS2 HOURS25% of all vulnsFigure 16Effect of vulnerability typeon library update time1 day7 days279 DAYS364 DAYS515 DAYS451 DAYS378 DAYS351 DAYS251 DAYS232 DAYS232 DAYS50%1 monthDAYS SINCE VULNERABLE LIBRARY SCANNED75%

FIXING VULNERABILITIESLanguageOnce again, we feel obligated to drive home the point that nearly everything depends on language,and fix times are of course no exception. There are some remarkable results in Figure 17.ORDERINGSPEEDFirst, the ordering (here by the time to resolve 50 percent of libraryvulnerabilities) is unusual from how “secure” different libraries in differentlanguages were last year. For example, PHP had a high percentage of librarieswith vulnerabilities, a high density of those flaws, and a high percentage offlaws with Proof of Concept exploits publicly available.7 But here we see thathalf of vulnerable libraries in PHP applications are fixed in a little over twomonths, the third-fastest among languages. A heaping dose of surprise atthis result is due to the fact that last year we saw PHP performing dead lastwhen examining flaw density in libraries and the number of flaws introducedinto applications by PHP libraries.LIBRARY LANGUAGEVeracode State of Software Security: Volume 11 / Open Source Edition227 DAYSJava106 DAYS4 DAYSRuby86 DAYS36 DAYS 65 DAYSPHP5 HOURS8 “Forever vulnerabilities.”1 day7 daysDAYS SINCE VULNERABLE LIBRARY SCANNEDFigure 17 Time to update insecure libraries by language240 DAYS237 DAYS82 DAYS25% of all vulns tate of SoftwareSSecurity Open SourceEdition 2020.504 DAYS127 DAYS63 DAYS29 MIN 58 MIN1 hour364 DAYS96 DAYS7 DAYSGoJavaScript775% of50% ofvulns fixed vulns fixedin 150 DAYS in 357 DAYS25% ofvulns fixedin 21 DAYS.NETPythonTwo frankly b

dynamics of library development and how developers react to library changes, including the discovery of flaws. We'll look at how library popularity has changed over the last two years. We'll see how often and quickly libraries are updated (not often), and how quickly flaws are addressed (surprisingly quickly!). We'll also dive deeper into those fixes and see when updates might be hard .