Crowdfense – The challenge

Crowdfense – The challenge

Reading Time: 5 minutes

After a few months, since I joined the company, it’s perhaps time for me to write something and inaugurate our blog.

First, I want to express my gratitude to the readers who have ventured into our blog for the first time. I understand your anticipation for technical content, and I assure you that this non-technical blog will only be a one-off. As you would expect, the upcoming blog posts will be full of technical content and deep dives into our vulnerability research and exploitation world.

The challenges

Since the beginning of my vulnerability research career, many things have changed, and many more will.

Also, if you’d like to have a more comprehensive and detailed timeline of how and when things started to change, I suggest reading Maor Shwartz’s article – The Boom, the Bust and the Adjust; it perfectly sums up my own experience and things that I’ve seen happening to this industry.


If back in 2015/2016, single researchers were able to research, develop, and maintain a full chain all alone, it is now getting harder and harder. I personally know only a few researchers that, potentially, can still have the skills to do that, and even when the lack of skills is not the problem, it is incredibly time-consuming to chain the different pieces together to get a “full chain.”

Vulnerability research is not linear by nature. When a problem occurs in any other field, key people can be hired to solve it. With research, that’s simply not true. I always compare research to a black hole: You can throw millions at it and still find nothing.


Over the years, vendors like Apple, Google, and Microsoft have spent significant resources to make their products more secure. They have introduced new mitigations, patched vulnerabilities, created bug bounty programs, and in general, they have adopted the “defence in depth” approach that is now serving them well.

It is common for them to (try) to address entire bug classes rather than all the simple instances of the bugs. Logical bugs can and will still happen, but the rate at which memory corruption bugs are patched is unparalleled. Apple, specifically, maintaining control over all the technological stack of its devices, granting support to only a few selected vendors and hardware compatibility to a few selected components, has the incredible advantage of being able to fix vulnerabilities in many different ways and at different layers. They have the massive benefit of deciding where fixing a vulnerability is more efficient; they can enforce stacked mitigations either at the software or hardware level.


In the past ten years, the 0-day market has drastically transformed. Nowadays, independent companies operating as brokers or agents in the offensive field (bridging researchers to clients) have almost completely disappeared. All major players of the past are dormant (Zerodium) or completely extinct (e.g. Incredity, Pwn0rama, Coseinc, etc.). The market does not accommodate new players and now relies on well-established partners; clients rarely trust single researchers and brokers.

How bright is the future?

Memory-safe languages

While I’ve seen some effort being put by vendors into migrating towards memory-safe languages, the effort required to train all the developers (the languages are new also for them) and rewrite the massive code bases we are all everyday using, it is gargantuan. I do not foresee them being able to do so for years to come, also accounting for the fact that rewriting an entire codebase exposes the entire attack surface and, possibly, re-introduces new bugs in the codebase itself. Unless AI comes to the rescue and helps developers migrate vast quantities of code to another language… Here, I would also like to point out a thing many fail to see when speaking about AI: it doesn’t need to be perfect; it just needs to be better than an average human.

Lack of new people in this field

being present at conferences, it’s evident that this field is subject to a small new influx of talent. While there are definitely some new faces around, most of the active researchers are well-known and have been present in the field for years. Either this field is not perceived as attractive to new generations (compared to web3, crypto, AI), or we need to individuate the cause for it being the case. Only a few companies have opened new entry positions or are willing to foster new researchers who, with time, will be able to replace older ones.

Researchers Market

While the market for researchers is thriving (at least in the EU), I do not consider it a positive trend. Eventually, companies that have hired a lot in the past few years will discover that they either cannot deliver and will fail, closing down, or will only need a bunch of capable researchers to deliver. They will start cutting down dead leaves (some major companies are already laying off a couple of researchers).


Clients must rethink or heavily downsize their expectations regarding SLAs and installation payments for entire systems and single exploits. The time when a vendor could grant SLAs and replacement for chains is gone. The market cannot accommodate that anymore. Researchers expect to be paid in full for the effort they’ve put into their research and exploits.

Will zero-day exploits flood the market?

Contrary to Maor, I do not foresee a flood of zero days in the market and a consequent drop in their prices. Exploits for mobile targets are becoming increasingly scarce and pricey, and I expect their cost to continue to increase significantly over time.

The elephant in the room, US and regulations

While the US is determined to crack down on spyware abuse, some of the discussed regulations can potentially have the side-effect of isolating them. First, because any country in the world will still need and want to maintain such national capabilities, not only the US, and no one will ever give up this requirement nor allow only the US to detain it. Also, If the US ends up scaring researchers or closing the “borders” to foreign research, I’m not sure their internal market is, nor will it be enough for them to maintain these capabilities all by themselves.

Why is Crowdfense still relevant?

Crowdfense has operated in the market long enough to be one of the few, if not the only one still standing, public-facing company bridging researchers with institutional clients. Dealing with governments is extremely time-consuming, and most are unwilling to trust random researchers; some are impossible to reach as they need direct relationships or introductions. Governments also do not usually offer excellent terms, timely schedules and payments.

Crowdfense, on the other hand, has a view of the market landscape and maintains a portfolio of institutional clients. We handle the negotiation, compliance, and legal framework and manage the process on behalf of researchers so they can focus on the technical things they like the most. It’s not only that; we are not just a broker maintaining clients’ and researchers’ anonymity; we understand the technical aspects of vulnerabilities and will ensure your submission will be evaluated and priced in the most relevant way.

There are no strings attached. If, after the initial submission through the VRH platform (our unique private vulnerability research hub, a safe environment where researchers can anonymously submit, discuss and sell single zero-day and chains of exploits) and evaluation, we are unable to match your specs with our clients, the researchers still retain their capability and are free to look for other opportunities or submit to other platforms or vendors.

Tips for Researchers

  • As a researcher turning to the offensive field, you will get paid more than the vendor’s bug bounty program.
  • Technical specifications of your assets are gold; the better the specs are, the better your capability can be evaluated and priced.
  • Just because your item is worth X, it doesn’t always mean that there is an active buyer willing to pay for it; market demand changes frequently. In general, high-end vulnerabilities are always in high demand (nowadays, especially for mobile capabilities).
  • Never claim an exploit to be more reliable or capable than it is.
  • Your support, SLAs, and exploit adjustments would still be worthwhile if you could provide them.

Share this post