/security-test-tool-governance

name: security-test-tool-governance
description: "Governs supplied benign security-test tool artifacts through purpose, authority, provenance, artifact integrity, safety-test evidence, version-bound review, custody, change control, and defensive handoff. Use when reviewing proposed security tooling or deciding whether an externally supplied artifact is ready for an authorized isolated test, without generating source code, payloads, build procedures, bypasses, or deployment instructions."
allowed-tools: Read Grep Glob

Security test tool governance

Produce an evidence-bound ledger for externally supplied opaque benign artifacts.

When to Use

• Reviewing proposed security tooling or deciding whether an externally supplied artifact is ready for an authorized isolated test, without generating source code, payloads, build procedures, bypasses, or deployment instructions.
• Use only within explicit authorization and the stated rules of engagement.

When NOT to Use

• Do not treat this skill as permission to access, test, or change a target.
• Do not convert missing evidence into a clean result or a stronger claim.

Boundary

Accept inventory facts and external receipts only. Never fetch, reconstruct, modify, compile, sign, execute, deploy, or distribute a referenced tool. Never provide source code, pseudocode, tool commands or flags, build recipes, payloads, loaders, injection or in-memory execution instructions, persistence, credential access, lateral movement, C2, covert channels, evasion, packing, obfuscation, signature avoidance, telemetry blinding, security-control tampering, target selection or locators, stealth rankings, or quieter-tool recommendations.

Only isolated labs and dedicated non-production test tenants with explicit separation evidence are supported. Release is an externally evidenced controlled handoff to an approved internal lab. Production use, customer deployment, public distribution, and operational use have no contract state. Restricted or unknown capabilities are inventory facts that force prohibition and quarantine; an authorization cannot waive that boundary.

Workflow

1. Record purpose, policy snapshot, assessment cutoff, scope, authority window, permitted governance actions, operator roles, non-production boundary, and numeric ceilings. Missing authority remains visible; governance readiness never grants execution authority. 2. Register each supplied artifact, source, configuration, supplier, component, and declared capability using only opaque references and exact SHA-256 digests. A digest establishes identity, not safety. Do not open opaque content to fill an evidence gap. 3. Have the offline review recompute the versioned canonical manifest from candidate identity and sorted component/capability declarations. Any material change requires a replacement candidate and fresh downstream evidence; a supplied digest assertion cannot inherit prior approval. 4. Pin the sandbox fingerprint, synthetic-data boundary, production separation, containment, rollback baseline, and validity window. Drift invalidates current claims even when the artifact bytes are unchanged. 5. Instantiate all assurance criteria for every candidate before importing results. Applicability comes from the artifact-class matrix. Keep planned, failed, blocked, prohibited, inconclusive, and evidence-bound not-applicable cells in the denominator; absence is never a pass. 6. Import separate provenance, integrity, dependency/source review, independent review, containment, functional, safety, observability, stop, and restoration receipts. Every supporting member must match its exact binding tuple and chronology. Supplier attestations cannot substitute for independent review; execution evidence cannot substitute for criterion-outcome evidence. 7. Record current readiness gates, reserved and consumed budgets, applicable successfully pretested stop controls, custody readiness, and cleanup readiness. Derive readiness from these records, authority, identity, coverage, and issues. Preserve approval-required, blocked, and prohibited states without laundering them into lab-ready. 8. Import facts from separately authorized bounded synthetic lab validation. This workflow does not perform it. Bind each run to its exact case, authority, candidate/manifest, sandbox/fingerprint, policy, gate, budget, stop, and cleanup records. Keep execution, criterion outcome, observability, stop event, and cleanup receipts distinct. Failed and stopped runs consume budget; a fired stop is terminal. A retry needs remaining capacity and a later decision. 9. Preserve custody for each evidence artifact and its aliases. Keep failed, stopped, inconclusive, and unexecuted cases. Evidence disposal requires its own external authority and receipt; endpoint cleanup cannot authorize it. Record cleanup separately and retain blocked or failed restoration obligations. 10. Derive issues and remediation from assurance failures and contradictions. A supplied change receipt does not close an issue. Record externally authorized change, a materially new replacement candidate, and later exact verification of the original criterion in an equivalent approved sandbox. Preserve the failed candidate, supporting evidence, and unresolved issues. 11. Derive lab eligibility only with complete applicable passing assurance, current identities and approval, complete run cleanup, and no blocking or prohibited capability. Validate a supplied release occurrence receipt against the exact candidate, manifest, artifact, sandbox, scope, policy, authority, internal-lab recipient, channel, owner, and window. Have the review recompute the canonical handoff digest over the exact recipient and release facts; recipient class is only `internal-lab`, and channels are only `controlled-repository`, `sealed-offline-media`, or `mana