Only 3% of open-source software bugs are actually attackable, researchers say

With vulnerability-management workloads ballooning in the era of heightened software supply chain security risks, a study out today suggests that only about 3% of today’s flaws are actually reachable by attackers. The data implies that if application security (appsec) pros and developers work to focus on fixing and mitigating what’s truly attackable, they could drastically reduce the strain on their teams.

The new study by ShiftLeft, the 2022 AppSec Progress Report, suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on the “attackable” ones. Data from the report shows that developers saw a 97% reduction in false-positive library upgrade tickets once they considered attackability when examining packages in use with critically rated vulnerabilities.

If true, this would be a welcome relief to many. Vulnerability management was already hard enough as is, but the added complication of third-party flaws — especially the scale of impact of these vulnerabilities rippling across numerous pieces of software — creates an even more daunting workload that can only be managed through effective prioritization. Security and developers can only get to so many vulnerabilities in so many applications within any given time period. They need to make sure the ones they fix or mitigate with compensating controls are the ones that count.

What Does ‘Attackability’ Mean for Security Vulnerabilities?

Making the determination of what’s attackable comes by looking beyond the presence of open source dependencies with known vulnerabilities and examining how they’re actually being used, says Manish Gupta, CEO of ShiftLeft.

“There are many tools out there that can easily find and report on these vulnerabilities. However, there is a lot of noise in these findings,” Gupta says. “For example, they do not consider how the dependency is used in the application; they don’t even consider whether the app even uses the dependency.”

The idea of analyzing for attackability also involves assessing additional factors like whether the package that contains the CVE is loaded by the application, whether it is in use by the application, whether the package is in an attacker-controlled path, and whether it is reachable via data flows. In essence, it means taking a simplified threat modeling approach to open source vulnerabilities, with the goal of drastically cutting down on the fire drills.

CISOs have already become all too familiar with these drills. When a new high-profile supply chain vulnerability like Log4Shell or Spring4Shell hits the industry back channels, then blows up into the media headlines, their teams are called to pull long days and nights figuring out where these flaws impact their application portfolios, and even longer hours in applying fixes and mitigations to minimize risk exposures.

To that point: The report noted that 96% of vulnerable Log4J dependencies were not attackable.

Software Dependencies to the Fore

Reliance on open source dependencies — both first-hand and through third-party dependencies — is growing in modern development stacks.

“For any major application that uses a large number of dependencies, it is common to have new CVEs multiple times a month,” says Gupta. “Multiply that by all the apps in the organization, one can imagine it is no easy task to keep up with all the upgrades.”

While updating a package might be easy, he says the associated development work surrounding such a change can often be significant. Often a single library upgrade can precipitate a battery of new tests not just for security but for functionality and quality, and it potentially could require refactoring of code.

To read the complete article, visit Dark Reading.