Bout time we had a real intro rather than trolling each other. ;) My job in INFOSEC was high assurance security engineering and systems design. Premium stuff with provable properties to stop attacks by nation states or other High Strength Attackers. I learned from a tiny, elite community in academia and defense that published a lot on what worked vs what didn't. Not a great market in U.S. these days unless suppliers are willing to be very unethical. All I'll say on that. I left & am not doing INFOSEC commercially right now.

So, past 7+ years I've been designing solutions to every problem I could spot, mostly giving them away for free on various forums to get our baseline up, and evangelizing strong security methods over the more mainstream ones that I call 0-day generators. Reference copies of most of my stuff posted on Schneier's blog since it reaches many people without any strings attached (i.e. ACM/IEEE's bullshit). Recently, I started doing stuff here too. Hindsight, probably should've done less work to focus on publishing in more mainstream outlets but I stayed too busy to be that wise. ;)

My commercial framework [1] said the nation states would hit every layer of the system and any device in the network. All must be protected, monitored, obfuscated, whatever. It's was long known that routers, etc were being used as a beachhead. Anyone on the defense side against strong attackers would see unusual traffic. My perspective was always that, if it's useful & can run code, it will be hacked by pros eventually. That simple, no further imagination required. Mainstream ITSEC people I contacted always said I was too paranoid, no evidence of such attacks, stronger methods were overkill, etc. Post-Snowden, they're getting a bit of a wakeup call but still using same methods & tech that got them there. (sighs)

That's background. Back to your comment. You said you were surprised there was a 0-day and huge price tag on Netgear routers. Think like an attacker. Such routers are used by many potential targets as the first line of defense, with visibility into the network, can run code, and have shit security. It was an obvious attack that can facilitate others. The attack requires an exploit, though. So, someone made one and tried to price it quite profitably. Router security sucks so bad that 0-days aren't worth that much based on effort to find but might sell well if limited supply.

So, it follows from the existence of an opportunity and cases of attackers seizing it previously that there will be a market of supplying and buying 0-days for that type of target. We must also remember the specialization of malware market where people using hacking tools don't necessarily want to dig out 0-days themselves: they buy them & integrate them with custom or purchased toolkits. Especially for cyber-espionage and offensive warfare by governments. The rest, like prices and demand, I'd only be guessing at so no comment on that.

Answering other question, I don't do vulnerability research. It's mostly mental masturbation that doesn't solve our problems. The few exceptions are those uncovering new classes of attack which I'm very grateful for. My segment of INFOSEC focuses on understanding the root problem of given issues, identifying ways to prevent/catch it, promoting them so they get more review, and I constantly try to enhance & integrate them in my own work since that community is more scattered than mainstream. That's what I call medium assurance with strongest designs, implementations, and security arguments being high assurance (or on that path).

The only part of medium-to-high assurance that's mainstream right now is langsec.org, IIRC. They have methods and tools that eliminate a whole class of problems along with strong arguments that they work. That's how high assurance does it. Another micro-level example are stack overflows. Mainstream did canaries, checks, all kinds of BS. MULTICS (1970's) just made data flow away from stack pointer (reverse stack) and overflows drop into newly allocated memory. Root problem solved. Boom. Done. Most UNIX people, upon hearing of setuid risks, set on some auditing process to try to avoid abuses while using such apps. TIS's Trusted Xenix kernel cleared setuid bit upon a write to any such file w/ admin seeing that & having to manually reset it if it was OK. Setuid issue gone w/ legacy compatibility still there. I hope such simple examples illustrate the difference between my subset and mainstream INFOSEC's approaches to solving security problems.

[1] http://pastebin.com/y3PufJ0V