Vuln ReportSAFE

Vigolium - High-fidelity vulnerability scanner fusing agentic AI with native speed, modularity, and precision

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: vuln-report
description: Draft a single-vulnerability report in GitHub advisory style from an audit finding, bug note, patch diff, PoC, or code review evidence. Use when Codex needs to turn one confirmed security issue into a clean disclosure-ready report with the fixed section set — Summary; Severity, Confidence, Vulnerability Type; Impact; Affected Component; Source to Sink Flow; Vulnerable Code; Proof of concept & Evidence; Preconditions; Remediation — with embedded code snippets, explanatory prose that points to the vulnerable code, and inline GitHub markdown links to source evidence.
---

# vuln-report.md

## Overview

Draft one disclosure-ready report for one confirmed bug. Keep the report evidence-driven, concrete, and concise. Prefer the section order and phrasing rules in [references/report-template.md](references/report-template.md).

## Workflow

1. Confirm the report is about one bug only.
2. Extract the minimum facts needed to prove the issue:
   - vulnerable component or behavior
   - attacker-controlled input or missing validation
   - preconditions and trust boundary
   - exploit result
   - practical impact
   - strongest reproduction path
   - decisive source locations and any relevant fix commit
3. Separate demonstrated facts from inference. State assumptions explicitly.
4. Draft the report using the required section order from [references/report-template.md](references/report-template.md).
5. Always embed at least one fenced code snippet from the decisive code path, and explain what each snippet proves.
6. Always convert repository file references and patch references into GitHub markdown links, and prefer embedding those links directly into the surrounding explanation instead of listing them separately.
7. Keep the nine-section contract exactly; fold any enrichment (CWE/CVSS, preconditions, references) inside the relevant required section rather than adding new H2s.
8. Save the final report as `report.md` inside a folder named with the bug's severity identifier (`C1`, `H1`, `M1`, etc.) followed by a lowercase hyphenated slug derived from the final report title. Use `C` for Critical, `H` for High, `M` for Medium, sequentially numbered if there are multiple bugs of the same severity. Example: `C1-cross-site-websocket-hijacking-re-enabled-by-allow-websocket/report.md`. Also, ensure the bug report title and internal references use this ID (e.g., '[C1] Cross-Site WebSocket Hijacking'). Do not write reports for Low severity findings — document them in the summary table only.
9. Remove filler, hedging, and unproven claims before finalizing.

## Required Sections

The report begins with a single `# <Finding Title>` H1 (prefixed with the
severity ID, e.g. `# [C1] SQL Injection in Login`), then exactly these H2
sections, in this order, with these exact headings:

1. `## Summary`
2. `## Severity, Confidence, Vulnerability Type`
3. `## Impact`
4. `## Affected Component`
5. `## Source to Sink Flow`
6. `## Vulnerable Code`
7. `## Proof of concept & Evidence`
8. `## Preconditions`
9. `## Remediation`

This is a fixed contract — every report uses this exact set and order so the
report-composer and downstream tooling can parse sections deterministically.
Do **not** add a standalone `Details` or `Root Cause` section: the root-cause
analysis is the closing paragraph of `## Source to Sink Flow`. Do not rename,
reorder, merge, or drop any of the nine required sections even if a section is
thin — write `None.` or `Not applicable.` rather than omitting it.

## Evidence Rules

- Include one or more fenced code snippets in the report, primarily in `Vulnerable Code` (and `Source to Sink Flow` where a snippet clarifies the path).
- Use the smallest snippet that proves the bug.
- Introduce each cited code location with a short explanation of why it matters; do not drop raw link lists without commentary.
- Add GitHub markdown links for source files, line anchors, controllers, helpers, patch commits, or affected surfaces whenever the repository is on GitHub and the target URL is known or can be derived.
- When constructing GitHub source links, use the latest commit SHA (from `git rev-parse HEAD` or the most recent commit visible in context) instead of a branch name such as `main` or `master`, so links remain stable after future commits.
- Prefer embedding inline markdown links into explanatory sentences such as `The following code in [build_request](https://github.com/org/repo/blob/main/src/executor.rs#L10) reads attacker-controlled input without validation.`
- Keep non-GitHub standards or spec citations as normal markdown links.

## Self-Contained Rule

`report.md` is a disclosure-ready artefact. The reader must understand the vulnerability, the trace, the impact, and the reproduction without opening any sibling working file (drafts, debate transcripts, review notes, internal metadata).

- Do not write prose pointers such as `See draft.md`, `See debate.md`, `See adversarial-review.md`, `See metadata.json`, `See pN-NNN for full trace`, `See AP-NNN`, `Refer to the draft for impact analysis`, or `for the full trace see ...`. If that content is needed in the report, **inline it**.
- Do not cite internal phase IDs (`pN-NNN`, `p10-NNN`, `AP-NNN`) — these are pipeline bookkeeping, not reader-facing references.
- Sibling-file references are only allowed for runnable evidence artefacts shipped alongside the report (e.g. `poc.<ext>`, `evidence/<file>`), and only inside the `Proof of concept & Evidence` or `Impact` sections. Quote the decisive lines from logs inline rather than telling the reader to open them.
- GitHub links to source code (pinned to a commit SHA) are external evidence, not deferred narrative — those are required, not banned.
- Before finalizing, scan the draft for the banned phrasings above and rewrite any occurrence to inline the content.

## Section Rules

### Summary

One short paragraph: the vulnerable behavior, the attacker control, and the outcome. Name the component only 

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.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

AGENTS.md

Gates applied: no_behavioural_pass.