Vulnerability Validation

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 206587dd9725 · 16 Oct 2026Report an issue or request a re-scan

• Publishercodexstar69 GitHub userOwner of the repository this skill is read from
• Source foldercodexstar69/bug-hunter/skills/vulnerability-validationThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict206587dd9725A new audit runs when the source changes
• Repository statusNot archivedLast push 60 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Validate security findings for exploitability, reachability, and real-world impact using Bug Hunter-native findings artifacts. Use after security scans, before patch generation, or whenever the user wants confirmation…

---
name: vulnerability-validation
description: Validate security findings for exploitability, reachability, and real-world impact using Bug Hunter-native findings artifacts. Use after security scans, before patch generation, or whenever the user wants confirmation that a suspected vulnerability is actually exploitable.
---

# Vulnerability Validation

This is a bundled local Bug Hunter companion skill. It strengthens the security-specific parts of the Skeptic/Referee process.

## Purpose

Take suspected or confirmed security findings and answer:
- Is the vulnerable path reachable?
- Can an attacker control the input?
- Are there existing mitigations?
- How exploitable is it really?
- What is the CVSS / PoC / impact level?

## Inputs

Prefer Bug Hunter-native artifacts:
- `.bug-hunter/hunter-findings.json`
- `.bug-hunter/threat-model.md`
- `.bug-hunter/security-config.json`
- `.bug-hunter/dep-findings.json` when dependency issues are involved

## Workflow

1. Read the findings and isolate the security ones.
2. Trace reachability:
   - EXTERNAL
   - AUTHENTICATED
   - INTERNAL
   - UNREACHABLE
3. Trace exploitability:
   - EASY
   - MEDIUM
   - HARD
   - NOT_EXPLOITABLE
4. Check for mitigations already present in code, framework behavior, or deployment assumptions.
5. For confirmed HIGH/CRITICAL security bugs, generate:
   - exploitation path
   - benign proof of concept
   - CVSS vector + score
6. Feed the result back into Bug Hunter-native verdicting.

## Outputs

When used as a companion to the main pipeline, keep outputs compatible with:
- `.bug-hunter/referee.json`
- `.bug-hunter/report.md`

If a separate validation artifact is helpful for the run, place it under `.bug-hunter/validated-findings.json`.

## Important constraints

- This skill validates findings; it does not replace the normal fix pipeline.
- Keep outputs portable and self-contained under `.bug-hunter/`.
- Prefer explicit reasoning for false positives so the user can trust dismissals.

Excerpt, first 1,986 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/codexstar69/bug-hunter
git -C bug-hunter checkout 206587dd9725

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 206587dd9725

Questions about Vulnerability Validation

• github.com/codexstar69/bug-hunter/tree/main/skills/vulnerability — the audited source at commit 206587dd9725 and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology