Security thinking
Start with assets and harm
Identify what a product must protect and describe the concrete harm that follows if confidentiality, integrity, or availability fails.
8 minute lesson
Security starts with what matters. A generic instruction like “make the app secure” gives us nothing we can test.
List the data, actions, services, money, and reputation the product depends on. Then describe what happens if someone reads, changes, destroys, or blocks each asset. This turns security from fear into a set of product requirements.
Imagine a shared notes app that stores private drafts and recovery email addresses. A leaked draft harms confidentiality, while an overwritten draft harms integrity.
A list that only says “user data” hides these differences. It can lead us to protect database secrecy while missing deletion, account lockout, or a broken restore.
Create an asset table for the notes app with owner, location, and believable harm. For each asset, show one observable failure: an unauthorized read, an unauthorized change, or an unavailable operation.
Lesson completed