What Security Researchers Actually Do All Day

It's 11 p.m. on a Tuesday, and someone is staring at a hex dump, trying to figure out why a PDF viewer crashed on a file that was only 47 bytes long. That's the job. Not the hoodie-and-green-text fantasy — the patient, slightly obsessive business of making software break in ways nobody intended, then explaining exactly how it broke.

If you've ever wondered what a security researcher actually does between the dramatic headlines, this is the unglamorous, honest version.

The five kinds of security researcher (and what each one does)

"Security researcher" isn't one job. It's an umbrella that covers at least five different day-to-days, and people mix them up constantly. Here's the map I wish someone had handed me early on:

Type	What they mostly do	Typical employer
Vulnerability researcher	Find and exploit flaws in software, often at the memory level	Big tech, OS vendors, consultancies
Penetration tester	Break into client systems on purpose, then write it up	Boutique firms, consultancies
Malware analyst	Take apart malicious code in a sandbox and trace what it does	AV vendors, incident response firms, government
Detection engineer	Write the rules and alerts that catch attacks in progress	SOC teams, security product companies
AppSec engineer	Sit with developers and stop bugs before they ship	Almost everywhere with a product

A pen tester works to a scope document and a deadline. A vulnerability researcher might spend four months on a single parser bug. Same field, wildly different Tuesdays.

A day in the life of a security researcher

Strip out the conference talks and it looks a lot like other knowledge work — with a strange twist.

Mornings are for reading. Changelogs, patch diffs, mailing lists, someone's new write-up on a browser exploit chain. Researchers read constantly, because the attack surface shifts every release cycle. If you don't know that a library got bumped, you don't know what to look at next.

Then comes the actual work, which is usually one of four things:

• Reconnaissance. Mapping an application's endpoints, auth flows, and hidden parameters. Burp Suite's Community edition is free and fine to start; Professional runs a few hundred dollars a year and automates a lot of this.
• Fuzzing. Feeding thousands of malformed inputs at a parser to see what crashes. Tools like AFL++ and libFuzzer do the hammering; you do the triage. Most crashes are junk. A few aren't.
• Reverse engineering. Opening a binary in Ghidra (free, from the NSA, released in 2019) or IDA Pro (not free — think thousands, which is why most beginners start with Ghidra) and reconstructing what the code does without source.
• Writing. Reports, repro steps, CVE requests, Slack messages. I'm not joking when I say a good chunk of the week is prose. A bug nobody can reproduce is a bug that doesn't get fixed.

Afternoons blur into evenings more often than anyone admits. The classic researcher failure mode isn't burnout from hacking — it's losing six hours to one crash and forgetting to eat.

What does "finding a vulnerability" actually mean?

Most beginners imagine a lightning-strike moment. In reality it's a grind with a specific shape: you get a crash, you minimize the input to the smallest file that still crashes, you attach a debugger, and you ask why. Off-by-one in a length check? Use-after-free? An integer that wrapped around when nobody expected it to?

Then you ask the harder question: can I turn this crash into something an attacker would actually want? A crash in a browser tab is annoying. A crash you can steer into arbitrary code execution is a CVE with your name on it.

When it's confirmed, disclosure kicks in. Many vendors run bug bounty programs through platforms like HackerOne or Bugcrowd. Others have their own portals. Your report gets triaged (a human decides whether it's real and how bad), and eventually you coordinate on a fix and a public date. Google's Project Zero famously uses a 90-day disclosure deadline before going public, which has caused no small amount of friction with vendors over the years. That tension is deliberate. It's the whole point.

(My take: coordinated disclosure works, but the 90-day clock is a blunt instrument. Some vendors genuinely need six months. Some just need a calendar reminder and a fire lit under them.)

How to become a security researcher (without a CS PhD)

You don't need a doctorate. You do need to be comfortable being confused for long stretches and reading documentation that assumes you already know three other things.

Start here:

1. Learn one system deeply. Networking basics, then a web stack, then memory management in C. Depth beats breadth at the start.
2. Use free labs. PortSwigger's Web Security Academy is free and genuinely excellent. TryHackMe has beginner paths. Hack The Box is harder and worth it once you're past the basics.
3. Read real write-ups. Vendor advisories, Project Zero blog posts, CTF solution blogs. Copy the technique in a lab, not on the internet.
4. Write your own notes publicly. A blog post explaining a bug you understood beats a certificate in an interview, honestly.
5. Consider one certification. OSCP from Offensive Security is the one most hiring managers respect for hands-on work — and it costs well north of $1,000, so budget accordingly.

Do the labs legally. Practicing on a system you don't own without written permission is a crime in most places, not a personality quirk.

Security researcher salary: what the money actually looks like

US pay for security research roles commonly lands somewhere around $100k–$180k depending on specialty, employer, and location, with senior vulnerability researchers and red teamers at large tech companies pushing past that. Government and defense work often pays less but comes with stability and clearance premiums.

Bug bounty income is the wild card. The top earners on HackerOne and Bugcrowd make serious money — but that's a small group. Most people who make a living from bounties treat it like a sales job: variable months, long dry spells, and a lot of competition on popular targets. Doing bounties alongside a day job is the healthier path, especially early on.

Key Takeaways

• "Security researcher" covers at least five distinct jobs; figure out which one you actually want before you buy anything.
• The daily reality is reading, fuzzing, reverse engineering, and writing — the writing matters as much as the hacking.
• Ghidra, Wireshark, Nmap, Burp Suite Community, and PortSwigger's free labs will get you a long way for zero dollars.
• Most real work is incremental. One crash might take a week to understand.
• Get written permission before you test anything you don't own. Always.
• A public blog explaining what you've learned is worth more than most certifications in an interview.

Frequently Asked Questions

What do security researchers do all day?

Mostly read, test, analyze, and write. A typical day mixes patch reviews, fuzzing or manual testing, triaging crashes in a debugger, and writing up findings so engineers can fix them. Very little of it looks like the movies — the dramatic moment accounts for maybe 2% of the week.

How much do security researchers make?

In the US, most mid-level roles fall roughly in the $100k–$180k range, with senior vulnerability researchers at major tech companies earning more. Bug bounty income is far more variable and shouldn't be your only plan when you're starting out.

Do you need a degree to become a security researcher?

No, and the industry is increasingly vocal about that. Hands-on skill, public write-ups, lab experience, and certifications like OSCP carry serious weight. A computer science degree helps with fundamentals — memory management especially — but plenty of good researchers came in through IT support, development, or self-study.