AgentStack
SKILL verified MIT Self-run

Dynamic Verification

skill-shieldnet-360-secure-vibe-dynamic-verification · by ShieldNet-360

Confirm or refute a vulnerability candidate against a live target with a deterministic probe (the agent runs the probe, respecting authorization and scope) — Applies to: when a static/SAST or LLM review flags a possible injection or SSRF; when triaging a finding before opening a bug or shipping a fix; when an authorized dynamic test against a running app is available; when a verification result t…

No reviews yet
0 installs
5 views
0.0% view→install

Install

$ agentstack add skill-shieldnet-360-secure-vibe-dynamic-verification

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Dynamic Verification? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Verify Findings

Confirm or refute a vulnerability candidate against a live target with a deterministic probe (the agent runs the probe, respecting authorization and scope)

ALWAYS

  • Treat a static-analysis or LLM-review hit as a candidate, not a vulnerability, until a probe with a deterministic oracle confirms it against a live target.
  • Prefer an oracle that proves server-side behaviour over one that inspects the response text: out-of-band callbacks (SSRF, blind command injection, XXE) and timing deltas (blind SQLi, command injection) catch blind bugs that leave no trace in the body.
  • Re-confirm any timing-based result a second time before trusting it — one slow response is noise, a repeatable delay over baseline is signal.
  • For reflected oracles (XSS, SSTI), require the dangerous form: XSS confirms only when the payload comes back UNESCAPED; SSTI confirms only when the arithmetic is EVALUATED (the product appears as a standalone number and the raw expression does not).
  • Pin file-read oracles (path traversal) to a content signature of a known system file (root:…:0:0: from /etc/passwd, [fonts] from win.ini), never to a generic 200/404.
  • Drive the probe yourself with SecureVibe's scope-gated primitives: http_probe (send one crafted request, read status/headers/body/timing) and oob_listener (allocate a callback URL, poll for blind hits). They fire only at a target the operator authorized — otherwise they return a dry-run plan and send nothing.
  • Reach past http_probe for what it cannot prove: use your own headless browser for XSS execution-proof and DOM-based XSS, and your own shell (see list_external_tools) for heavyweight scanners. SecureVibe ships the light primitives; the heavy tools are yours.
  • When a verdict turns out wrong (a "confirmed" that is actually benign, or a "refuted" that was real), root-cause why the oracle misled you before moving on. If it was a target-specific PoC flaw (payload filtered, sink not reached, timing threshold, OOB unreachable) → fix the PoC and re-probe. If this skill's guidance was itself wrong (bad oracle, mis-mapped class, missing caveat) → record it with propose_skill_update so the knowledge is fixed, not just this run.

NEVER

  • Send an attack payload at a host you are not explicitly authorized to test — authorization lives in the operator scope, not in the model's judgement.
  • Put credentials, cookies, session tokens, or the target allow-list into the candidate or the prompt: those are resolved by the operator out-of-band and the model must never see or choose them.
  • Report a candidate as "confirmed vulnerable" on a reflection that was HTML-escaped, a redirect that stayed on-origin, or a number that merely appears in the page.
  • Treat a dry-run plan (nothing was sent) as a refutation — it is "not yet tested".
  • Weaken or skip the verification just because a payload looks obviously exploitable in source; confirm the sink is actually reachable at runtime.

KNOWN FALSE POSITIVES

  • XSS payload reflected but HTML-escaped → output encoding is working; refuted, not a bug (it may still be an encoding lead, not an executable XSS).
  • XSS marker not in the server response (http_probe body) → does NOT refute DOM-based XSS: the payload may flow entirely client-side. Read the client JS or render in a browser before refuting.
  • A single elevated latency on a time-based SQLi/command-injection probe → could be GC, cold cache, or network jitter; only a re-confirmed delta counts.
  • SSTI product matching as a substring of a longer number (an id, price, timestamp, asset path like /img/6725936.jpg) → not evaluation; require a standalone number.
  • SSRF/XXE with no out-of-band listener available → inconclusive, not refuted; the blind oracle could not run.
  • Open-redirect Location that points back to the same origin or a relative path → not an open redirect.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.