It's tough because infosec is a terribly inefficient market. The vast majority of end users don't care about security until they are impacted by it, at which p

It's tough because infosec is a terribly inefficient market. The vast majority of end users don't care about security until they are impacted by it, at which point they blame the vendor and scramble for a quick fix and then quickly go back to not caring. As a result, end users are rarely customers for security. (Or privacy, which really is just a form of security.) The vast majority of vendors do care something about security, but the knowledge and skill of actually understandings security is rare. Therefore most of the actual customers for security are ignorant customers who are looking for something that will make them feel secure. Ignorant customers tend to fall back on secondary indicators of status such as name and brand recognition and the opinions of those who are deemed experts in a given field. This makes security a bit of an in-club, where experts recommend each other through their expert advice. It also makes security a field where snake oil can get a lot of traction if it can correctly mimic these secondary signals or can piggyback on them. All fields with ignorant customer bases tend to be somewhat status-indicator-driven and anti-meritocratic. I'd advocate focusing your efforts more narrowly at breaking into this market on the positive (non-snake-oil) side. There are three ways I can think of to do this: (1) Try to get a job with a highly regarded security firm. (2) Look for the things that vendors use as secondary indicators such as certifications, and try to get at least one of those. Then use that to break into the market and start building a reputation. (3) Target a specific popular software product (e.g. OpenSSL, nginx, Apache, etc.) and identify a real vulnerability. Then "market" this vulnerability with a catchy name that will get you some recognition as its discoverer. Then use this as a credential. But be sure the thing you identify is real enough to impress those who do understand security or this could backfire a bit. For #3 I would highly suggest wading into the probably very shark infested waters of NodeJS and popular NPM packages. Node is the Hot New Thing and development has been progressing rapidly and chances are popular Node security and authentication packages are riddled with non-obvious holes. It's likely that you could identify a single insecure programming practice that is systematically encouraged by the nature of the JavaScript programming language and then bag dozens of vulnerabilities based on it by searching code bases for that pattern. "Eval" or any form of it has been a likely candidate in the past but that one is mostly common knowledge today, so you'll probably have to find a less obvious one. The core Node code might also be a fruitful place to look, since we (at my venture) recently had to delve into it a bit and it's a chthonic blob of C code if I ever saw one. Start with libuv, but keep some eye bleach and religious iconography handy.