From offensive security to blue team

Before I worked in a SOC, I spent about three years on the other side, hunting web application vulnerabilities on public and private bug bounty programs. My job was to find the one thing a team had missed, prove it, and write it up well enough that someone would fix it. Then I moved to defence, where the job is closer to the reverse: notice the one thing an attacker did that does not fit.

People often ask whether that background helps. It does, enormously, though not always in the ways they expect. Here is what transferred, what I had to unlearn, and what I would tell anyone thinking about making the same move.

Lesson 1: attackers think in paths, not alerts

As a bug hunter I never thought about a single vulnerability in isolation. A low-severity information leak was interesting because of what it unlocked: an internal hostname, a user ID format, an API endpoint that should not be public. Chain three small things and you had something serious.

Attackers in a real network work the same way. Initial access, discovery, credential theft, lateral movement, collection, exfiltration. Each step on its own might produce a low-severity alert that looks harmless. The defender who only reads alerts one at a time misses the story. The defender who asks "if this were the first step, what would the next one be?" finds it.

Lesson 2: read alerts like an intruder would

When I look at an alert now, my first question is not "is this rule right?" It is "if I were the attacker, why would I have done this?" A PowerShell command makes sense or does not depending on what an intruder would gain from it. A login from a new location matters more if that account has access worth stealing.

That habit makes triage faster in both directions. Some alerts that look alarming make no sense as attacker behaviour, and you can close them with confidence. Others that look routine suddenly make a lot of sense, and you look harder.

Lesson 3: every control has an edge

Bug bounty teaches you that every control has a boundary, and the interesting bugs live right on it. Input validation that covers one parameter but not the next. Authorisation checked on the page but not on the API behind it. Rate limiting on login but not on password reset.

Defensive controls have edges too. MFA protects the login but not a stolen session, which is why I wrote MFA is not your last line of defense. EDR covers managed laptops but not the contractor's personal device. A detection catches the common tool but not the renamed copy. Offensive experience trains you to look for the edge of every control you rely on, and to ask what happens just beyond it.

Lesson 4: proof beats opinion

A bug bounty report without a working proof of concept is usually closed. You learn quickly to show, not tell: exact steps, exact requests, exact impact. That discipline translates directly into incident reports and detection proposals. "This looks suspicious" gets ignored. "Here is the timeline, here are the three log entries that prove it, and here is what the attacker could reach next" gets action.

What I had to unlearn

Not everything transfers. A few offensive habits work against you on the blue side.

• Depth over breadth. Bug hunting rewards going very deep on one target for days. A SOC shift needs you to handle many alerts well, not one perfectly. Knowing when an alert has had enough attention is a skill I had to build.
• Working alone. Bug bounty is mostly solo. Defence is a team sport with handovers, shared queues and on-call rotations. Writing for the next analyst matters as much as finding the issue.
• Focusing on the clever. Offensive work celebrates the novel bypass. Most real intrusions use boring techniques: phishing, stolen credentials, unpatched services. Defenders win by doing the boring things consistently.
• Thinking about the finding, not the business. In bounty work, impact is a severity score. In a company, impact is a conversation about risk, cost and timing with people who are not security specialists.

Why rotations help

One thing that helped me bridge the two worlds was an internship that rotated through every team reporting to the security leadership: the SOC, threat and vulnerability management, application security, security architecture and product security incident response. Seeing how each team worked, and how a vulnerability moves from discovery to fix to detection, made it much clearer where an attacker's mindset adds the most value on defence.

If your organisation offers rotations, take them. If it does not, ask to shadow the teams next to yours for a week. You will understand your own job better.

How defenders can borrow the offensive mindset

You do not need a bug bounty background to think like an attacker. A few practical ways to build it:

• Walk through ATT&CK for your own environment. Pick a technique from MITRE ATT&CK, then ask how an attacker would do it here, and what you would see if they did.
• Practise on deliberately vulnerable labs. Breaking things in a safe environment teaches you what the logs look like when it happens for real.
• Run purple-team exercises. Have someone run a technique while defenders watch the telemetry live. Gaps show up within minutes.
• Read offensive write-ups. Bug bounty reports and red team blogs are free lessons in how controls fail.
• Ask "what next?" on every alert. If this were real, what would the attacker do in the next ten minutes, and would we see it?

Advice for anyone moving from red to blue

• Learn the logs. You know how attacks work; now learn what they look like in a SIEM and an EDR timeline.
• Learn the business. Find out what the organisation actually cares about protecting. That is where attackers will go.
• Turn your findings into detections. Every technique you know how to perform is a detection you can write.
• Keep your offensive skills sharp. They are your advantage, and they fade if you never use them.

Frequently asked questions

Do you need offensive experience to be a good defender? No. Plenty of excellent defenders have never done a pentest. But spending some time breaking things, even in labs, makes you much faster at recognising what an attack looks like in real logs.

Is moving from red to blue a step down? Not at all. Defence is harder in some ways: an attacker needs one path in, while a defender has to watch all of them, every day. The skills are complementary, and many people move back and forth during a career.

What is purple teaming? It is offensive and defensive people working together in the open. One side runs a technique, the other watches what their tools see, and both improve the detection on the spot.

The point

Offence and defence are not opposite careers. They are two views of the same problem. Offensive work teaches you how systems fail; defensive work teaches you how to notice failure at scale and respond to it calmly. The best defenders I know can switch between those views quickly, reading an alert as an attacker would, then acting on it as a defender must.