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.

• 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.

• 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.

• 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.

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.

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.

• 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.

• 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.

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, 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, 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, Ethereum 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

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, Sui Move concepts, Ethereum client architecture

Hardware & firmware#

Open the Hardware & firmware playbook.

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

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, Security overview

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, ISTG memory

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, ISTG wireless interfaces

Module-level completion checks#

Every reusable module 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.