When I started my cybersecurity career, I was a consultant leading various vulnerability assessment projects within given scopes and recommending risk remediation solutions, commonly known as ‘penetration testing’ activities.
Over the past few years, external consultants have been replaced by internal security teams, as organizations from a wide range of industries have realized the growing risks and need for such in-house capabilities. Combining my software development skills and consulting experience, I joined such a team at wix.com.
One of the first, and most alarming, things I witnessed in my new position was the increasing gap between how vendors see cybersecurity and how practitioners actually experience it. Take open source software security as an example, which is a growing concern that is rapidly gaining more attention, and for good reason. In recent years we have experienced numerous truly impactful breaches involving open source software, and have learned about easily exploitable software defects that were introduced by its supply chain.
Practitioners deal with an array of threat agents that try to exploit any weakness. It doesn't matter if the exploited weakness is caused by open source software, misconfiguration, problems in your cloud security setup, or limited security capabilities of your custom code. These weaknesses introduce a true challenge in prioritizing OSS security related tasks.
Vendors, on the other hand, are busy devising new and improved approaches, knowledge and methodologies to deliver security functions. Excellence in cybersecurity comes from mastering a specific problem with great focus. As such, vendors will often mark issues they are specialized in identifying or detecting as more urgent than they actually are, and portray their solution as the “end game” fix to the problem.
On the practitioner's side, the day-to-day reality of cyber defense is fundamentally different. With countless alerts and occasional incidents - every agile organization quickly learns that there are no magic solutions, and that it needs to orchestrate different activities and tools. Practitioners know that cyber defense isn't a one-time operation of fortifying your castle - It is a living part of the company, and its job is to protect the business at a low, or sustainable cost.
But what reasons lie behind this astronomical growth in cyber attacks?
Well, put quite simply, the underlying cause is that breaching digital services is easy money. Even when considering the highest profile of targets, for example - classified defense industries - physically breaching their facilities and extracting secret plans is much harder than infecting an employee workstation with malware and exfiltrating a bunch of files. Add to this the ingredient that makes the hi-tech industry the birthplace of so many unicorns - every person with a computer plays a role - be it a maker, a user or an attacker.
And this brings us back to OSS security. Today, OSS security alerts can be easily integrated into the lifecycle of any software engineering organization. With great commercial vendors, open source tools, and solutions in your source code management you can easily assess known vulnerable OSS used in your software. Unfortunately, the next step is much harder. OSS isn’t always very easy to upgrade, and does not necessarily offer a quick fix.
Despite advances in vulnerability management, the field is still prone to significant problems. First and foremost, we return to the timeless issue of getting developers to make a fix, which they aren’t normally very excited about. They may ask for proof, adding to the red tape of accomplishing what would otherwise be considered an easy fix. To add more insult to injury, proving the exploitable nature of OSS security issues is oftentimes challenging.
Despite these hurdles, ignoring this problematic field is not an option. Given their nature, OSS vulnerabilities are more widespread and known to exist. As a result, weaponized exploits for such defects, such as log4shell can be easily used -- even by attackers that are much less resourceful then the advanced groups that identified the issue. The OSS ecosystems and the supply chains integrated with them are highly attractive for malware distribution.
Rather than admitting defeat in the face of OSS vulnerabilities, there are a few measures AppSec professionals can take.
First - the backlog. This starts with gaining full visibility of your asset inventory and corresponding vulnerabilities. Next, create a system or use a tool to prioritize vulnerabilities based on their overall risk to the organization. Make sure to aggregate reports into smart action items. For example, if a single dependency already has a fix, and accounts for many severe CVEs, prioritize this dependency over others. Chasing after all existing vulnerabilities is a futile process– the goal is to zoom in on the ones with the potential to have a real impact on the business, or that fall within the governance scope that the organization set out for itself.
The next phase involves getting the entire organization on board. It is not enough for the CISO and security team to understand the risk of open source software. The potential for real damage should be brought to the C-suite, and security should be communicated to all relevant teams and decision makers as a fundamental building block of the organization.
Lastly, make sure to celebrate accomplishments, and communicate them. Create a reward system and shout the compliments out. If the organization sees how easy it is to fix vulnerabilities, it will be easy for them to get on board. That said, be sure not to amplify the risk - your organization should be well-equipped with risk resilience from a host of other tools.
As you operate based on this workflow, your organization will develop an appetite for eradicating bugs in OSS, and will gain fundamental understanding of the true risks in open source and its supply chain - way before the attackers do.