# Master checklist Use this as an engagement preflight and a submission review. A tick means the item was checked; record the evidence and outcome in the coverage template. An unchecked item is not automatically a vulnerability. **Not applicable, blocked, untested, passed, and finding are different outcomes.** Scope-specific checklists follow the common gates. ## Before testing - [ ] Official policy URL and review time recorded; current intake status confirmed. - [ ] Researcher eligibility, invitation, confidentiality and collaboration conditions satisfied. - [ ] Exact asset, version, environment and test identity approved. - [ ] Repository scope distinguished from vendor infrastructure and customer deployments. - [ ] Third-party services, redirects, callbacks and provider restrictions reviewed. - [ ] Allowed techniques, time window, rate and concurrency recorded. - [ ] Payment eligibility and disclosure terms recorded separately from test permission. - [ ] Owned or program-issued accounts, tenants, fixtures and recovery method ready. - [ ] Tools, rules, queries, databases, artifact hashes and versions recorded. - [ ] Scope evaluator prevents newly discovered assets from entering active jobs automatically. - [ ] Logs and callbacks will not expose private data to an unapproved external service. - [ ] Stop conditions and security contact available. ## During research - [ ] Normal product behavior and intended security contract understood. - [ ] Actors, resources, entry points, privileged actions and trust boundaries mapped. - [ ] Each prioritized hypothesis states preconditions, expected violation and evidence. - [ ] Baseline and negative control captured before interpreting the result. - [ ] Synthetic resource ownership verified independently of guessed IDs. - [ ] Asynchronous jobs, alternative protocols and state transitions considered where relevant. - [ ] Security behavior changed by instrumentation or debug mode documented. - [ ] A successful status code checked against actual data or state. - [ ] Failed tools and timeouts recorded as failures rather than clean scans. - [ ] Sensitive data encounter or service degradation triggers the agreed stop behavior. - [ ] Every session ends with a result and a specific next action. ## Before submission - [ ] A real security boundary is crossed under eligible attacker assumptions. - [ ] Exact affected asset, product release/commit and supported configuration provided. - [ ] Clean reproduction succeeds using written steps and preserved fixtures. - [ ] Demonstrated impact is separated from possible downstream consequences. - [ ] Prior advisories, known issues, recent fixes and program exclusions checked. - [ ] PoC is minimal and does not depend on unnecessary data access or destructive effects. - [ ] Report includes expected/actual behavior, numbered steps, evidence and controls. - [ ] Source findings show the real public entry path, guard behavior and reachable sink. - [ ] Client/device findings distinguish modified builds from production-relevant behavior. - [ ] AI findings contain actual retrieval/tool events, not only generated claims. - [ ] Web3 findings pin chain/address/block/source and satisfy program proof requirements. - [ ] Hardware findings state physical access, revision, firmware and recovery assumptions. - [ ] Severity uses the required rubric with justified assumptions and a vector if applicable. - [ ] Tokens, personal data and unnecessary private details removed from attachments. - [ ] Submission uses the designated confidential channel. ## After submission - [ ] Report ID, submitted version, triage questions and decisions recorded. - [ ] Replies answer the actual reproduction or impact uncertainty. - [ ] Retest permission and fixed version checked before new requests. - [ ] Original case and legitimate control compared against the fix. - [ ] Disclosure timing and allowable content agreed or governed by the program policy. - [ ] Synthetic data, accounts, tokens, callbacks and lab costs cleaned up as appropriate. - [ ] Evidence retained or removed according to program rules and the retention plan. - [ ] Reusable lessons sanitized before adding to a personal or public knowledge base. ## Scope-specific review lists The lists below retain the evidence and eligibility expectations of their technical chapters. Read the linked playbook before checking its items. ## OSS & self-hosted [Open the OSS & self-hosted playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/oss.html). - [ ] Repository, product edition, version, scope, and reporting channel recorded. - [ ] Working baseline, synthetic identities, reset procedure, and config delta preserved. - [ ] Priority entry points mapped to authentication, authorization, and sensitive operations. - [ ] Every promoted finding has attacker control, reachability, prerequisites, and impact evidence. - [ ] Source, runtime, build, and shipped dependency inventories distinguished. - [ ] Secrets redacted; no discovered credential used for verification. - [ ] CI events, artifact/cache consumers, publishing identity, images, and IaC reviewed. - [ ] Scanner errors, excluded files, stale databases, and unresolved models recorded. - [ ] Local PoC minimizes side effects and includes a legitimate control case. - [ ] Prior advisories checked; tested versions distinguished from inferred versions. - [ ] Report and patch retest can be reproduced from preserved inputs. ## Web & API [Open the Web & API playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web-api.html). - [ ] Policy snapshot and exact asset/technique authorization recorded; exclusions applied. - [ ] Every candidate has an ownership and scope decision; redirects and dependencies reviewed. - [ ] Synthetic accounts, two tenants, role transitions and cleanup plan established. - [ ] Endpoints include background jobs, exports, integrations and alternate protocols. - [ ] Object, function and property authorization checked independently. - [ ] Authentication and revocation tested across UI/API/socket paths. - [ ] High-value business invariants have serial controls before concurrency tests. - [ ] Browser findings verified in a real browser; server findings have controlled differential evidence. - [ ] Finding has a reproducible boundary violation, not only a scanner label or missing hardening control. - [ ] Sensitive evidence minimized; timestamps, requests, relevant responses and state changes preserved. - [ ] Test records removed, tokens revoked, callbacks stopped and report submitted privately. ## Network services [Open the Network services playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/network.html). - [ ] Exact IPv4/IPv6, transport, port, owner and environment are authorized. - [ ] Shared hosting, origin, provider and customer boundaries are documented. - [ ] Active requests are separated from historical third-party discovery. - [ ] DNS server, query type and UDP/TCP behavior are explicit. - [ ] Commands have explicit ports, timeouts and bounded concurrency. - [ ] Service identity includes build/configuration and possible vendor backports. - [ ] SNI and expected TLS hostname are recorded. - [ ] Authentication and resource authorization have separate test cases. - [ ] Synthetic data or owner-provided canaries support evidence. - [ ] DNS/mail configuration observations are tied to eligible impact. - [ ] Parser/appliance testing has isolation, recovery and minimized inputs. - [ ] First-proof stopping, cleanup and private reporting are completed. ## Mobile [Open the Mobile playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/mobile.html). **Android** - [ ] Package ID, publisher, store channel, version, hash, and signer recorded. - [ ] Base and relevant split/dynamic-feature packages included. - [ ] Device API, ABI, target SDK, and release/debug state recorded. - [ ] Exported and dynamically registered components mapped. - [ ] Component permissions and caller identity checked. - [ ] Provider permissions, URI grants, and path handling reviewed. - [ ] Intent forwarding and PendingIntent authority traced. - [ ] Deep-link host, path, parameter, and session validation checked. - [ ] WebView navigation, frames, and bridge methods mapped. - [ ] Storage, logs, notifications, clipboard, and backups examined. - [ ] Key storage, key use, and local authentication connected. - [ ] Network trust behavior separated from lab CA changes. - [ ] Account switching and logout tested with synthetic identities. - [ ] Claimed ordinary-app issue reproduced without ADB-only privilege. **iOS** - [ ] Bundle ID, build, channel, hash, signing team, and device recorded. - [ ] Simulator, device, and instrumented builds distinguished. - [ ] `Info.plist` and embedded extension metadata inspected. - [ ] Associated domains and custom URL schemes inventoried. - [ ] URL parameters and account context validated independently. - [ ] App Groups and Keychain access groups mapped. - [ ] Keychain class, synchronization, and user-presence policy reviewed. - [ ] Sensitive file protection evaluated for intended lock states. - [ ] Extension and document-import trust boundaries exercised. - [ ] WebView frames, navigation, and message handlers inspected. - [ ] ATS configuration and actual certificate validation checked. - [ ] Cache, logs, pasteboard, screenshots, and backup exposure assessed. - [ ] Local authentication tied to sensitive data or key access. - [ ] Re-signing/jailbreak limitations and release reproduction documented. ## Desktop & extensions [Open the Desktop & extensions playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/desktop.html). **Native applications: apply each item to Windows, macOS, or Linux as relevant.** - [ ] Product, platform, architecture, channel, version, hash, signer recorded. - [ ] Installer, updater, service/helper, and plugin scope separated. - [ ] Clean snapshot and standard-user baseline captured. - [ ] Default installation paths and post-install actions mapped. - [ ] Service/helper effective identity documented. - [ ] IPC caller authentication and object-level authorization reviewed. - [ ] Writable executable, configuration, temporary, and search paths checked. - [ ] Windows registry/filesystem ACLs and named-pipe access inspected. - [ ] macOS XPC, launch services, entitlements, and signing checks inspected. - [ ] Linux sockets, D-Bus/polkit, service users, capabilities, and ownership inspected. - [ ] Protocol handlers, file associations, imports, and archive boundaries exercised. - [ ] Update metadata, artifact, signer, and rollback policy traced. - [ ] Parser fuzzing limited to a local harness with resource limits. - [ ] Crashes minimized; impact distinguished from code-execution speculation. - [ ] Reproduction repeated without artificial administrator privileges. **Electron and extensions** - [ ] Shipped Electron/browser version and extension ID/version captured. - [ ] Store-installed and modified/unpacked evidence distinguished. - [ ] Every renderer/window’s security settings inspected. - [ ] Context isolation and sandbox assumptions verified. - [ ] Preload methods and main-process IPC handlers inventoried. - [ ] IPC sender frame/origin and argument checks inspected. - [ ] Navigation, child-window, and external-protocol handling reviewed. - [ ] Host/API/optional permissions and intended usage mapped. - [ ] External messaging and web-accessible resources restricted appropriately. - [ ] Page-origin data treated as untrusted through content-script messages. - [ ] Privileged service-worker actions require bounded inputs. - [ ] Native-messaging host origin list, path, and parser reviewed. - [ ] Local browser profile contains only synthetic application data. - [ ] Result reproduced through a realistic entry point, without console-only access. ## Cloud & containers [Open the Cloud & containers playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cloud.html). - [ ] Exact account/project/subscription, resource owner and active principal match scope. - [ ] CSP policy and bounty policy both cover the method; third-party integrations are identified. - [ ] Test tenants A/B, synthetic objects and baseline denied requests exist. - [ ] Management plane, data plane, storage signing and background jobs are separately mapped. - [ ] IAM inheritance and restrictions are considered; exported policy is not mistaken for effective permission. - [ ] Cluster, namespace, CNI, admission, operator and node boundaries are distinguished. - [ ] Workload creation and sensitive RBAC verbs are reviewed without reading real secrets. - [ ] Image/module digest, supported deployment mode and runtime reachability are recorded. - [ ] SSRF proof uses owned callbacks; impact beyond the callback remains explicitly unproven. - [ ] The report contains one minimum boundary violation, redacted evidence and cleanup status. ## AI, agents & MCP [Open the AI, agents & MCP playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/ai.html). - [ ] Hosted application, model, artifact, connector and provider scopes are distinguished. - [ ] Attacker capability and the legitimate user's task are explicitly recorded. - [ ] A/B tenants and private random canaries exist; canaries are absent from attacker input. - [ ] Baseline requests establish expected permissions before adversarial input. - [ ] Model version, runtime, sampling settings and trial budget are fixed and logged. - [ ] Retrieval authorization, citations, caches and revocation are tested separately. - [ ] Tool argument ownership and approval binding are checked below the model. - [ ] MCP protocol era, transport, OAuth audience and upstream credentials are mapped. - [ ] Model hashes, custom code and deserialization paths are reviewed in isolation. - [ ] Success means an observable security consequence; hallucinated actions are excluded. - [ ] Attempts/successes, evidence redaction and cleanup are documented. ## Web3 & protocols [Open the Web3 & protocols playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web3.html). | Area | Investigation | Evidence that advances a report | |---|---|---| | Deployment identity | Correct chain, implementation and configuration at the pinned block | Address/commit manifest and the executed call path | | Authorization | Initializers, role delegation, upgrade authority, emergency controls, arbitrary call permissions | An unprivileged actor crosses the documented permission boundary | | Accounting | Deposits, redemptions, fees, debt indexes, rewards, donations, empty pools | Before/after balance sheet with explicit units and a violated relationship | | Token behavior | Supported fee-on-transfer, rebasing, hooks, nonstandard returns and decimal variation | A supported integration produces incorrect accounting or authority | | Oracle integration | Price denomination, freshness, decimals, failure modes and L2 downtime | Reachable accepted input causes an incorrect economic decision | | Callbacks | Callback authentication, intermediate state, cross-function and cross-contract reentry | A local trace showing the unexpected state transition and impact | | Signatures | Domain, signer, nonce, deadline, action binding, chain and verifying contract | A signature authorizes an unintended second action or context | | Governance | Snapshot voting, quorum, proposal state, timelock, cancellation and execution | A locally demonstrated bypass of the actual governance guarantees | | Bridges | Source authentication, destination binding, message uniqueness, ordering and finality | A local two-sided model with a duplicated or unauthorized state transition | | Liveness | Unbounded processing, poisoned queues, dependency failure and recovery | A bounded local test proving eligible user funds or operations become stuck | | Economic ordering | Slippage, deadlines, quote validity and attacker-controlled order | Loss exceeding intended, documented market behavior under feasible assumptions | | Regression | Current implementation and known exclusions | Fresh reproduction and comparison with documented known issues | Oracle checks must be feed-specific. Chainlink exposes answer metadata and timestamps; applications must interpret values and freshness correctly. On supported L2 integrations, evaluate sequencer availability and any required recovery grace period. A missing generic check is only a lead until its concrete consequence is established. [Data Feeds API](https://docs.chain.link/data-feeds/api-reference), [L2 sequencer feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) Vault rounding and donations deserve explicit boundary tests around zero supply, small deposits and conversions. OpenZeppelin’s ERC-4626 discussion illustrates why share arithmetic and inflation defenses require economic reasoning. Signature review likewise needs more than finding EIP-712: the standard itself does not supply replay protection. Inspect application nonces, consumption and action binding. [ERC-4626 security considerations](https://docs.openzeppelin.com/contracts/5.x/erc4626), [EIP-712](https://eips.ethereum.org/EIPS/eip-712) Governance review must follow the configured module composition: voting and execution may be separated, and a timelock changes which contract executes the action. Bridges introduce additional assumptions about relayers, validators and cross-chain finality. Reproduce these assumptions explicitly rather than replacing their security checks with unconditional mocks. [OpenZeppelin governance](https://docs.openzeppelin.com/contracts/5.x/api/governance), [Ethereum bridges](https://ethereum.org/developers/docs/bridges/) MEV describes value extracted through transaction inclusion or ordering, including arbitrage and sandwich behavior. Its existence is not automatically a bounty vulnerability. The report must identify an eligible broken guarantee, realistic capital and ordering assumptions, and the resulting harm; reproduce ordering locally. [Ethereum MEV](https://ethereum.org/developers/docs/mev/) For non-EVM branches, retain the same scope and evidence model but replace the execution harness. Solana research needs account ownership, signer and writable privileges, PDA derivation and CPI boundaries; Sui/Move research needs module authority and object ownership; protocol/client research needs versioned consensus rules, serialization, state transitions and private multi-node reproductions. Treat these as separate specialization tracks, not as Solidity detector configurations. Select the chain’s official SDK and program-specific build requirements before testing. [Solana privileges](https://solana.com/docs/core/cpi/cpi-execution), [Sui Move concepts](https://docs.sui.io/develop/write-move/sui-move-concepts), [Ethereum client architecture](https://ethereum.org/developers/docs/nodes-and-clients/) ## Hardware & firmware [Open the Hardware & firmware playbook](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/hardware.html). | Area | Investigation | Evidence that advances a report | |---|---|---| | Firmware identity | Model, revision, update package, installed build, hashes | Exact affected product and reproducible baseline | | Provisioning | Initial ownership, pairing, reset, reassignment and local presence | An unauthorized identity obtains a protected role or capability | | Update trust | Signature verification, trusted keys, authenticated metadata, target compatibility | A harmless unauthorized artifact crosses the actual acceptance boundary | | Rollback | Version counters, signed old images and recovery paths | An allowed attacker can restore a vulnerable security state | | Boot chain | ROM-to-bootloader-to-application verification and recovery trust | A gap in the claimed chain under the eligible access model | | Secrets | Per-device versus shared keys, credentials, debug logs and persistent storage | Protected capability established without publishing usable secrets | | Debug interfaces | UART console, JTAG/SWD, test modes and privilege separation | Unexpected access on the production configuration | | Local services | Authentication, authorization, command construction and configuration import | Reachable low-privilege input causes a protected operation | | Memory safety | Length fields, parsers, allocation/free patterns and signedness | Minimized input, crash location, reachability and bounded consequence | | Wireless | Pairing/bonding, identity, replay, sequencing and encrypted transport | Own-device controlled capture shows an authentication or integrity failure | | Cloud/app coupling | Device claims, token scoping, ownership transfer and command routing | Reproduction only against separately authorized API/app assets | | Recovery | Reboot, factory reset, watchdog and supported restore procedures | Device restored and test limitations documented | Update transport encryption, update authentication and secure boot are separate checks. HTTPS can protect download transport while leaving a local update path insufficiently authenticated. A signed image may still be unsuitable for the model or permit a security downgrade. Examine what bytes and metadata are verified and what executes afterward. [ISTG firmware update mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md) Vendor details matter. On ESP32, Secure Boot v2 support depends on chip revision, and Espressif documents interactions with JTAG and flash encryption. Its security guidance separately describes anti-rollback controls. Do not infer the presence or absence of a production control from a generic SoC feature list; inspect the target configuration and matching vendor documentation. [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html), [Security overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html) Classify discovered secrets before testing them: public certificate, local password hash, per-device private key, shared fleet credential or build-time sample. Demonstrating a secret’s role on an owned lab device is stronger than indiscriminate credential trials against cloud endpoints. For storage, distinguish attacker-accessible contents from intended administrator/debug access; note encryption-key placement, deletion behavior and residual data after reset. [ISTG installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md), [ISTG memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md) Internal interfaces deserve their own boundary assessment. A UART that prints boot diagnostics differs from an unauthenticated privileged console; accessible JTAG differs from a demonstrated ability to extract protected secrets. Record physical effort and whether opening the case is required. Radio observations likewise differ from active tests: perform replay or malformed-message experiments only between owned devices in a controlled setup, and evaluate pairing and message authentication in the relevant protocol. [ISTG internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md), [ISTG wireless interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md) ## Module-level completion checks Every [reusable module](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules.html) contains its own checkable completion criteria alongside the procedure and commands. Use these after the master preflight. Mark blocked and inapplicable cases with reasons in the coverage record.