As vulnerability management workloads explode in the era of increased software supply chain security risks, research published today suggests that only around 3% of current vulnerabilities are actually accessible to attackers. The data implies that if application security (appsec) professionals and developers focus on fixing and mitigating what is truly attackable, they could significantly reduce the strain on their teams.
The new study from ShiftLeft, the AppSec 2022 Progress Report, suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on “attackable” ones. Data from the report shows that developers saw a 97% reduction in false-positive library upgrade tickets once they factored in the attack when reviewing used packages with critical vulnerabilities.
If true, that would be a welcome relief to many. Managing vulnerabilities was hard enough as it is, but the added complication of third-party vulnerabilities – especially the magnitude of the impact of these vulnerabilities that reverberate across a lot of software – creates an even tougher workload that can only be managed through effective prioritization. Security and developers can only access so many vulnerabilities in so many applications in a given time period. They need to ensure that the ones they fix or mitigate with compensating controls are the ones that matter.
What does “attackability” mean for security vulnerabilities?
Determining what is attackable requires looking beyond the presence of open source dependencies with known vulnerabilities and examining how they are actually being used, says Manish Gupta, CEO of ShiftLeft.
“There are many tools that can easily find and report these vulnerabilities. However, there is a lot of noise in these results,” says Gupta. “For example, they don’t take into account how the dependency is used in the application; they don’t even wonder if the app even uses the dependency. »
The idea of analyzing attackability also involves evaluating additional factors like if the package that contains the CVE is loaded by the application, if it is used by the application, if the package is in a path controlled by the attacker and whether it is accessible. through data streams. In essence, this means adopting a simplified approach to threat modeling for open source vulnerabilities, with the goal of significantly reducing fire drills.
CISOs are already all too familiar with these exercises. When a new high-profile supply chain vulnerability like Log4Shell Where Spring4Shell hits secondary industry channels and then explodes into media headlines, their teams are expected to spend long days and nights figuring out where these flaws affect their application portfolios, and even more hours applying fixes and mitigations to minimize risk exposures.
At this point: the report noted that 96% of Log4J’s vulnerable dependencies were not attackable.
Foreground software dependencies
Reliance on open source dependencies – both first-hand and via third-party dependencies – is increasing in modern development stacks.
“For any major application that uses a large number of dependencies, it’s common to have new CVEs several times a month,” says Gupta. “Multiply that by all the apps in the organization, you can imagine it’s not easy to keep up with all the upgrades.”
While updating a package can be easy, he says the development work associated with such a change can often be significant. Often, a single library upgrade can precipitate a battery of new tests, not only for security, but also for functionality and quality, and this can potentially require code refactoring.
To read the full article, visit dark reading.