55AA-002 · This is the first lecture in Software Security. It does not jump directly into exploitation; it establishes the vocabulary of defects, vulnerabilities, exploits, risk, assets, attack surfaces, and trust boundaries.

Back to course

Vulnerability Models and Secure Engineering Workflow

This is the first lecture in Software Security. It does not jump directly into exploitation; it establishes the vocabulary of defects, vulnerabilities, exploits, risk, assets, attack surfaces, and trust boundaries.

Learning Objectives

  • Distinguish bug, vulnerability, exploit, and risk with security-specific examples.
  • Describe the attack surface of a small software system using assets, entry points, trust boundaries, and attacker capabilities.
  • Extract root cause, impact, remediation strategy, and regression-test needs from a vulnerability advisory.
  • Explain why software security must enter requirements, design, implementation, testing, and release workflows.

Prerequisites

  • Quality attributes from software engineering.
  • Basic concepts of HTTP requests, input validation, backend services, and databases.
  • Basic use of Git, issues, pull requests, and tests.

Preparation

  • Pre-class reading: read one short CVE advisory and mark the affected component, attack preconditions, and fixed version.
  • Pre-class prompt: is a crash bug always a security vulnerability?
  • Environment: browser, text editor, and access to the sample advisory in the course repository.

Class Flow

0-8
Review: quality attributes in software engineering

Open with reliability, maintainability, and security; ask students what each quality attribute protects.

review
Question

If an input-validation bug only crashes the program, is it always a security vulnerability?

Expected answer: Not necessarily. It depends on attacker reachability, whether the crash affects a security goal, and whether it enables further exploitation.

Follow-up: What if it is an authentication service? What if it restarts automatically but loses in-memory session state?

Script

Opening

This is the first lecture in Software Security. We will not start by writing exploits or chasing spectacular attacks. The most common mistake in a security course is treating vulnerabilities as mysterious tricks. We will do the opposite: a vulnerability is first an engineering defect, with the special property that an attacker can use it.

Demo / Exercise

From advisory to engineering tasks

Open the sample advisory.

Slides
Open slides placeholder
Slide 1Today's Question
Slide 2Four Words
Slide 3Five Questions for Vulnerability Judgment
Video Media
Video placeholder link

Bug, Vulnerability, Exploit, and Risk

8-18
Diagnostic question: does crash imply vulnerability?

Give three scenarios: local CLI crash, public API crash, and authentication service crash. Ask whether the risk is the same.

diagnostic
Question

If an input-validation bug only crashes the program, is it always a security vulnerability?

Expected answer: Not necessarily. It depends on attacker reachability, whether the crash affects a security goal, and whether it enables further exploitation.

Follow-up: What if it is an authentication service? What if it restarts automatically but loses in-memory session state?

Script

Review

From software engineering, you have seen quality attributes. Reliability asks whether a system keeps working under normal and abnormal conditions. Maintainability asks whether future engineers can understand and change it. Security adds an active adversary. So here is the first question: when is a crash merely a reliability problem, and when is it a security problem?

Demo / Exercise

From advisory to engineering tasks

Assume the system lets users upload avatars. List at least 4 assets, 3 entry points, 3 trust boundaries, and 3 security tests.

Slides
Open slides placeholder
Slide 2Four Words
Slide 3Five Questions for Vulnerability Judgment
Slide 4Advisory Reading Checklist
Video Media
Video placeholder link

Bug, Vulnerability, Exploit, and Risk

18-34
Bug, vulnerability, exploit, and risk

Build the hierarchy: implementation defect, attacker exploitability, exploitation path, and asset impact plus likelihood.

concept
Question

In an advisory, is the CVSS score more important than root cause and attack preconditions?

Expected answer: CVSS helps prioritization, but engineering remediation depends more on root cause, preconditions, affected versions, and regression-test conditions.

Follow-up: If the score is high but the product does not expose the relevant entry point, how should priority change?

Script

Guided question

Consider three cases: a local CLI crashes on a malformed file; a public API crashes on a special request; an authentication service crashes and no one can log in. All three are crashes. Do they carry the same security meaning? Do not answer only yes or no. Ask whether the attacker can trigger it, how costly it is, which asset is affected, and whether it enables further exploitation.

Demo / Exercise

From advisory to engineering tasks

Open the sample advisory.

Slides
Open slides placeholder
Slide 3Five Questions for Vulnerability Judgment
Slide 4Advisory Reading Checklist
Slide 5From Risk to Engineering Tasks
Video Media
Video placeholder link

Bug, Vulnerability, Exploit, and Risk

34-48
Advisory dissection

Read a short advisory together and mark affected versions, root cause, impact, fixed versions, workaround, and regression test.

case
Question

In an advisory, is the CVSS score more important than root cause and attack preconditions?

Expected answer: CVSS helps prioritization, but engineering remediation depends more on root cause, preconditions, affected versions, and regression-test conditions.

