I’ve watched a lot of people burn months of research time on the wrong target — a piece of software that was either too hardened for a beginner to make progress on, too obscure for the findings to matter to anyone, or just a poor match for the skills they were trying to build. Target selection is one of those things nobody teaches directly, but it quietly determines whether your research time turns into real findings, a publishable write-up, or a paycheck (via bug bounty), versus months of frustration with nothing to show for it. I want to lay out an actual framework for choosing what to research, because “just pick something interesting” is not a strategy.
Why Target Selection Matters More Than People Think
Vulnerability research time is finite and expensive, whether you’re doing it as a hobby, for a bug bounty, or as part of a paid engagement. A poorly chosen target can fail you in several distinct ways:
- Too hardened: heavily audited, professionally developed software (major browsers, widely-used crypto libraries) with mature security teams — finding anything meaningful here often requires research-level sophistication and significant time investment.
- Too obscure: software with essentially no user base — even a real vulnerability has minimal impact, and for bug bounty purposes, may not even be in scope anywhere.
- Too unstable a codebase: rapidly changing code where your research becomes stale before you finish, or where the specific vulnerable version isn’t actually deployed anywhere real.
- Mismatched to your skill level: targets that require reverse engineering skills, kernel internals knowledge, or cryptographic expertise you haven’t built yet — productive eventually, but a poor first choice.
A Framework for Target Selection
flowchart TD
A[Define Your Goal] --> B{Bug Bounty / CTF / Research Publication / Skill Building?}
B --> C[Assess Attack Surface Characteristics]
C --> D[Assess Your Current Skill Match]
D --> E[Assess Impact Potential]
E --> F[Assess Competition Level]
F --> G[Shortlist 2-3 Candidates]
G --> H[Do a Time-Boxed Recon Pass on Each]
H --> I[Commit to One Target]
Step 1: Define Your Actual Goal First
This sounds obvious, but it changes everything downstream. Are you trying to:
- Earn bug bounty income? → Prioritize scope breadth, program payout history, and realistic time-to-first-bug for your skill level.
- Build a specific skill (e.g., kernel exploitation, browser internals)? → Prioritize targets known to have a learning curve appropriate to where you are, with good existing write-ups to learn from.
- Publish novel research / build reputation? → Prioritize under-researched software with real-world deployment, where you’re less likely to be racing other researchers to the same finding.
- Prepare for a CTF or certification? → The target is often given to you; this framework applies less directly, though the approach to a given challenge still benefits from the same systematic thinking.
Step 2: Attack Surface Characteristics Worth Evaluating
| Characteristic | Why It Matters | How to Assess |
|---|---|---|
| Code accessibility | Source-available research is dramatically faster than pure black-box/binary reversing | Check GitHub/GitLab, package registries, vendor documentation |
| Attack surface size | More entry points generally means more opportunity, but also more time to cover thoroughly | Enumerate listeners, parsers, deserialization points, admin interfaces |
| Deployment prevalence | Real-world impact and bounty payout both scale with how widely deployed the software is | Shodan/Censys searches, package download stats, market share reports |
| Prior research density | Heavily researched targets have fewer easy findings left; under-researched targets have more low-hanging fruit | Search CVE databases, conference talks, existing write-ups for the target |
| Update/patch cadence | Fast-moving targets can make your research stale quickly; very slow-moving legacy targets may have long-standing unpatched issues | Check release history, changelog frequency |
| Language/tech stack | Memory-unsafe languages (C/C++) have different bug classes than memory-safe ones (Go, Rust, managed languages) — pick based on the skill you want to exercise | Read the source or documentation |
Step 3: Honest Skill Self-Assessment
Be genuinely honest here, because mismatched difficulty is the single biggest cause of research projects that fizzle out. A rough progression, useful as a self-check:
| Skill Level | Suitable Target Characteristics |
|---|---|
| Beginner | Source-available web applications, well-documented open-source CMS plugins, small utilities with clear input/output boundaries |
| Intermediate | Larger open-source projects, custom network protocols with available source, mobile apps with moderate obfuscation |
| Advanced | Closed-source binaries requiring reverse engineering, browser engines, kernel components, cryptographic protocol implementations |
| Expert | Novel exploitation techniques against hardened targets, hypervisors, complex memory corruption chains bypassing modern mitigations |
Choosing a target one level above your current comfort zone is generally the right amount of stretch; choosing one two or three levels up tends to produce frustration rather than learning.
Step 4: Impact Potential
Not all vulnerabilities carry equal weight, and it’s worth thinking about impact before you start, not just after you find something. Ask:
- Does this software handle sensitive data (credentials, financial information, health data)?
- Is it typically deployed in a privileged context (root/admin services, cloud control planes, CI/CD systems)?
- Is it reachable remotely without authentication, or does exploitation require significant prerequisites?
- How many real deployments exist, and are they patchable in practice (actively maintained vendor) or likely to remain vulnerable for years (abandoned/legacy systems, embedded devices)?
Step 5: Competition Assessment
For bug bounty and CVE-hunting specifically, popular, well-known targets attract many researchers simultaneously — you’re racing people you can’t see. Signals of high competition: the target is a major bug bounty program with a large payout history, has been featured in recent conference talks, or has an active, well-known research community. Under-the-radar targets — internal tools that recently went open-source, newer frameworks that haven’t seen a security research wave yet, niche-but-widely-deployed enterprise software — often have a much better effort-to-finding ratio.
A Practical Scoring Approach
For a shortlist of candidate targets, a simple weighted scoring table can cut through analysis paralysis:
| Criterion (1-5 scale) | Target A | Target B | Target C |
|---|---|---|---|
| Skill match | 4 | 2 | 5 |
| Attack surface size | 3 | 5 | 2 |
| Deployment prevalence | 5 | 4 | 2 |
| Prior research density (lower = better opportunity) | 2 | 4 | 5 |
| Code accessibility | 5 | 3 | 5 |
| Total | 19 | 18 | 19 |
Even a rough, subjective version of this exercise is more useful than gut instinct alone, because it forces you to weigh factors you might otherwise ignore in the moment (like accidentally picking something exciting but wildly over your current skill level).
Time-Boxed Reconnaissance Before Committing
Before fully committing to a target, spend a strictly time-boxed period (a few hours to a day, depending on scope) doing lightweight recon:
- Read the README, architecture docs, and recent changelog. Get a sense of the codebase’s shape and recent activity.
- Skim for obvious low-hanging fruit — outdated dependencies with known CVEs, obviously risky patterns (
eval, raw SQL concatenation, disabled certificate validation) via a quick grep pass. - Check existing disclosed vulnerabilities for the target — this tells you both what attack surface has already been picked over and, often, what hasn’t been looked at yet (e.g., “everyone’s found web bugs in this, nobody’s looked at the CLI tool that ships with it”).
- Verify the target is actually in scope if this is for a bug bounty program — read the policy carefully, since out-of-scope findings are wasted effort no matter how good they are.
- Set up a working local instance or test environment and confirm you can actually run/build/debug it — a surprising number of research efforts stall out on tooling and environment setup alone.
Real-World Example: Choosing Between Two CMS Plugins
Imagine you’re bug-bounty hunting and considering two WordPress plugins: Plugin A has 2 million active installs, was last updated six months ago, and has a long history of prior CVEs (meaning it’s been heavily researched already). Plugin B has 300,000 active installs, was updated last week, and has zero prior disclosed vulnerabilities despite being several years old. On raw install count, A looks more attractive — but B’s complete absence of prior findings on a mature codebase suggests genuinely under-researched surface, while A’s research history suggests the easy findings are likely gone and what remains is probably harder to find. For a beginner-to-intermediate researcher optimizing for actually finding something, B is very often the better bet, even with a smaller install base — this is a real, common pattern in bug bounty target selection.
Frequently Asked Questions
Should I prioritize install/deployment count or research novelty when picking a target? It depends on your goal — for maximum bounty payout on a single critical finding, prevalence and criticality of the affected system matter most; for actually finding something in reasonable time, low prior-research density often matters more than raw popularity.
Is it a mistake to keep switching targets frequently? Switching too early, before finishing a reasonable recon pass, wastes the time already invested; switching too late, after recon clearly shows a poor skill match or saturated research history, wastes even more. The time-boxed recon step exists specifically to make this decision early and cheaply.
How much should CVE/vulnerability history influence target selection? Heavily — a long list of prior memory-corruption CVEs in a C/C++ project tells you the codebase has real bug density and is worth continued attention; a total absence of history in a similarly-aged, similarly-complex codebase is a strong signal that it simply hasn’t been looked at yet, which can be equally attractive for different reasons.
Do I need source code access to do effective vulnerability research? No, but it changes your methodology significantly — source-available targets favor the source-to-sink/sink-to-source analysis techniques covered elsewhere, while closed-source targets require reverse engineering, binary diffing (for patch analysis), and dynamic analysis/fuzzing as the primary discovery techniques instead.
References
- OWASP Testing Guide: Scoping and Reconnaissance
- MITRE CVE database
- NIST National Vulnerability Database
- Bugcrowd: Vulnerability Rating Taxonomy
- HackerOne: Hacker101 resources
Summary and Recommendations
Good vulnerability research starts well before you open a disassembler or a code editor — it starts with a deliberate, honest evaluation of what you’re trying to achieve, what skill level you’re actually at, and which targets offer a realistic path to a meaningful finding given both. Skip the targets that are either far beyond your current skill level or so heavily researched that the easy findings are long gone, and give real weight to under-researched, actively-deployed software where your time is likely to be genuinely productive. A short, disciplined recon pass before fully committing will save you from the single most common failure mode in vulnerability research: months spent on a target that was simply the wrong choice from the start.
