Working templates

Copy these into a private per-target workspace. They are records, not executable authorization policies. Use the program's required report fields where they differ. Store credentials separately; the records use identity references and redacted evidence paths.

Scope record#

program:
  name: example-program
  policy_url: https://example.com/security/policy
  policy_checked_at: YYYY-MM-DDTHH:MM:SSZ
  policy_snapshot_sha256: REPLACE_WITH_ACTUAL_HASH
  intake_status: needs_review
  participation: public_or_invited
  enrollment_verified: false
  reward_eligibility: unknown
  disclosure_terms_reference: REPLACE

asset:
  kind: exact_url
  identifier: https://app.example.com:443/api/v1/export
  repository_commit_or_artifact_hash: null
  environment: designated_test_tenant
  ownership_evidence: REPLACE
  included_by: REPLACE_WITH_EXACT_POLICY_RULE
  exclusions_reviewed: false
  third_party_dependencies: []

activity:
  intended_method: controlled_authorization_comparison
  permitted_methods_reference: REPLACE
  identities: [owned_tenant_a_member, owned_tenant_b_member]
  data: synthetic_canaries_only
  rate_limit_from_policy: null
  internal_request_budget: null
  concurrency_limit_from_policy: null
  callback_destinations: []
  redirects_require_revalidation: true
  test_window: null
  stop_conditions: [scope_change, service_degradation, unexpected_sensitive_data]

decision:
  status: needs_review
  reason: no_active_testing_until_completed
  approved_actions: []
  reviewed_by: REPLACE
  recheck_on: [new_session, policy_change, ownership_change, new_destination]

Null limits and an empty approval list mean unresolved, not unlimited. A scope engine needs explicit logic for every asset type; this template deliberately does not pretend that a YAML list is sufficient enforcement.

Hypothesis card#

ID:
Asset and version:
Policy/action reference:
Starting actor and controlled input:
Legitimate workflow:
Expected security invariant:
Suspected missing guard:
Test fixture and reset:
Baseline successful operation:
Baseline prohibited operation:
Smallest proposed test:
Expected evidence if true:
Evidence that would disprove it:
Request/time/cost budget:
Stop condition:
Actual observations:
Demonstrated impact:
Unproven implications:
Status:
Next action:

Coverage record#

asset,version,entry_point,actor,resource_owner,action,state,boundary,status,evidence,limitation
local-fixture,COMMIT,/exports,tenant_a_member,tenant_b,read,private,tenant,untested,,awaiting_baseline

Use untested, passed, finding, blocked, or not_applicable. “Passed” means a specific test did not break the expected rule under recorded conditions. It is not a claim that the entire feature is secure. For client and hardware targets, replace endpoint-oriented columns with the relevant IPC method, parser entry point, physical interface, or update stage.

Include stable references when using the manual as a reusable testing system:

coverage_item:
  id: COV-001
  module_ids: [authz-matrix]
  vulnerability_family_ids: [bola-controlled-object-access]
  asset_ref: exact-approved-asset
  entry_point: POST_/exports
  boundary: tenant_and_document_ownership
  baseline_evidence: evidence/baseline-redacted.txt
  negative_control_evidence: evidence/control-redacted.txt
  result: untested
  observed_at: null
  tool_and_config_ref: null
  limitations: [worker_retrieval_not_yet_tested]
  next_action: observe_the_export_worker_under_two_owned_tenants

module_ids and vulnerability-family IDs are navigation references, not proof of test execution or final CWE classification. Record the assessed root cause and any conditional ATT&CK behavior separately after validation.

Retest matrix#

finding_ref,fixed_version,case,expected,actual,evidence,status
REPORT-001,FIXED_COMMIT,original_reproduction,deny_without_side_effect,,,untested
REPORT-001,FIXED_COMMIT,legitimate_control,allowed_operation_still_works,,,untested
REPORT-001,FIXED_COMMIT,shared_guard_variant,record_intended_rule,,,untested
REPORT-001,FIXED_COMMIT,queued_or_cached_result,record_lifecycle_semantics,,,untested

Keep the vulnerable and fixed environment manifests. Record whether a result depends on token renewal, a cache reset, delayed job completion, a client restart, or a newly issued artifact. Use not_applicable with a reason when a listed case has no corresponding surface.

Normalized evidence record#

{
  "record_type": "observation",
  "schema_version": 1,
  "program_ref": "private-local-reference",
  "asset_ref": "exact-approved-asset",
  "policy_snapshot_ref": "policy-sha256",
  "hypothesis_id": "H-001",
  "observed_at": "YYYY-MM-DDTHH:MM:SSZ",
  "tool": {"name": "manual", "version": "record_actual_version"},
  "environment": {"build": "actual-build", "principal_ref": "test-a"},
  "evidence": [{"path": "evidence/redacted-response.txt", "sha256": "actual-hash"}],
  "outcome": "needs-validation",
  "demonstrated_impact": null,
  "limitations": ["not_reproduced_after_reset"],
  "confidentiality": "program-private"
}

Keep raw tool output and the normalized observation together. Do not discard stderr, request ordering, source path, or configuration needed to explain a result. Deduplicate on root cause and affected boundary; a shared scanner rule ID alone is not a sound duplicate key.

Reproducible report#

Title
[Starting actor] can [unauthorized action] on [resource] through [root cause]

Summary
Describe the actual boundary violation and demonstrated consequence in 2–4 sentences.

Affected asset and versions
Exact URL/repo/package/app/contract/device identity, tested release/commit/hash.
Separate tested affected versions from inferred ranges.

Preconditions
Starting account/role, owned tenants/data, supported configuration, build and setup.

Steps to reproduce
1. Reset/setup the controlled fixture.
2. Establish the normal successful and denied behaviors.
3. Perform the minimal candidate operation.
4. Verify the resulting synthetic data or state.

Expected behavior
The documented or clearly intended security invariant.

Actual behavior
The observed result, with evidence references and relevant timestamps.

Impact
What the attacker demonstrably gains; clearly label additional inferred consequences.

Evidence
Minimal requests/inputs, responses/state, logs, artifact hashes, source path and PoC.
Redact tokens and irrelevant private data.

Severity
Required program rubric; CVSS version/vector if applicable; assumptions explained.

Root cause and remediation suggestion
Relevant guard or trust decision; a focused correction where known.

Cleanup and disclosure
Actions taken, test records remaining, confidential coordination preferences.

OSS lab manifest#

Repository URL:
Source commit and tag:
Product edition:
Artifact/image digest:
OS/architecture/runtime:
Dependency lockfile hash:
Build command and trusted toolchain versions:
Network access required during setup:
Configuration delta from documented default:
Test users and synthetic objects:
Reachable public interface:
Exact local reproduction:
Expected and observed result:
Reset and teardown:
Affected/fixed version evidence:

AI trial record#

Product/model/runtime version:
Legitimate user task:
Attacker-controlled surface:
Private synthetic marker location:
Confirmation that marker is absent from attacker input:
Caller identity and available tools:
Applicable tool permissions and approval requirement:
Prompt/input and retrieved artifact hashes:
Sampling settings and session reset:
Baseline trials:
Candidate trials:
Successful boundary violations / total trials:
Actual retrieval/tool audit event:
Attacker-visible result:
Unproven broader impact:

Web3 and device addenda#

End-of-session note#

Resolved today:
Best remaining hypothesis:
Exact next file/function/request:
Access or policy blocker:
Evidence saved:
Cleanup due:
Reason to continue or rotate: