scope-policy-qualification

Validates bug-bounty scope and reportability against live program policies and target contracts.

1|Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Maybe4a6f7365/agentic-bug-bounty-framework --skill scope-policy-qualification-maybe4a6f7365
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: scope-policy-qualification
Source: https://github.com/Maybe4a6f7365/agentic-bug-bounty-framework/tree/main/skills/scope-policy-qualification
Command: npx skills add https://github.com/Maybe4a6f7365/agentic-bug-bounty-framework --skill scope-policy-qualification-maybe4a6f7365

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security researchers risk testing unauthorized assets or submitting non-qualifying findings when they misread bug-bounty program policies. This Skill gates every engagement on two non-technical checks — in_scope (asset and technique authorized) and program_reportable (impact meets the program's threshold) — so no testing or submission happens without verified authorization. ## Core Features & Use Cases - Scope qualification at target entry: Reads the live program policy and the target contract.yaml, builds an in-scope allowlist of assets and permitted techniques, and sets required identification headers and rate budgets. - Reportability qualification before submission: Re-reads the live policy to confirm demonstrated impact meets the severity/reward threshold and was not achieved via an excluded method, then gates handoff on contract.yaml pre-flight flags. - Stop-condition enforcement: Applies labeled negative-control categories (out_of_scope_asset, prohibited_test_method, below impact threshold) so candidates that fail any gate are never advanced. - Use Case: Before running recon against a new HackerOne target, load this Skill to parse the program policy into an allowlist, configure the X-Bug-Bounty header and 1 req/s rate budget, and block any asset not explicitly authorized. ## Quick Start Check whether this asset and testing technique are in scope for the program before I start recon, and re-verify reportability before I submit the finding.

Frequently Asked Questions about scope-policy-qualification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if an asset is in scope for a bug bounty program?

Read the live program policy and the target contract.yaml program_scope section, then build an allowlist of exact assets and permitted techniques. A host surfaced by recon is not authorized until it matches this allowlist, and the live policy wins whenever it is newer or stricter than the contract.

What is the difference between in_scope and program_reportable?

in_scope asks whether the program policy and contract cover the asset and technique, while program_reportable asks whether the demonstrated impact meets the program's severity or reward threshold. A finding can be technically real and in scope but still not reportable if the impact falls below the bar.

When should bug bounty policy be re-reviewed before submission?

Re-read the live policy immediately before submission, not just at target entry, because program terms may have changed during the engagement. Set the policy_re_reviewed flag only after this final live-policy re-read, and gate handoff on the contract's pre-flight requirements.

Does public reachability mean an asset is authorized to test?

No. Public reachability, a platform listing, or an in-scope asset reaching into another system never grants authorization. Only assets and techniques explicitly covered by the live program policy and contract.yaml allowlist may be tested.

What testing methods are commonly prohibited in bug bounty programs?

Commonly prohibited methods include automated scanning, brute force, denial-of-service or stress testing, social engineering, and accessing real user data. Findings demonstrable only through banned techniques are stopped with the prohibited_test_method label and never submitted.