Open Source Flaws Take Years to Find But Just a Month to Fix

Companies need to embrace automation and dependency tracking to keep software secure, GitHub says in its annual security report.

4 Min Read
Dark Reading logo in a gray background | Dark Reading

Developer mistakes and indirect dependencies are the two main sources of vulnerabilities in open source software projects, which together are expected to cause the majority of security alerts in the next year, according to GitHub's annual Octoverse report, published today.

Using data collected from its own platform, GitHub found the vast majority of projects used open source software, from a low of 65% for Java applications to a high of 94% for JavaScript applications. On average, a vulnerability goes undiscovered for 218 weeks, or more than four years, while it takes just over a month to fix the average vulnerability.

Developers must anticipate the need to fix issues quickly and improve open source security, rather than finding ways to reduce reliance on open source, says Maya Kaczorowski, senior director of product management for GitHub.

"Rather than try to offset the use of open source, embrace it," Kaczorowski says. "Increased transparency and information about what you're consuming in your software supply chain allows you to feel more confident that you're appropriately addressing risks, such as security vulnerabilities, that you may be consuming."

For the report, GitHub scanned more than 45,000 active repositories on its service that use one of six major open source software ecosystems — such as Node Package Manager (NPM) for JavaScript or RubyGems for Ruby — and have their dependency-graph feature turned on. The reliance on open source projects leads to vulnerabilities trickling down from one open source library to the programs that depend on it, with an average of 59% of active repositories likely to receive a vulnerability alert from GitHub's Dependabot service in the next year.

While the average program in the languages tracked by GitHub has fewer than a dozen dependencies — 10 for JavaScript, eight for Java, and six for Python, for example — those packages often rely on other open source libraries. JavaScript, for example, had a whopping 683 transitive dependencies, on average, compared with 70 for PHP and 68 for Ruby — the next two highest dependency counts.

Developers should focus on minimizing their applications' attack surface area by removing unnecessary dependencies and updating their dependencies regularly, Kaczorowski says.

"Proactively, security teams should help developers shift left to catch security issues early by looking for security issues before they are introduced," she says. "All developers, not just those using NPM, should keep the dependencies up to date and prune dependencies that aren't needed. You don't have to patch something that's not in your environment."

In addition, developers should use security tests and automated tools to catch vulnerabilities in their code, and they should also watch out for malicious attempts to insert backdoors into their projects.

A survey of 521 random samples of vulnerabilities found that 17% were maliciously inserted into software projects, but those only accounted for 0.2% of malicious activity because those projects were rarely used, accordin to the GitHub report. Every so often, however, attackers are successful in inserting code into an open source library, and if other projects rely on that library, it can lead to widespread impact. 

Yet, by far, the vast majority of security impact was created by developer mistakes that resulted in vulnerabilities. 

"A big part of the challenge of maintaining trust in open source is assuring downstream consumers of code integrity and continuity in an ecosystem where volunteer commit access is the norm," GitHub states in the report. "This requires better understanding of a project's contribution graph, consistent peer review, commit and release signing, and enforced account security through multifactor authenticatition (MFA)."

The report also highlights the success of GitHub's Security Advisory service, which gives projects a place to post security advisories about newly discovered flaws. While the advisory service started only 18 months ago, after GitHub officially became a CVE Numbering Authority (CNA) for the Common Vulnerability Enumeration (CVE) project, the service has already accounted for more than 3,000 new vulnerability reports

"For projects that didn't have existing disclosure lists or processes, this is a marked improvement," Kaczorowski says. "We want to avoid purposely or accidentally reporting security issues where they might get lost or be hard to find, and instead enable users to come to a single place to see what affects their environment."

JavaScript and NPM accounted for 26% of the vulnerabilities reported, Java and the Maven ecosystem accounted for 24%, and Python and the Python Package Index (PyPI) accounted for nearly 20%. The NPM ecosystem produced the largest share of critical advisories, about 14%.

About the Author

Robert Lemos, Contributing Writer

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights