SEC-101 Capstone Specification: Historical CVE Explainer Report

The SEC-101 capstone is a written reconstruction of a significant historical vulnerability. The student selects a CVE from an instructor-curated list, researches the technical mechanism and disclosure history, and produces a 5-8 page report pitched at the "educated non-specialist" level.

What you ship

A Git repository containing:

1. report.md: The 5-8 page report (see Required Sections below).
2. timeline-diagram.png (or .svg): A visual timeline of the disclosure process (discovery through mass exploitation if applicable).
3. At least 3 commits in the Git history: the first commit should be your research notes or outline; subsequent commits show incremental drafting.

Repository naming: sec101-capstone-[your-name] (lowercase, hyphens, no spaces). Example: sec101-capstone-alex-jones.

CVE selection

Choose one from the curated list below. Get instructor sign-off on your outline in the Week 13 workshop before drafting.

An alternative CVE may be proposed with instructor approval. Requirements: widely deployed affected software, documented CVD process, at least three independent technical write-ups.

Required report sections

Section 1: What happened (500-700 words)

Plain-English narrative for the educated non-specialist. Assume your reader has seen general-audience coverage but has not read a security advisory. Cover:

• What software or system was vulnerable.
• What an attacker could do by exploiting the vulnerability.
• Who was affected and at what scale.
• When it was discovered and when the public learned about it.

Define every technical term the first time you use it.

Section 2: Why it worked (600-900 words)

The technical root cause. Must be technically accurate; must remain accessible to the stated audience.

Cover:

• The specific code or design failure that created the vulnerability.
• The mechanism of exploitation: what an attacker actually does.
• Why the vulnerability was not caught earlier.

Analogies are encouraged where they aid understanding, provided they are labeled as analogies and their limits are noted.

Section 3: The timeline (300-400 words)

Chronological, with specific dates. Include: discovery, vendor notification, embargo period, CVE assignment, patch release, advisory publication, mass exploitation (if documented).

Section 4: Disclosure handling (300-400 words)

Evaluate the CVD process the vulnerability followed:

• Did the vendor respond appropriately?
• Was the embargo period reasonable?
• Was the public notified clearly and promptly?
• What did the process do well? What would you recommend differently?

Section 5: CVSS v3.1 scoring (200-300 words)

Score the CVE yourself using the FIRST.org CVSS v3.1 calculator (first.org/cvss/calculator/3.1). Show each of the eight base metric values with a one-sentence justification. Compare your score to the NVD-assigned score. If they differ, explain why.

Section 6: What would we do differently (200-400 words)

Prospective reflection: what specific change would prevent the next vulnerability of this class?

This is not "they should have tested more." It is a specific change: a secure coding practice, a language feature, a development-process change (fuzzing, formal verification, mandatory dependency scanning), or an industry-wide change (SBOMs, secure defaults, CVD frameworks). Name the specific mechanism and explain why it would have helped.

Primary sources (all three required)

1. The original CVE record (NVD or MITRE).
2. The vendor's security advisory.
3. An independent technical write-up (Project Zero blog, researcher's post, conference talk, CERT advisory).

Use any consistent citation format. Include URL and access date.

Two-tier grading rubric

Tier 1: Pass/fail gate

The report covers a real CVE from the curated list (or approved alternative) with technical accuracy. Reports with material technical errors -- incorrect description of the mechanism, wrong date attribution, factually inaccurate CVSS scoring -- do not advance to Tier 2 scoring. Plagiarized content (paragraph-level copying, even with attribution) is grounds for course failure.

Tier 2: Scored dimensions

There is no curve. There is no participation credit.

What the capstone does NOT require

• Reproducing the exploit (that is PEN-101 and ADV-101).
• Source code analysis or binary reversing of the vulnerable component.
• Access to the original vulnerable software.
• Novel research: the public record is sufficient.
• A specific citation format (any consistent format is accepted).

Submission

Push your repository to GitHub or GitLab and email the URL to interested@virtuscyberacademy.org with subject SEC-101 capstone, [your name]. The course team replies within 7 days with the grade and brief feedback.

Forward pointers

The capstone is deliberately structured as the precursor to:

• PEN-101: The engagement report format from PEN-101 uses the same audience-appropriate clarity discipline established here.
• RE-101: The CVE record reading and timeline reconstruction skills transfer directly to the SB6141 vulnerability research workflow.
• ADV-101 and ADV-102: Both courses begin with a CVE record and end with a reproduction. SEC-101's capstone is the read-and-explain step; ADV-101/102 adds the reproduce-and-detect steps.

Capstone specification v0.1.