News

App Security Report Examines 'Fragility of Open Source'

• By David Ramel
• 02/09/2023

The perpetual security problem of using open source software that may contain flaws or vulnerabilities was once again highlighted in an application security study.

Coming from AppSec specialist Veracode, the State of Software Security 2023 report examines .NET, Java and JavaScript apps. The firm's 13th such annual report is based on data collected from Veracode services and customers, including many scans of various types. The report includes findings about applications that were subjected to static analysis, dynamic analysis, software composition analysis and/or manual penetration testing.

The company said the three main takeaways from the report, which was topped by the tagline, "An Ounce of Prevention is Worth a Pound of Cure," were:

• 32 percent of apps contain security flaws at the first scan, and by the five-year mark, this jumps to 70 percent.
• Certain choices made early in development can measurably improve security posture in the long run.
• Open source may be extremely fragile, so proceed with caution.

A whole section was devoted to that last point, which was also a main focus of last year's report. Even though this was a focus last year, the company said that for the 2023 report, it took some first steps to analyze and profile open source repositories, including an analysis of GitHub repositories that were scanned with composition analysis.

While GitHub hosts millions of repositories, Veracode identified 29,783 that were actively used in production code by its customers. "This means this is not just a dragnet analysis looking for what we might arbitrarily think is malicious or filtering using stars or some other method for inclusion/exclusion," the report said. "The repos in this analysis are actually included in production code. What we are measuring is the fragility of legitimate packages."

One of those measures concerns licensing, with a report chart showing that 12.2 percent of libraries in use with repositories in GitHub had no license defined. As can be seen in the graphic below, the report said, "Not paying attention to licensing can introduce risk to a commercial application. This issue can come up at inopportune moments. Such as when due diligence is performed during a merger or acquisition. No license means no usage rights, and that is why it is important not to ignore this."

Other potential factors that might affect open source software quality are the age of repositories,

and the amount of time that has passed since the last commit:

Another potential contributing factor to open source software quality is the number of libraries and dependencies that an app uses. "Developers build their applications using libraries completely outside their control, establishing dependencies for basic functions that an application needs," the report said. "Some of these dependencies then introduce further dependencies and things move fast out there."

The company acknowledged it was delving into "a mostly philosophical area" when examining contribution cadence and project team size, so it had to accept it doesn't yet know all the answers to questions like:

• Are repository demographics and low commit cadence representative of potential problems?
• Is the last commit indicative of inactivity?
• Are either of these things cause for concern?

"We illuminated a few things, and more questions came up," the report said. "We feel our work here raises some real questions and challenges the conventional wisdom around pre-calculated 'confidence scores.' This research should spur some healthy debate on what constitutes a healthy or safe library or repository."

Veracode also offered some advice on the open source issue:

• Prioritize your efforts by looking at vulnerable methods analyses and the existence of public exploits. Consider that it might take weeks or months for a vulnerability to appear in the National Vulnerability Database (NVD) and how much advance warning means to your team. Any SCA solution in use should leverage multiple sources for flaws (not just NVD) to give advanced warning to teams. Once a vulnerability is disclosed (even via unofficial channels), it's a race against the clock to when active exploitation begins. It might take weeks to months for a vulnerability to appear in the NVD, and by then, in-the-wild exploits may have already begun.
• Set organizational policy around what vulnerabilities you're willing to accept, understanding that different applications will have different risk profiles and risk tolerances. It's more sustainable to enforce policy programmatically than trying to maintain an internal repo of "safe" libraries, which can be too resource intensive for all but the most well-staffed organizations.
• Consider ways to reduce your third-party dependencies. Think back to 2016 and the left-pad package6 that was 11 lines long. For simple "shortcut" code that is included by default, ask why it is included. Especially if it introduces new dependencies that are required in order for your code to work. If developers can write the code easily, and it's low risk to do so, then try to reduce dependencies that can introduce fragility, or worse, increase your attack surface. It is worth calling out that no one should be trying to roll their own crypto!

"What does this all mean for you?" Veracode said in a blog post. "Tackling technical debt by remediating security flaws as early and quickly as possible can save teams major headaches -- and hefty 'interest' payments in the form of the time it takes to remediate accumulated flaws -- down the road," Veracode said. "Thankfully, there are data-driven, concrete steps teams can take to help meet this objective, including increasing scan cadence, scanning via API, and implementing developer education."