Vulnerability Validation

codexstar69/bug-hunter/skills/vulnerability-validation

by codexstar693be69733a27aa04d4f5620df203c05350d162067No license519 starsListed Oct 9, 2026Updated Oct 9, 2026Repository updated 7 weeks ago

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.

Instructions onlySecurity
AI-generated overview

Validates suspected security findings for reachability, exploitability and real-world impact, producing CVSS scores and proof-of-concept notes.

What it does
This skill takes suspected or confirmed security findings, preferably from Bug Hunter artifacts such as hunter-findings.json and threat-model.md, and isolates the security-relevant ones. It traces whether the vulnerable path is reachable (external, authenticated, internal or unreachable) and how exploitable it is (easy, medium, hard or not exploitable), and checks for existing mitigations in code, framework behavior or deployment assumptions. For confirmed high or critical bugs it generates an exploitation path, a benign proof of concept and a CVSS vector and score, writing results into Bug Hunter-compatible artifacts such as referee.json, report.md or validated-findings.json.
When to use it
Use it after security scans, before patch generation, or whenever someone wants confirmation that a suspected vulnerability is actually exploitable. It fits workflows that already use Bug Hunter-native findings and want explicit reasoning about false positives.
Requirements
Instructions only; no scripts are shipped. It expects Bug Hunter-native artifacts under a .bug-hunter directory (for example hunter-findings.json, threat-model.md, security-config.json and optionally dep-findings.json) and writes outputs back into that directory.

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.

Source and attribution

Source:codexstar69/bug-hunterinskills/vulnerability-validationat commit3be6973

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal