Common Exploit VerificationSAFE
A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages
Overview
A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages
6f5be687a268OBSERVED · 2026-10-14What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: common-exploit-verification
description: Enforce "No Exploit, No Report" policy with PoC construction standards, false-positive filtering, and evidence collection per vulnerability class across backend, frontend, and mobile. Use when validating security findings, constructing exploit proofs, filtering false positives, or writing pentest findings.
metadata:
triggers:
keywords:
- exploit verification
- proof of concept
- PoC
- false positive
- validate finding
- exploit proof
- pentest finding
- security evidence
---
# Exploit Verification Standard
## **Priority: P0 (CRITICAL)**
## Always-Apply Rules
- **No Exploit = No Report**: Finding without reproducible PoC is discarded. No exceptions.
- **No Theoretical Findings**: "This could be exploited if..." → rejected. Demonstrate actual impact.
- **No Tool Output as Evidence**: Scanner output alone insufficient. Manual verification required.
## PoC Construction
Every confirmed finding must include all fields:
```
ID: [unique identifier]
Vulnerability: [CWE-XXX: type name]
Platform: [backend|frontend|mobile-ios|mobile-android]
Component: [file:line or endpoint]
Severity: [Critical|High|Medium|Low] (CVSS: X.X)
OWASP: [mapping — e.g., A03:2021, API1:2023, M4:2024]
-- Proof of Concept --
Preconditions: [required state, auth level, config]
Steps:
1. [exact step with command/payload]
2. [expected vs actual result]
Payload: [exact input — copy-paste ready]
Evidence: [response body, status code, data returned]
-- Impact --
Impact: [what attacker gains — data, access, control]
Blast Radius: [lateral movement, escalation paths]
-- Remediation --
Fix: [specific code change, not generic advice]
```
## Validation Gate
| Result | Action | Criteria |
|---|---|---|
| ✅ Confirmed | Include in report | PoC reproduces, impact demonstrated |
| ⚠️ Conditional | Include with conditions | Requires specific config/timing/race |
| ❌ Unconfirmed | **Discard** | Cannot reproduce despite 3 attempts |
| 🔄 Degraded | Downgrade severity | Partial impact, mitigating controls exist |
## False Positive Filters
See [false-positive-checklist](references/false-positive-checklist.md) for platform-specific filters.
Quick checks before reporting:
- **SAST-only finding**: Is the flagged code actually reachable from user input? Trace full data flow.
- **Scanner noise**: Does the "vulnerability" have compensating controls (WAF, middleware, framework defaults)?
- **Version mismatch**: Is the CVE for a function the project actually uses (reachability analysis)?
- **Client-side only**: Is the "bypass" only client-side while server enforces correctly?
## Anti-Patterns
- **No severity inflation**: Missing header ≠ Critical. CVSS score must match demonstrated impact.
- **No duplicate findings**: Same root cause across endpoints = 1 finding with multiple affected components.
- **No remediation without specificity**: "Use parameterized queries" → include the exact code change for the affected file.
## References
- [False Positive Checklist](references/false-positive-checklist.md) — platform-specific false positive filters
- [Exploit Playbook](references/exploit-playbook.md) — PoC templates per vulnerability class (backend, frontend, mobile)Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (2)
exploit-playbook.md
| "No jailbreak detection" | Is the app's risk profile low enough that jailbreak detection isn't required? |
Gates applied: no_behavioural_pass.
6f5be687a268full audit observations/trust-audit/skill/hoangnguyen0403__common-exploit-verification.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-14 | 6f5be687a268 | SAFE | B | 89 | first audit |
Questions
What does the Common Exploit Verification skill do?
A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages
Is Common Exploit Verification safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Common Exploit Verification access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (6f5be687a268), read on 2026-10-14. The repository is watched, and a new audit runs when it changes — this is the first audit.