Operating playbook
The workflow below applies to a repository, a private SaaS account, a mobile artifact, a local chain fork, or a device. Branch-specific techniques come after the common admission and evidence gates. The gates and time-boxes are recommended research practices; the target's policy supplies the actual authorization requirements.
Stage gates#
| Stage | Inputs | Actions | Output | Exit gate |
|---|---|---|---|---|
| 0. Admit | Official program policy and asset | Check eligibility, scope, techniques, disclosures and rewards | Scope record | No unresolved permission question for the intended action |
| 1. Prepare | Approved asset, identity, artifact | Pin versions; isolate lab; prepare synthetic data; record tool configuration | Reproducible environment | Clean reset and normal baseline work |
| 2. Model | Product docs, source, traffic, architecture | Identify actors, resources, state machines, trust boundaries and dependencies | Attack-surface and ownership map | Each prioritized boundary has a concrete entry point |
| 3. Hypothesize | Boundary map and observations | Write condition→action→violation→impact hypotheses; prioritize | Hypothesis backlog | Each hypothesis has a control and a stop condition |
| 4. Test | One hypothesis, allowed actions | Observe baseline; change one factor; compare; check side effects | Evidence and result | Confirmed, disproved, blocked, or needs a specific next test |
| 5. Validate | Candidate evidence | Reset, minimize, reproduce, inspect prerequisites, assess impact | Minimal PoC | Claimed boundary and affected asset are supported |
| 6. Report | Reproduction and policy | Write exact steps, evidence, impact, severity rationale, disclosure notes | Submitted report | Program can reproduce without guessing |
| 7. Follow through | Triage questions or fix | Answer, clarify, retest when authorized, coordinate disclosure | Resolution and learning | Cleanup and records completed |
Model actors, resources, and state#
Start with actor → entry point → authorization decision → operation → resource → consequence. Source review can expose the authorization decision directly; black-box testing uses controlled comparisons to infer behavior. Background jobs, exports, callbacks and notifications deserve their own rows because they may act under different identities.
For a multi-tenant application, prepare two tenants you control, an owner and restricted member in one tenant, and at least one account in the second tenant when allowed. Mark where roles are not available instead of pretending full coverage. Use synthetic documents, messages, payments in sandbox mode, and other reversible fixtures.
| Actor / state | Own resource | Same-tenant restricted resource | Other controlled tenant | Deleted/revoked/shared resource |
|---|---|---|---|---|
| Anonymous | As designed | Denied unless intentionally public | Denied unless intentionally public | Check intended public semantics |
| Restricted member | Only permitted operations | Role-limited | Denied | Recheck every state transition |
| Tenant owner | Tenant-scoped management | Tenant-scoped management | Denied | No restoration of revoked authority |
| Background job / service identity | Explicit delegated authority | Explicit delegated authority | No implicit cross-tenant access | Current permission or documented snapshot semantics |
The table is a starting model, not a universal expected result. A sharing product can intentionally allow cross-tenant access. Record the intended business rule before labeling the observation a vulnerability.
Write useful hypotheses#
Weak: “Check IDOR.” Useful: “A member of tenant B can retrieve tenant A's private export by replacing the export ID after it is created, because the download handler may validate the signed URL but omit tenant ownership.” Test only with tenant A and B under your control, using the real intended sharing rules as the baseline.
Weak: “This parser is dangerous.” Useful: “An unauthenticated import reaches a parser that accepts external resource references before the import permission check; a local callback should distinguish actual resource retrieval from a syntax error.” The callback must be permitted and contain no sensitive data.
Weak: “The model ignores instructions.” Useful: “A retrieved document controlled by a lower-privilege user can cause an agent to invoke a tool using another user's authority without the required confirmation.” A trace showing the prohibited action and the applicable authorization expectation is necessary.
Prioritize by expected research value#
Score each candidate from 0–3 for boundary importance, attacker reachability, evidence of a missing guard, novelty, and reproducibility. Subtract 0–3 for access/setup cost and duplicate likelihood. This original heuristic is useful for ordering work; it is not a probability model and should not replace judgment.
Start with high-value ownership, privileged workflow, import/export, identity recovery, integration, update, and trust-transition paths. Use scanner leads when they point to those boundaries. Defer expensive broad fuzzing until the scope, parser, harness and expected security consequence are clear.
Define coverage before selecting tools#
Create one row per security-relevant operation, not just one row per URL. Record its entry points, actors, object owners, lifecycle states, and downstream consumers. A single endpoint can contain several security decisions; several endpoints can share one decision. An absent UI button does not establish that an API action is forbidden.
Use this completion rule: each prioritized boundary has a successful control, a negative control or a documented reason it cannot be performed, a result, and an evidence reference. For deferred work, record the exact prerequisite or next test. Do not convert a checklist tick, a scanner's zero findings, or the manual's coverage chart into an assertion that an entire feature is secure.
| Coverage dimension | Questions to include | Typical missed variant |
|---|---|---|
| Identity lifecycle | Before enrollment, after recovery, after suspension, after revocation | Existing API key or refresh token survives deprovisioning |
| Resource lifecycle | Draft, published, shared, moved, archived, deleted | An export or cache preserves an earlier permission decision |
| Execution time | At request, enqueue, execution, delivery, and later retrieval | A worker checks a different object or obsolete authority |
| Input representation | URL, JSON, form, batch, protocol, normalization | Two parsers disagree on the effective parameter |
| External interaction | Incoming event, outbound call, retry, reconciliation | A valid webhook belongs to a different tenant |
| Resource budget | Per request, actor, tenant, recipient, and background job | A small batch triggers work beyond a request-rate limit |
The shared-module matrix helps choose procedures. Use the coverage record to store actual outcomes. For cost, availability, and sensitive workflow abuse, use the resource-budget procedure; keep these tests in a bounded local fixture unless the program expressly permits the proposed production experiment.
Testing controls#
Use a successful legitimate baseline, a prohibited baseline, and the proposed bypass. Keep identity, resource, configuration, version, and time recorded. An HTTP 200 does not prove successful access; inspect the returned synthetic marker or changed state. A 403 does not prove no side effect; verify the controlled resource if a state change might have occurred.
For asynchronous operations, record task IDs, callbacks, polling observations, and the identity under which processing occurs. For races, reproduce deterministically in a local harness first where possible; live concurrency needs program permission and a small bounded test. For crashes, distinguish invalid input handling, process termination, recoverability, and exploitable memory or isolation consequences.
Automation architecture#
Automate repeatable collection and bookkeeping first. Keep candidate discovery, authorization review, execution, evidence storage, and human validation as separate transitions. A target extracted from source, a redirect, a package dependency, or a model response must not enter the active queue automatically.
| Component | Responsibility | Required constraint |
|---|---|---|
| Policy record | Store exact policy and approved action set | Versioned, reviewed, and invalidated by changes |
| Candidate collector | Gather hostnames, routes, files, artifacts, dependencies | Discovery output remains unapproved |
| Scope evaluator | Normalize and match asset + action + environment | Deny unresolved or excluded cases; never guess ownership |
| Planner | Choose approved probes and explicit test hypotheses | Bound rate, concurrency, retries, time and destination |
| Executor | Run pinned tools in isolated contexts | No scope expansion through redirects, DNS changes, callbacks or generated commands |
| Evidence store | Preserve raw results, versions, timestamps and hashes | Access control, redaction, retention and separation of program data |
| Normalizer | Convert tool-specific results into common records | Preserve original evidence and avoid merging distinct vulnerabilities |
| Validator | Confirm reachability, controls, eligibility and impact | Human review before report submission |
Maintain an explicit status vocabulary: candidate, approved, queued, running, needs-validation, confirmed, false-positive, duplicate-lead, blocked, reported, resolved. Failed tools and untested paths must not become “clean” results. Rate budgets apply across workers, not independently per process; retries must consume the same budget.
AI can summarize source, suggest hypotheses, map routes, and draft reports, but its claims need evidence. Treat repository text, issue content, target pages, tool descriptions, and scan output as untrusted input. Do not let such content rewrite the scope policy, choose new destinations, disclose credentials, or publish findings. Keep private-program data out of external services unless the applicable rules permit that processing.
Report structure#
Lead with a specific title: “Tenant member can download another controlled tenant's private export through missing ownership check.” Follow with affected asset/version, starting privilege, expected behavior, actual behavior, reproducible steps, evidence, and concrete impact. Include the smallest PoC that proves the boundary; distinguish demonstrated consequences from possible follow-on impact.
Use the platform's required severity rubric. If submitting CVSS, provide the version and vector as well as the score, and explain assumptions. CVSS Base describes intrinsic vulnerability severity, not a complete organizational risk estimate or guaranteed payout. FIRST CVSS v4.0 specification, CVSS v4.0 user guide.
Check public advisories, prior disclosed reports, supported versions, and program exclusions before submission. A public fix does not automatically make a new variant a duplicate, and a different endpoint does not automatically make the same root cause a new issue. Explain the distinction and let the program apply its duplicate policy.
Triage and disclosure#
Answer questions with evidence and concrete reproduction changes. If a result depends on a non-default option, paid edition, proxy configuration, physical access, privileged starting account, or obsolete release, state that early. If severity is disputed, clarify the attacker capability and observed impact instead of repeating a score.
For an OSS finding, use the project's private security reporting route or coordinated disclosure channel. Discuss affected ranges, a fix, advisory ownership and CVE assignment with the maintainer or applicable CNA. CVE identifies a vulnerability record; it does not guarantee a reward or determine program acceptance. The CVE Program maintains the CNA operational rules. CNA Rules.
Do not infer a universal disclosure deadline. Follow the program terms and explicit coordination. If there is no response, use the stated escalation process or a suitable coordinator without publishing exploit details by default. Keep private invitations, target names, reports and artifacts confidential until disclosure is permitted.
Retest and close#
Recheck scope before retesting. Repeat the original minimal case, verify expected behavior, and inspect closely related variants only when authorized. Separate a regression from an independent flaw and record tested fixed versions. Remove synthetic data, revoke test tokens, shut down callbacks and lab resources, and retain only the evidence required by your records and program terms.
Record retest results for the original entry point, a legitimate neighboring operation, and any other caller of the corrected guard that is both relevant and authorized. A returned error is insufficient if a queued side effect still occurs. If the fix changes token revocation, account linking, cache ownership, or update verification, include the corresponding lifecycle boundary. When a variant remains untested, list it explicitly instead of claiming the patch closes the entire vulnerability family.
End each hunt with a small retrospective: what boundary mattered, which assumption failed, what evidence eliminated a false positive, and what reusable query or technique is worth keeping. Do not carry confidential details into reusable public templates.
References#
- FIRST. CVSS v4.0 Specification Document, document version 1.2; accessed 11 September 2026. Used for severity characteristics and metric groups.
- FIRST. CVSS v4.0 User Guide, version 1.2, 14 November 2025; accessed 11 September 2026. Used for Base severity versus risk and score/vector presentation.
- CVE Program. CNA Operational Rules, version 4.1.0, effective 14 May 2025; accessed 11 September 2026. Used for CVE/CNA coordination context.