CVE Analysis Prompt — REFLEX Framework

Use this prompt to generate a complete CVE analysis page for the Reflex Framework website. Feed it to an LLM along with the CVE identifier and any supporting context (vendor advisory, NVD entry, proof-of-concept links).

Prompt

You are writing a CVE analysis for the Reflex Framework (https://reflexframework.github.io), a developer-first security education site. Your output must be a complete, publish-ready Quarto (.qmd) page that teaches developers about this vulnerability through the REFLEX methodology.

Analyze **[CVE-YYYY-NNNN]** and produce the full .qmd file described below.

### Research instructions

Before writing, gather accurate data for the following. Do not guess — if you cannot confirm a detail, say so explicitly:

- The exact vulnerable version range (e.g. "2.0-beta9 through 2.15.0", not "older versions")
- The exact safe version to upgrade to
- The CVSS 3.1 score and severity rating
- The technical root cause (CWE if available)
- Whether HeroDevs provides Never-Ending Support for this specific technology — only include the HeroDevs NES callout if this is confirmed true
- At least 3 authoritative references (NVD, vendor advisory, technical write-ups)

---

### Output format

Produce a single Quarto .qmd file with the following structure, in this exact order:

#### 1. YAML Frontmatter

```yaml
---
title: "CVE-YYYY-NNNN: [Vulnerability Name] - REFLEX Analysis"
categories: [cve-analysis]
tags: [supply-chain, dependency, rce, ...]  # relevant tags
date: YYYY-MM-DD  # date the analysis is written (not the CVE publication date)
---

2. CVE Overview (metadata block)

Present these fields exactly:

  • CVE ID: CVE-YYYY-NNNN
  • Component/Software: Name of the affected library, framework, or system only
  • 🚨 Vulnerable Versions: [exact version range]
  • Severity: [CVSS score] [SEVERITY LEVEL] (CVSS 3.1)
  • Impact: One-sentence description of what the vulnerability allows
  • Date: Discovery or publication date
  • ✅ Safe Version: Upgrade to [exact version] or later

3. Support Callout (conditional)

If HeroDevs provides NES for this technology:

:::{.callout-important}
## HeroDevs Never-Ending Support (NES)
Organizations running legacy applications that cannot easily upgrade can leverage [HeroDevs Never-Ending Support](https://herodevs.com/support) for continued security patches and guidance on legacy versions of [technology name].
:::

If HeroDevs does NOT provide NES for this technology:

:::{.callout-note}
## Legacy System Support
For organizations unable to immediately upgrade, consider implementing the temporary mitigations in the Fortify section while planning your upgrade path.
:::

4. Opening Hook + Scenario

Hook (1–2 sentences, bold): A punchy, memorable line that frames the significance of this CVE. Example: “The vulnerability that broke the internet. Log4Shell allowed attackers to execute arbitrary code on millions of systems by exploiting a logging library present in countless Java applications.”

Scenario (one paragraph, 4–6 sentences): A vivid narrative that dramatises how this specific vulnerability could be discovered and exploited in a realistic setting. Use a named attacker persona and a believable target — a company, a developer, a CI pipeline — to make the threat concrete. The scenario should:

  • Be specific to this CVE’s actual attack vector (not generic)
  • Show the chain of events from discovery to impact
  • Make the reader think “that could be us”
  • End with the consequence (data exfiltrated, code executed, credentials stolen, etc.)

Model this on the battlecard scenario format. Example tone:

An attacker named “Vex” monitors npm security advisories and spots CVE-YYYY-NNNN within hours of disclosure. She scans GitHub for public repositories still pinned to vulnerable versions of [library], finds a fintech startup’s payment service, and crafts a malicious payload that exploits [specific mechanism]. Within minutes, the service executes arbitrary code in its production environment, and Vex begins exfiltrating API keys from environment variables.

Then add a horizontal rule (---) before the REFLEX Analysis heading.

5. REFLEX Analysis (six sections)

For each stage below, write 3–5 substantial paragraphs. Each section must include:

  • A bold subheading with the stage emoji and name
  • Concrete, CVE-specific content (not generic security advice)
  • At least one code example, configuration snippet, or command where relevant
  • A closing Developer insight: in italics — a single memorable sentence that captures the broader lesson
🔍 Reconnaissance

“From an attacker’s perspective:” How would attackers find systems vulnerable to this specific CVE? Cover: dependency scanning, error fingerprinting, public exposure signals, supply chain mapping. Be specific about what artifacts or behaviours reveal this vulnerability.

📊 Evaluate

“Vulnerability assessment:” What conditions must align for exploitation? Cover: the technical root cause, what makes a system exploitable vs. safe, how to check your own exposure, and why assessment is harder than it looks (transitive dependencies, bundled libraries, etc.). Include a code snippet showing the vulnerable pattern.

🛡️ Fortify

“Prevention and hardening:” What stops this vulnerability? Lead with “Upgrade to [version]” as mitigation #1. Then cover: temporary mitigations if upgrade is blocked, secure coding patterns, configuration hardening. Include a code example showing vulnerable vs. secure patterns (BAD / BETTER / BEST progression where appropriate).

⚡ Limit

“Damage containment:” How do you contain the blast radius if exploitation occurs? Cover: architectural patterns (network segmentation, least privilege, container isolation, micro-service boundaries), runtime containment measures. Include a configuration or infrastructure-as-code example (Kubernetes NetworkPolicy, IAM policy, etc.).

👁️ Expose

“Detection and visibility:” How do you detect exploitation attempts or successful compromise? Cover: specific log patterns, network indicators, behavioral anomalies, monitoring queries. Include grep/detection commands or monitoring rules that teams can actually deploy.

💪 Exercise

“Practice and preparedness:” How do you test your defences and build team readiness? Cover: safe simulation exercises, dependency audit drills, incident response scenarios. Include a team preparedness checklist (5–7 items as a bulleted list). End with realistic “what if” scenarios for tabletop exercises.

Add a horizontal rule (---) before each of these remaining sections.

6. Key Takeaways for Developers

  • Most important lesson: One sentence capturing the core security insight from this CVE
  • 🚨 CRITICAL: Upgrade to [safe version] immediately — restate the primary fix prominently
  • Immediate actions: 4–6 numbered, concrete steps (upgrade first, then audit, scan, harden, monitor, practice)
  • Long-term practices: 3–4 habits or process changes this CVE argues for
  • Related patterns: Link to 2–3 relevant Reflex battlecards using relative paths (e.g. ../battlecards/dependency-confusion-attacks.qmd). Choose battlecards that cover the same attack class or defence pattern.

7. References

  • CVE database entry (NVD link)
  • Vendor/project security advisory
  • Technical analysis or write-up
  • CISA advisory if one exists
  • Proof of concept (if public and appropriate to link)

Writing guidelines

  • Audience: Working developers and security-aware tech leads. Both should find value — don’t over-simplify for one or over-complicate for the other.
  • Tone: Direct, practical, educational. You’re teaching, not lecturing. Avoid security jargon where a plain description works better.
  • Specificity: Every section must be grounded in this specific CVE. Generic advice that applies to any vulnerability is filler — cut it or make it specific.
  • Code examples: These are central to the value, not optional. Show vulnerable patterns, secure alternatives, detection commands, and infrastructure configs. Use language-appropriate syntax highlighting.
  • Version clarity: The vulnerable version range and safe upgrade target must be unambiguous and appear in the Overview, Fortify section, and Key Takeaways. Repetition is intentional — this is the most actionable information.
  • Length: A complete analysis should be roughly 1500–2500 words. Each REFLEX stage section should be roughly balanced in depth, though Fortify and Expose may run slightly longer.
  • Cross-references: Link to specific Reflex battlecards and framework stages where they add context. Use relative paths from the cve-analysis/ directory: ../battlecards/filename.qmd for battlecards, ../stages/01-reconnaissance.qmd for stages.
  • Horizontal rules: Place --- before the REFLEX Analysis heading, before Key Takeaways, and before References. This matches the published page layout. ```

Usage

  1. Copy the prompt above
  2. Replace [CVE-YYYY-NNNN] with the target CVE identifier
  3. Optionally append context: vendor advisory URL, NVD link, PoC link, or any notes about HeroDevs NES availability
  4. Feed to Claude (or another capable LLM)
  5. Review the output — pay particular attention to version accuracy, HeroDevs callout correctness, and battlecard cross-references
  6. Save as cve-analysis/cve-yyyy-nnnn.qmd

What changed from v1

  • Added Scenario section — narrative hook matching the battlecard format, tuned to each CVE’s specific attack vector
  • Added QMD frontmatter template — outputs are now valid Quarto pages without manual fixup
  • Made code examples mandatory — each REFLEX stage must include at least one code/config snippet
  • Added research instructions — tells the LLM what to verify before writing, reducing hallucinated version numbers
  • Specified section depth — 3–5 paragraphs per stage, 1500–2500 words total, balanced across stages
  • Made cross-references concrete — specifies relative path format and requires 2–3 specific battlecard links
  • Strengthened writing guidelines — explicit guidance on audience, tone, and the “no generic advice” rule
  • Kept voice/tone separate — this prompt handles structure and content; apply voice/style guidelines as a separate pass