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-8Review: quality attributes in software engineeringOpen with reliability, maintainability, and security; ask students what each quality attribute protects.
review
Open with reliability, maintainability, and security; ask students what each quality attribute protects.
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?
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.
From advisory to engineering tasks
Open the sample advisory.
Bug, Vulnerability, Exploit, and Risk
8-18Diagnostic 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
Give three scenarios: local CLI crash, public API crash, and authentication service crash. Ask whether the risk is the same.
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?
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?
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.
Bug, Vulnerability, Exploit, and Risk
18-34Bug, vulnerability, exploit, and riskBuild the hierarchy: implementation defect, attacker exploitability, exploitation path, and asset impact plus likelihood.
concept
Build the hierarchy: implementation defect, attacker exploitability, exploitation path, and asset impact plus likelihood.
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?
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.
From advisory to engineering tasks
Open the sample advisory.
Bug, Vulnerability, Exploit, and Risk
34-48Advisory dissectionRead a short advisory together and mark affected versions, root cause, impact, fixed versions, workaround, and regression test.
case
Read a short advisory together and mark affected versions, root cause, impact, fixed versions, workaround, and regression test.
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?
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.
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.
How to Read a Vulnerability Advisory
48-63Assets, entry points, trust boundaries, and attack surfaceDraw a login service data flow and mark trust boundaries among browser, API, database, dependencies, and admin console.
concept
Draw a login service data flow and mark trust boundaries among browser, API, database, dependencies, and admin console.
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?
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.
From advisory to engineering tasks
Open the sample advisory.
How to Read a Vulnerability Advisory
63-75In-class exercise: model an upload endpointStudents work in pairs and list assets, entry points, attacker capabilities, and the three most likely risks.
exercise
Students work in pairs and list assets, entry points, attacker capabilities, and the three most likely risks.
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?
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.
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.
How to Read a Vulnerability Advisory
75-84Putting security into the engineering workflowTurn the risks into issues, tests, code-review checks, and release gates.
discussion
Turn the risks into issues, tests, code-review checks, and release gates.
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?
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.
From advisory to engineering tasks
Open the sample advisory.
How to Read a Vulnerability Advisory
84-90Summary and hook for next classSummarize the core sentence: a vulnerability is an attacker-exploitable engineering defect. Next class applies this method in an advisory-analysis workshop.
summary
Summarize the core sentence: a vulnerability is an attacker-exploitable engineering defect. Next class applies this method in an advisory-analysis workshop.
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?
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.
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.
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.