Cyber threats have always been a part of the landscape of tech; from the first worm all the way to current supply chain and CI/CD vulnerabilities. What's different now is there seems to be an overwhelming amount of tools and solutions promising to be the silver bullet against security vulnerabilities. One of the most sought after tools, both from tool creators and users, is the "best" vulnerability scanner. There's a common misconception that the key to fortifying ourselves lies in the acquisition of the latest and greatest vulnerability scanner - the one that produces the most results or the prettiest PDFs. But is the real challenge about finding vulnerabilities, or is there more at play here?

The problem is not a scanning problem. There are three much more profound problems that arise for the modern security team that go well beyond just “finding the most vulnerabilities”

How false positives & overstated severity lead to too much noise

The first issue with many modern scanners is the overwhelming noise they produce. Modern scanners, with their advanced algorithms and vast databases, pride themselves on detecting a myriad of vulnerabilities. Imagine being in a room full of alarms, where only a few signal a real danger, while the rest are just distractions. For a security engineer, this is a daily reality. Sifting through these false positives is not just time-consuming, but also counterproductive. The constant barrage of insignificant alerts can lead to alert fatigue, where critical warnings might be dismissed as just another false alarm.

While these scanners might boast about detecting thousands of vulnerabilities, a closer inspection often reveals a plethora of false positives. And beyond true false positives, there are discoveries that - while “true” - don’t represent an actual exploitable vulnerability.  These are issues that might seem concerning on paper, but are of little to no interest to a genuine attacker. Scanners can often find things an auditor might raise an eyebrow at, but an attacker would simply ignore…so if our goal is to protect against the attacker and appease the auditor, there are two different paths here - and one comes with a lot more noise. 

How do we understand what's critical?

Having filtered out the noise, the next monumental task is prioritization. While it's great to have a list of genuine vulnerabilities, without the proper context, it's like having a puzzle with no reference picture.

Most scanners rank vulnerabilities using generic metrics, often based on industry standards or known exploits. However, they lack the nuanced understanding of an organization's unique environment. A vulnerability that's critical for one company might be trivial for another due to differences in infrastructure, data sensitivity, or user base.

For instance, a vulnerability in a test environment might be ranked as high by a scanner, but if that environment doesn't hold sensitive data and is isolated from the production network, is it really a high-priority threat? On the other hand, a medium-severity vulnerability in a system that has access to customer data might pose a more significant risk due to potential data breaches.

Understanding the attack surface is just the beginning. Delving deeper into the prioritization conundrum, the likelihood of an exploit taking place plays a pivotal role. For instance, the popularity of a product can significantly influence its risk profile. Widely used products are often more attractive targets for attackers, as exploiting them can yield greater rewards or cause more widespread disruption. Similarly, the sheer number of assets exposed on the internet can elevate the risk. The more instances of a vulnerable system that are accessible online, the higher the chances of one or more being exploited. The ease of reverse engineering a product or system can also factor into its risk rating. If malicious actors can effortlessly dissect and understand a product, they can more readily craft targeted exploits.

And what’s worse is that the standards we do have in place today - such as the CVSS score for vulnerabilities - can often end up overstated, so relying solely on them without any other context could once again have teams chasing things that don’t really protect their systems. As I’ve said before, if everything is a 9.8 than nothing is.

Thus, prioritization isn't just about the severity of a vulnerability; it's a multifaceted equation that weighs the potential real-world impact against various influencing factors. To react and understand this, we have to think like an attacker and how they would try and exploit a given vulnerability - and include that in our prioritization calculations.

Once we know what’s important to fix, how do we make that actionable?

Identifying and prioritizing vulnerabilities are just the initial steps. The real challenge, and perhaps the most crucial, is effective communication. The findings need to be conveyed to the teams that actually have the power and authority to remediate them – the engineering and operations teams.

We all know there’s often a chasm between security professionals and developers or operations personnel. While the former is entrenched in the world of threats, risks, and vulnerabilities, the latter is focused on functionality, performance, and uptime. This difference in perspectives can lead to misunderstandings, with security teams seen as roadblocks rather than enablers.

Effective communication isn't just about relaying findings. It's about translating the technical jargon of vulnerabilities into actionable insights. It's about understanding the pressures and timelines of development teams and finding a middle ground where security compliments functionality rather than hindering it. 

One of the most critical aspects that is often overlooked by busy teams is the detailed communication of how an exploit manifests itself. It's not enough to simply state that a vulnerability exists; teams need a clear picture of its behavior, its potential impact, and the conditions under which it truly thrives to understand its impact.

Furthermore, for engineering and operations teams to address the vulnerability effectively, they need a step-by-step guide on how to reproduce it. This reproduction process is vital, as it ensures that the teams can see the vulnerability in action, understand its nuances, and tailor their solutions accordingly.

Lastly, once a fix is applied, there must be a clear and reliable method to verify its effectiveness. It's not uncommon for initial patches to miss the mark, or for vulnerabilities to persist in a slightly altered form. By providing a means to test and confirm that the vulnerability has indeed been addressed, security teams can ensure the fix is not just a temporary bandage but a long-term solution. 

This cycle of detailed communication – from identification to verification – is paramount in fostering trust and collaboration between security and development teams. And what is really needed is a universal, open language to discuss and communicate clearly the signature of vulnerabilities.

This brings us to an essential point: scanning for vulnerabilities should be a communal effort. Security can't be hidden behind a paywall or some brand-new scanner, it needs to be something anyone can implement and in doing so, increase the security of everyone participating on the internet.  That kind of “arms race” will not serve to advance the cause of making all of our organizations safer, and we’ve seen the challenges that this kind of mentality creates.

Given these challenges, the focus should shift from the mere detection of vulnerabilities to a more holistic approach. This is where the concept of democratizing security comes into play. Tools like Nuclei from ProjectDiscovery are open-source, aiming to make security a shared responsibility. Security scanning should be democratized - available for all. By making these tools more accessible, the community can collaborate, enhancing the tools and sharing knowledge.

When security becomes a communal effort, organizations can move away from the repetitive and often frustrating task of scanning. Instead, they can channel their resources into training, fostering better communication, and developing frameworks for effective vulnerability management.

We don't have a "finding vulnerabilities" problem. We have a communication and prioritization problem. Before investing in another scanner, organizations should first invest in training, processes, and tools that enhance communication between security and development teams and provide a clear framework for prioritizing vulnerabilities based on real-world impact.

By addressing these core challenges, we can make our systems more secure and foster a culture where security is an integral part of every phase of development and operations.