SEC-101 Week 13: Capstone Scoping

Each student selects their CVE from the curated list, drafts an outline, and gets instructor sign-off before drafting begins.

Reading (~30 min)

Revisit the capstone CVE you identified as your top candidate during Week 12. Read the full NVD entry (nvd.nist.gov), the MITRE CVE record, and the vendor's original advisory. Identify at least one independent technical write-up (a security researcher's blog post, a conference talk slide deck, a Project Zero analysis, or a CERT advisory). These are your primary sources; you will cite all three in the final report.

Lecture outline (~1.5 hr)

Part 1: What the capstone asks you to do (20 min)

The capstone is not a summary of what other people wrote about a CVE. It is a reconstruction: your own explanation of what happened, why it worked, and what it meant, pitched at a "smart friend who is not a security professional."

The "educated non-specialist" level is specific. Your reader:

• Can follow a clear logical argument.
• Does not know what a CVSS base score is (you explain it).
• Does not know what a JNDI lookup is (you explain it with an analogy).
• Has read general-audience reporting about the breach but not the technical advisories.

The report is not pitched at your instructor. It is pitched at the reader who is going to be the audience of every security-professional communication you write in your career: the executive who approves the security budget, the developer who needs to understand why they should update a dependency, the journalist writing about a breach.

This is Bloom's L6 (Create): you produce an original artifact (the explanation) that synthesizes technical detail, historical context, disclosure process, and remediation guidance into a coherent narrative.

Part 2: The curated CVE list and selecting your topic (20 min)

The curated list of capstone CVEs:

Students may propose an alternative with instructor approval. The alternative must be of comparable scope (a broadly-affected CVE with a documented disclosure process and at least three independent technical write-ups).

How to choose:

• Choose the CVE whose technical mechanism you find most interesting, not the most famous one.
• Log4Shell and Heartbleed have the most public write-ups; EternalBlue and Spectre/Meltdown have the deepest technical rabbit holes.
• Dirty COW and ImageTragick are good choices for students interested in operating-system internals or image processing.
• If you've spent significant time on any OWASP Top 10 category in the labs, choose a CVE that belongs to that category. Depth of interest + familiar vocabulary = stronger report.

Part 3: Report structure and the outline workshop (30 min)

The report structure (from CAPSTONE.md):

Required sections:

1. What happened: a plain-English description of the vulnerability and the attack, written for the non-specialist audience. No jargon without explanation.

2. Why it worked: the technical root cause. This is the one section that requires genuine technical depth. The non-specialist reader should understand the mechanism well enough to understand why it wasn't caught earlier.

3. The timeline: from discovery (if known) through vendor notification, embargo, patch release, advisory publication, and mass exploitation (if applicable). Use dates, not relative terms ("two weeks later").

4. The disclosure handling: how well did the vendor, the researchers, and the community handle the disclosure? What did they do well? What would you recommend doing differently?

5. CVSS v3.1 score: score the CVE yourself using the FIRST.org calculator. Show each metric's value with one-sentence justification. Compare to NVD's score; if they differ, explain why.

6. "What would we do differently": 200-400 words. What should the vendor, the industry, or the broader ecosystem change to prevent the next vulnerability of this class?

Workshop (30 min): Draft your outline. For each section, write 2-3 bullet points identifying what you plan to cover. The instructor reviews and signs off on the outline before you begin drafting.

Part 4: Research workflow and source requirements (20 min)

Primary sources (all three required):

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

Secondary sources (optional, useful for context):

• General press coverage (useful for timeline and impact; not technically authoritative).
• Wikipedia (useful for initial orientation; not citable as a primary source).
• Academic papers or conference proceedings (if they exist for your CVE).

Citation format: Use any consistent format (IEEE, APA, or Chicago are all acceptable). Include the URL and the date you accessed each source. Web resources change; record the access date.

Plagiarism: The capstone is graded on originality of analysis, not originality of facts. You can and should describe the same facts as your sources, but in your own words and with your own explanation. Copying a paragraph from a blog post, even with attribution, fails the "educator non-specialist" requirement: the blog post was not written for your reader.

Independent practice (~9 hr)

This week has more independent practice time than usual because the capstone research begins now.

• CVE research (4 hr): Read all your primary sources thoroughly. Take notes in your lab notebook: what are the key technical facts? What is the timeline? What sources conflict with each other? Where are the gaps in the public record?
• CVSS scoring (1 hr): Use the FIRST.org calculator to score your CVE. Work through each metric. Compare your result to NVD's score; note any differences.
• Outline completion (1 hr): Turn your workshop bullet points into a full section outline with source citations attached to each point.
• picoCTF spine (2 hr): Student choice this week. Work on challenges you've been saving, or push into a new category. Document your approach.
• Reflection (1 hr): Write the prompts below.

Reflection prompts

1. Your capstone CVE was disclosed at a specific moment in time. Security research at the time knew what they knew in that year. What contextual knowledge (about a protocol, a hardware architecture, a software dependency) did the security community have that made this vulnerability discoverable? What would have needed to change for this vulnerability to have been found and fixed earlier?

2. The "educated non-specialist" audience requirement is about translation, not simplification. You are not dumbing down the technical content; you are explaining it with enough context that the reader can follow the reasoning. What analogies or comparisons will you use in your capstone report to explain the core technical mechanism? Write one paragraph draft.

3. The "what would we do differently" reflection is prospective: it looks forward. Given what you now know about your chosen CVE, what would you recommend as a preventive control that would have stopped this class of vulnerability before it appeared? Be specific about where in the software development lifecycle or security program the control belongs.

Week 13 of 14. Next: Capstone delivery (Lab 9 due; course close; forward pointers).