Cybersecurity & Data Protection

A Kaern Schools course for founders building real companies.

Tutor: Ada

Welcome — read this first

Hi, I'm Ada. I've spent years keeping the lights on for small teams shipping fast: a Shopify storefront here, a fleet of connected machines reporting telemetry there, a tangle of Cloudflare Workers and KV stores holding it all together. I've watched a founder paste an API key into a public Slack channel "just to test something." I've watched a leaked admin token drain a Stripe balance over a weekend. I've also watched founders who took two afternoons to threat-model their product sleep soundly through their first security scare.

This course is built from that real cycleX practice — the same stack many Kaern startups run on: Cloudflare Workers and KV, Shopify, connected machines and IoT endpoints, and the eternal headache of secrets management. Everything here is something I've actually had to do or clean up.

Who this is for

You're a founder. You write some code, or you manage people who do. You don't have a security team — you are the security team, between two other jobs. You don't need a CISSP. You need to make good decisions under uncertainty, fast, and know which corners are safe to cut.

What you'll be able to do by the end

• Threat-model any feature in 30 minutes and know where your real risks live.
• Build authentication and authorization that won't embarrass you, and handle secrets so a leak doesn't end your company.
• Recognize and prevent the OWASP Top 10 in your own web and API code.
• Apply privacy by design and meet your GDPR-style obligations without a lawyer on retainer.
• Secure connected devices and cloud infrastructure — the messy edge where most real breaches happen.
• Have a written incident response plan, working backups, and the resilience to survive a bad day.

How we work

Every module has teaching scripts (me, talking, the way I would in the room), a worked example from real practice, a hands-on exercise you do on your own product, common mistakes I see constantly, and quick checks so you know it stuck. We end with a capstone: a real security review of your own startup.

Pour a coffee. Let's make you hard to hack.

Module 1 — Threat Modeling & the Security Mindset

Learning objectives

1. Adopt an attacker's mindset: reason about who would attack you and why.
2. Map your system's assets, entry points, and trust boundaries.
3. Apply a lightweight threat-modeling method (STRIDE) to a real feature.
4. Prioritize threats by likelihood and impact instead of fear.
5. Decide deliberately which risks to fix, accept, or transfer.

Lesson 1.1 — Thinking like an attacker

Teaching script

Let me start with a confession: security is not about building walls. It's about understanding the people who want to climb them. When I look at your product, I don't see features — I see doors. Every input field, every API endpoint, every machine phoning home is a door someone might try.

Here's the mindset shift. As founders, you ask, "How does this work?" An attacker asks, "How does this break, and what do I get when it does?" Those are different questions, and you need to learn to hold both in your head.

Think of your startup like a corner shop. You lock the front door, sure. But what about the delivery hatch round the back? The window above the sink? The spare key under the mat that "everyone" knows about? Attackers don't queue at the front door. They walk the perimeter looking for the easy way in — and in software, the easy way in is almost always the door you forgot you built.

The good news: you don't need to be paranoid about everything. You need to be paranoid about the right things. Most attackers are opportunistic and lazy. They want the cheapest win. If you're not the cheapest win on the block, they move on.

So before we touch a single line of code: who would want to break into your startup, and what would they take?

Lesson 1.2 — STRIDE and trust boundaries

Teaching script

Now that you're thinking like an attacker, let's give that instinct some structure, because "imagine bad things" doesn't scale. I use a checklist called STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Six categories of "what could go wrong." For any feature, walk each letter and ask, "Could someone do this here?"

The other half of the picture is trust boundaries — the lines in your system where data crosses from somewhere you control to somewhere you don't, or vice versa. Your browser talking to your Cloudflare Worker: that's a boundary. Your Worker reading from KV: probably trusted. Your machine in a customer's basement sending telemetry to your cloud: a huge boundary, because you don't control that basement.

Draw your system as boxes and arrows. Every arrow that crosses a trust boundary is where you scrutinize hardest. Data coming across a boundary is guilty until proven innocent — validate it, authenticate it, never assume it's well-behaved.

The magic of STRIDE plus boundaries is that it turns a vague dread into a finite list. A finite list you can work through. A finite list you can prioritize.

So here's my question to you: where exactly does data cross from "I control this" to "I don't" in your product?

Worked example

A Kaern startup runs a Shopify store with a Cloudflare Worker that handles a "request a quote" form. We model it:

• Assets: customer contact details, the Shopify Admin API token the Worker uses.
• Entry points / boundaries: browser → Worker (untrusted input), Worker → Shopify API (trusted but token-protected), Worker → KV (trusted).
• STRIDE on the form endpoint:
• Spoofing: anyone can POST to the Worker — no auth on a public form (acceptable, but rate-limit it).
• Tampering: hidden form fields could be altered — never trust price from the client.
• Information disclosure: the Worker logs the full request, including emails, to a public log drain. Risk found.
• Denial of service: a bot could flood the form and burn through Shopify API rate limits.
• Priority: the log leak (high impact, easy to exploit) gets fixed today; DoS gets a rate limiter this week.

Hands-on exercise

Take one real feature of your startup. On paper or a whiteboard:

1. List its assets (what's worth stealing or breaking).
2. Draw boxes and arrows; mark every trust boundary in red.
3. Run STRIDE across the most exposed entry point — one threat per letter, even if it's "not applicable."
4. Score each threat: likelihood (low/med/high) × impact (low/med/high).
5. Write a one-line decision for each: fix now, fix later, accept, or transfer (e.g., to insurance or a provider).

Bring your top three "fix now" items to the next module.

Common mistakes

1. Modeling the happy path only. You diagram how it should work and call it done. Attackers live in the unhappy paths — model those.
2. Treating every threat as equal. Founders either ignore everything or panic about everything. Score by likelihood × impact and triage.
3. Forgetting the boring boundaries. The flashy login page gets attention; the forgotten internal admin endpoint with no auth is what actually gets you.

Check for understanding

1. What does each letter of STRIDE stand for, and give one example threat per letter for a login form.
2. Why is data crossing a trust boundary treated as "guilty until proven innocent"?
3. You find ten threats. You have time to fix three. How do you choose which three?