Week 1, Lecture 2 — Why Secure Programming Matters

Module: COMP09031 — Cybersecurity & Secure Programming

Slot: W1 L2 Content budget: 35 min Embedded interlude: 5 min OWASP Top 10 movement Anchors: TalkTalk 2015, BA 2018, MOVEit 2023 Book chapter: 2

Before the lecture

Read Chapter 2 — Week 1, Lecture 2: Why Secure Programming Matters in the book PDF (approximately 14 pages, 30 minutes reading time). The chapter’s spine is three real breaches — TalkTalk 2015, British Airways 2018, MOVEit 2023 — and the bug-to-breach pipeline they share. The 28–35 min block on AI coding assistants is the set piece students will remember most.

Slides

Lecture timing

A 50-minute slot is realistically 45–50 minutes of room time. 35 min of content + 5 min embedded interlude + 5–10 min slack for arrivals, transitions, and Q&A.

Block Time Notes
TalkTalk and the bug-to-breach pipeline 0–10 min Walk the diagram explicitly; same shape returns in Ch 4 (Threat Modelling) and Ch 17 (Web Application Security)
The numbers, briefly 10–15 min Verizon DBIR + IBM cost-of-breach headline. Skim; do not read footnotes
Embedded interlude — live OWASP Top 10 movement 15–20 min See the script below
Why good developers write insecure code 20–28 min Acar 2016 + Perry 2023 are the heart of the lecture; spend time here
AI coding assistants 28–35 min Pearce 40% / Perry “more confident, less secure” / Veracode 45% — the most important slide
Trustworthy Computing & Heartbleed 35–40 min “Cultural change is possible” — that is the line

If you run short, drop the cost-of-fix curve discussion — the chapter covers it in more detail than the lecture needs.

Embedded interlude — live OWASP Top 10 movement (~5 min)

URL. https://owasp.org/Top10/

Setup. “Open this URL on your laptop. We’ll spend five minutes here — close everything else.”

Activity.

  1. Have students click into A03:2021 — Injection.
  2. Read its current rank aloud, then ask: “Anyone know where this category sat in the previous edition?”
  3. Reveal: Injection was A01 from 2010 through 2017, dropped to A03 in 2021.
  4. Click into A01:2021 — Broken Access Control and point at the new top of the list.

Talking points.

  • Why Injection was demoted — parameterised queries became framework defaults; ORMs do the work.
  • Why Broken Access Control rose — authorisation bugs are now the dominant class. Capital One 2019 SSRF, the Optus 2022 unauth API, the IDOR/BOLA family.
  • The Top 10 is a moving picture, not a fixed canon. Read it as “where the bug-class energy is going”.
  • Forward-point to Chapter 17 (W6 L2) where Broken Access Control depth lives.

Expected student response. Surprise that “the classic” got demoted. Some students will conflate Injection with SQL injection specifically — the OWASP category is broader (XSS, command injection, NoSQL, etc.).

Wrap. “Read the Top 10 every year when it updates. The categories tell you where the industry’s eyes are. Now back to why developers keep writing the bugs in the first place.”

Tip

Pre-lecture link check. Two minutes before class, click each link below and confirm it loads. OWASP occasionally restructures its URLs; better to know now than to fumble live.

Common student questions (and short answers)

  • “Why do these bugs keep shipping if everyone knows about them?” — Three reasons. (1) Knowledge is unevenly distributed; the developer who shipped the bug had not read the OWASP Top 10. (2) Time pressure; the team had a deadline and the security team had no veto. (3) Inherited code; nobody alive remembered the legacy webpages TalkTalk inherited from Tiscali. The honest answer is “people, not technology”, which is why this module spends as much time on culture as on code.
  • “Should I just stop using Copilot then?” — No. The Perry data shows that the bad outcome correlates with uncritical use, not with use itself. Healthy scepticism, prompt iteration, reading the output critically — these are the behaviours that work. Treat the assistant as a junior pair, not as an oracle.
  • “The cost-of-fix numbers seem suspicious.” — They are. The Bossavit / Register critique is real; the original Boehm 1981 study is solid but smaller in scope, and the IBM Systems Sciences Institute citation that everyone repeats is not traceable to a primary source. Ranges, not point estimates. The general direction is right — fixing late costs more than fixing early — but be sceptical of any clean 100× number.

End-of-lecture self-check

Optional, formative — not graded. Click an option to see immediate feedback.

Going Further

  • Pearce, Hammond et al. Asleep at the Keyboard? IEEE S&P 2022. — The original alarm about LLM-generated code. The methodology is straightforward; read it before you read any popular-press piece on AI and security.
  • Perry, Neil et al. Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023. — The user-study companion to Pearce. The “more confident, less secure” finding is the one that matters most for working developers.
  • Bossavit, Laurent. The Leprechauns of Software Engineering (2015), Chapter 10. — Historical detective work on the cost-of-fix curve. Worth reading in full if you ever cite the 100× number.
  • Howard, Michael, and David LeBlanc. Writing Secure Code, 2nd ed. (Microsoft Press, 2003). — The book the Trustworthy Computing pause produced. Twenty years on, much of it still lands.