Follow-up: If the score is high but the product does not expose the relevant entry point, how should priority change?

Script

Concept

Separate four words. A bug is an implementation defect. A vulnerability is an attacker-exploitable defect. An exploit is the path or program that exercises it. Risk combines asset impact and likelihood. Not every bug is a vulnerability; not every vulnerability has a stable exploit; and not every exploit carries the same business risk.

Demo / Exercise

From advisory to engineering tasks

Assume the system lets users upload avatars. List at least 4 assets, 3 entry points, 3 trust boundaries, and 3 security tests.

Slides
Open slides placeholder
Slide 4Advisory Reading Checklist
Slide 5From Risk to Engineering Tasks
Video Media
Video placeholder link

How to Read a Vulnerability Advisory

48-63
Assets, entry points, trust boundaries, and attack surface

Draw a login service data flow and mark trust boundaries among browser, API, database, dependencies, and admin console.

concept
Question

Are trust boundaries and module boundaries the same thing?

Expected answer: No. Module boundaries organize code; trust boundaries separate authority, identity, control, or data trustworthiness.

Follow-up: Can one module cross a trust boundary? Is every microservice boundary necessarily a trust boundary?

Script

Transition

Now we read an advisory. Do not read only the title and score. Extract six things: affected versions, attack preconditions, root cause, impact, fixed versions, and regression tests. In security engineering, your deliverable is not a forwarded link; it is a set of engineering actions.

Demo / Exercise

From advisory to engineering tasks

Open the sample advisory.

Slides
Open slides placeholder
Slide 5From Risk to Engineering Tasks
Video Media
Video placeholder link

How to Read a Vulnerability Advisory

63-75
In-class exercise: model an upload endpoint

Students work in pairs and list assets, entry points, attacker capabilities, and the three most likely risks.

exercise
Question

Are trust boundaries and module boundaries the same thing?

Expected answer: No. Module boundaries organize code; trust boundaries separate authority, identity, control, or data trustworthiness.

Follow-up: Can one module cross a trust boundary? Is every microservice boundary necessarily a trust boundary?

Script

Summary

The core sentence today is: a vulnerability is an attacker-exploitable engineering defect. To judge whether something is a security issue, inspect the attacker, entry point, trust boundary, asset, and impact. Next class turns this method into a workshop: advisory analysis that becomes issues, tests, and a remediation plan.

Demo / Exercise

From advisory to engineering tasks

Assume the system lets users upload avatars. List at least 4 assets, 3 entry points, 3 trust boundaries, and 3 security tests.

Slides
Open slides placeholder
Slide 6From Risk to Engineering Tasks
Video Media
Video placeholder link

How to Read a Vulnerability Advisory

75-84
Putting security into the engineering workflow

Turn the risks into issues, tests, code-review checks, and release gates.

discussion
Question

Are trust boundaries and module boundaries the same thing?

Expected answer: No. Module boundaries organize code; trust boundaries separate authority, identity, control, or data trustworthiness.

Follow-up: Can one module cross a trust boundary? Is every microservice boundary necessarily a trust boundary?

Script

Summary

The core sentence today is: a vulnerability is an attacker-exploitable engineering defect. To judge whether something is a security issue, inspect the attacker, entry point, trust boundary, asset, and impact. Next class turns this method into a workshop: advisory analysis that becomes issues, tests, and a remediation plan.

Demo / Exercise

From advisory to engineering tasks

Open the sample advisory.

Slides
Open slides placeholder
Slide 7From Risk to Engineering Tasks
Video Media
Video placeholder link

How to Read a Vulnerability Advisory

84-90
Summary and hook for next class

Summarize the core sentence: a vulnerability is an attacker-exploitable engineering defect. Next class applies this method in an advisory-analysis workshop.

summary
Question

Are trust boundaries and module boundaries the same thing?

Expected answer: No. Module boundaries organize code; trust boundaries separate authority, identity, control, or data trustworthiness.

Follow-up: Can one module cross a trust boundary? Is every microservice boundary necessarily a trust boundary?

Script

Summary

The core sentence today is: a vulnerability is an attacker-exploitable engineering defect. To judge whether something is a security issue, inspect the attacker, entry point, trust boundary, asset, and impact. Next class turns this method into a workshop: advisory analysis that becomes issues, tests, and a remediation plan.

Demo / Exercise

From advisory to engineering tasks

Assume the system lets users upload avatars. List at least 4 assets, 3 entry points, 3 trust boundaries, and 3 security tests.

Slides
Open slides placeholder
Slide 8From Risk to Engineering Tasks
Video Media
Video placeholder link

How to Read a Vulnerability Advisory

Homework

Choose a public CVE advisory and submit a one-page analysis: assets, attacker capabilities, root cause, impact, remediation strategy, and regression-test recommendation.