docs: add VEX integration guidance to dependabot prompt

[Copilot]

The dependabot.md agent prompt had no guidance on what to do when Dependabot alerts are dismissed — that security context was lost with no machine-readable record.

Changes to .github/aw/dependabot.md

• New section: "Dismissed Dependabot Alerts and VEX" — concise summary explaining when to generate a VEX (Vulnerability Exploitability eXchange) statement for dismissed alerts (not_used, inaccurate, tolerable_risk), and when to skip (no_bandwidth)
• Reference to openvex.dev — instructs the agent to learn the full OpenVEX format, purl construction, and dismissal-to-justification mappings from openvex.dev before generating statements
• Updated Related Documentation — added link to the OpenVEX specification

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.

[pelikhan]

@copilot keep it shorter and notify the agent to learn about VEX for full details

[Copilot]

@copilot keep it shorter and notify the agent to learn about VEX for full details

Done in ca87807. Replaced the detailed tables, JSON template, and sub-sections with two concise sentences that cover when to generate VEX, how to trigger the vex-generator workflow, and a pointer to openvex.dev for the full spec.

[pelikhan]

@copilot this file does not know about vex-generator but it teaches about VEX in general

[Copilot]

Fixed in 898c086 — removed the vex-generator workflow reference. The sentence now simply points the agent to openvex.dev for the format, purl construction, and dismissal-to-justification details.

[github-actions]

Hey @Copilot 👋 — great addition! Documenting VEX/OpenVEX guidance directly in the Dependabot agent prompt is exactly the kind of machine-readable security context this project benefits from, and the distinction between substantive dismissal reasons (not_used, inaccurate, tolerable_risk) vs. no_bandwidth is a nice touch.

A couple of things worth addressing before moving out of draft:

• Draft status — the PR is currently marked as a draft. Once you're confident the content is complete, flip it to "Ready for review" so @pelikhan can take a final look.
• No test coverage — this is a docs-only change to an agent prompt, so traditional unit tests don't apply. However, if there's a smoke-test or integration fixture for the dependabot agent prompt (e.g., in the test suite that validates agent prompt structure or references), it would be worth adding a case that exercises the new VEX section.
• No linked issue — the CONTRIBUTING guidelines encourage tracing work back to an issue/agentic plan. If this work was spawned by an issue, linking it in the body (Closes #NNNN) would give maintainers the full context trail.

If you'd like a hand closing these out, here's a prompt you can hand to your coding agent:

In the repo github/gh-aw, PR #22027 added a "Dismissed Dependabot Alerts and VEX" section to `.github/aw/dependabot.md`.

Please do the following:
1. Search the test suite (look under `test/`, `*_test.go`, and any fixture directories) for existing tests that validate `.github/aw/*.md` agent prompt files — structure checks, link checks, or schema validation.
2. If such tests exist, add a test case (or extend an existing one) that covers the new VEX section in `dependabot.md`.
3. If no such tests exist, add a brief note in the PR description explaining why tests are not applicable for this change.
4. Run `make agent-finish` to confirm all quality gates pass.
5. Mark the PR as ready for review.

Generated by Contribution Check · ◷

[Copilot]

Pull request overview

Adds guidance to the Dependabot agent prompt for preserving security context when Dependabot alerts are dismissed, by recommending OpenVEX/VEX statements for certain dismissal reasons.

Changes:

• Added a new “Dismissed Dependabot Alerts and VEX” section describing when to generate an OpenVEX statement for dismissed alerts.
• Added instructions to consult openvex.dev for OpenVEX format, purl construction, and justification mappings.
• Updated “Related Documentation” with a link to the OpenVEX specification.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The guidance says to write the VEX statement to .vex/<ghsa-id>.json, but this repo currently has no .vex/ directory. Please update the instructions to explicitly create the directory (e.g., mkdir -p .vex) and clarify whether the resulting JSON should be committed to the repo (and if so, consider adding a .gitkeep/README so the folder exists even before the first statement).

Suggested change

	When a Dependabot security alert is dismissed with a substantive security reason (`not_used`, `inaccurate`, or `tolerable_risk`), consider generating a [VEX (Vulnerability Exploitability eXchange)](https://openvex.dev/) statement to record the assessment as a machine-readable OpenVEX v0.2.0 document in `.vex/<ghsa-id>.json`. Alerts dismissed as `no_bandwidth` do not represent a security decision and should not produce a VEX statement.
	When a Dependabot security alert is dismissed with a substantive security reason (`not_used`, `inaccurate`, or `tolerable_risk`), consider generating a [VEX (Vulnerability Exploitability eXchange)](https://openvex.dev/) statement to record the assessment as a machine-readable OpenVEX v0.2.0 document.
	Recommended workflow:
	- Ensure the VEX directory exists at the repo root: `mkdir -p .vex`
	- Write the OpenVEX statement to `.vex/<ghsa-id>.json` (for example, `.vex/GHSA-xxxx-xxxx-xxxx.json`)
	- Add and commit the VEX JSON file alongside the corresponding Dependabot alert dismissal so the assessment is version-controlled
	- (Optional) Add a `.vex/.gitkeep` or `.vex/README.md` file and commit it so the `.vex/` directory exists in a fresh clone even before the first VEX statement is generated
	Alerts dismissed as `no_bandwidth` do not represent a security decision and should not produce a VEX statement.