Skip to content
Back to skills

Security Test Tool Governance

ASecurity

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.

  • 53 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 16, 2026
securitygosecurity

Works with

  • terminal

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned October 16, 2026

npx -y skills add zero-lab-ai/skills --skill security-test-tool-governance --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Security Test Tool Governance?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Security Test Tool Governance
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/zero-lab-ai-security-test-tool-governance/badge)](https://www.skillsdirectory.com/skills/zero-lab-ai-security-test-tool-governance)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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 `managed-lab-import`;
    approval, occurrence, and withdrawal receipts must bind that digest. Changed
    handoff facts invalidate inherited receipts. Occurrence is not approval.
12. Derive expiry and withdrawal obligations after authority expiry/revocation,
    policy or sandbox drift, material change, disposed evidence, prohibited
    behavior, or a blocking issue. A later exact withdrawal receipt records
    withdrawn. Export opaque blocker, cleanup, issue, remediation, and handoff
    IDs to defensive owners without operational instructions.

13. Treat a complete review as an internally consistent record only. It never
    establishes authenticity, safety, execution authority, production
    suitability, or release permission.

## Boundary with adjacent skills

`detection-resilience-test-plan` owns separate hypotheses, attempts, defensive
outcomes, test cleanup, and detector remediation. This skill owns artifact
provenance, assurance, custody, version validity, and defensive handoff beforehand.
Neither constructs implementations. `protocol-exploitation-assessment` owns
service weakness applicability and bounded reproduced faults; do not emit protocol
requests or vulnerability proofs here. `opsec-planning` owns observer analysis;
do not select quieter tools. `recon-automation-governance` owns jobs, targets,
schedules, contact budgets, and orchestration; this skill owns candidate assurance.
`findings-report` owns final findings and impact-derived severity. Export typed
assurance issues here, without assigning vulnerability ratings.
`binary-fault-triage` and `binary-fault-validation-readiness` own binary fault
prerequisites; never derive exploit primitives or feasibility here.
`engagement-report-assembly` owns the final engagement report; provide only the
typed governance export.

## Rationalizations to reject

- “The lab is authorized, so generate or execute the helper.” Authority cannot
  waive the opaque-artifact boundary; import external facts instead.
- “It is signed, reproducible, or hash-matched, so it is safe.” These establish
  limited identity/provenance facts and cannot replace independent assurance.
- “The function is optional or disabled.” Restricted or unresolved inventory
  still forces prohibited readiness and quarantined lifecycle.
- “The artifact barely changed; carry forward the review.” Material identity
  includes source, configuration, dependencies, capabilities, sandbox, and policy;
  mismatches invalidate current downstream claims.
- “Discard failed cases or count only tested cells.” This hides the denominator
  and creates unsupported coverage. Preserve every required cell and result.
- “A successful run proves every safety criterion.” Receipt roles and bindings
  are separate; a run cannot satisfy unrelated criteria.
- “Cleanup permits deleting inconvenient evidence.” Custody disposition and
  endpoint restoration need independent authority and receipts.
- “The fix or handoff happened, so approval is implied.” Changes require later
  verification; occurrence receipts never replace approval or withdrawal proof.

Files in this skill

  • SKILL.md8.9 KB
  • agents/openai.yaml238 B
  • assets/zero-lab-mark.svg10.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.