Choosing your first bug bounty program

The program you pick decides whether your first month is productive or wasted on targets you cannot test. This post is about reading a scope well, with an AI model doing the first pass and you making the call. It follows the loop and feeds the toolkit setup.

#What a program is

A bug bounty program is a public offer. An organization names assets it wants tested, states the rules for testing them, and sets rewards for valid reports. The policy is the contract. Everything you do stays inside what it lists, and a report that steps outside gets closed no matter how good the bug is. Some sites also publish a security.txt file at /.well-known/security.txt with a contact and policy link, which tells you where reports go.

#In scope and out of scope

Every policy splits the world into assets you may test and assets you may not. In scope is usually a set of domains, wildcard domains, mobile apps, or APIs. Out of scope is the rest, and it often includes third-party services the organization uses but does not own. The out-of-scope list matters more than the in-scope one for a beginner, because that is where accidents happen. A wildcard such as *.example.com can still exclude specific hosts, so read both lists together.

#The rules that close reports

Beyond the asset lists, a policy sets rules of engagement: rate limits, whether automated scanning is allowed, which bug classes are not rewarded, and what you may do with any data you reach. Common out-of-scope classes for beginners are self-XSS, missing security headers with no exploit, and reports from automated scanners with no manual proof. Bug bounty rules of engagement explains these in full.

#Read a scope with the model, then check it

Paste the policy into a chat and ask for three lists: in-scope assets, out-of-scope assets, and rules that would get a report closed. The model is good at this reading job. It is also capable of dropping a host or inventing a rule, so you read the policy yourself afterward and fix its lists. The point of the model here is speed on a boring task, not a verdict you trust blindly.

Signal	Beginner friendly	Harder start
Scope size	A few clear domains	Large wildcard estate
Maturity	Newer program, fewer hunters	Mature program, picked over
Rules	Scanning allowed, clear classes	Tight rate limits, many exclusions
Targets	A web app you can run locally too	Hardware or native-only apps

#Pick an asset you can actually test

A program can list ten assets while only two suit your skills. As a beginner, pick a web application you can also study on your own machine, so you can learn its behavior without sending traffic to the live target for every question. If the program offers a self-hosted or demo build, run that locally and save the live host for confirming a bug. This keeps your request count on the real target low, which respects the rate rules and leaves a cleaner record.

#Record the scope before you touch it

Write the scope down somewhere your tools can check it, not just your memory. The NotHoly CLI can hold the scope for a run with notholy engage, and it reads the target out of each command before the command runs, so an out-of-scope host asks for a second confirmation. The toolkit post sets this up. Recording the scope turns a rule you have to remember into a check the terminal makes for you.

#Picking the platform

Programs live on bounty platforms and on company pages found through security.txt or a /security page. Public programs accept anyone. Private ones come by invitation after you build a record. Start public, read a few policies with the model to get a feel for how they differ, and commit to one program long enough to learn its application well.

#Next in this track

Once you have a program and an asset, set up the toolkit and the terminal. Keep the OWASP Web Security Testing Guide and the disclose.io terms nearby as references for what good-faith testing looks like.