In this lesson you'll build a threat awareness foundation. This will be your first look at security.

---

Modelling Security

The moment you ship something real, you become a target. Not necessarily because anyone has a personal vendetta against you, but because the internet is full of automated tools and patient humans looking for unprotected apps, leaked keys, and careless developers.

A breach can leak your users' data, drain accounts, hijack your domain, or end your project entirely. If you're building anything that touches money, like a crypto app or a payments integration, the stakes go up dramatically. State-backed groups like DPRK have stolen over $3 billion from crypto projects alone.

This lesson covers the three things every vibecoder needs before writing a line of production code:

1. How to think about threats
2. How to recognize social engineering
3. How to avoid getting compromised by something you click or install.

---

Part 1: Threat Modeling for Vibecoders

Threat modeling is the practice of imagining how you get hurt, before you get hurt. It is the cheapest security tool you have:

The four-question framework

A threat model is a short document that answers four questions:

1. What are we building, and what are my crown jewels? A one-paragraph description of your app, including what users do with it and what valuable thing it touches (funds, identity, data, reputation).
2. What can go wrong? A list of specific bad outcomes. Not "we get hacked." Something like "an attacker drains the treasury multisig" or "a phishing site impersonates our domain and steals user funds."
3. What are we doing about it? For each bad outcome, the controls you have in place.
4. Did we do a good job? A way to check whether your controls actually work.

Who actually attacks you

Most beginners imagine the attacker as a faceless hacker in a hoodie. The real picture is more useful:

Opportunistic scammers run sweepers, fake airdrops, malicious extensions, and Google ads that look like the real product. They cast a wide net and catch whoever is careless.

Script kiddies are not looking for you. They pick one kind of bug that shows up in hundreds of projects (a vulnerability class), then run it against every contract or endpoint they can reach. The modern version points an AI agent at the problem instead of writing the exploit by hand, which makes the net much wider. If your code has that bug, they find it whether or not anyone has heard of your project.

Targeted phishers show up once your project gains traction. They impersonate your team, register lookalike domains, and run ads on the real URL that redirects elsewhere.

Supply chain attackers compromise a popular npm package, a VS Code extension, or a developer's GitHub account. You install it, you run it, and they are now inside your build pipeline.

Financially motivated crews are organized businesses, not individuals. Ransomware, extortion, and large-scale theft, with the proceeds reinvested into better tooling. These are the groups you see named in the news after an exchange loses nine figures.

State-level actors run multi-month operations, fake job interviews, and elaborate social engineering campaigns.

---

Reading the names in security reports

Companies that track attackers for a living give these groups code names instead of describing them, and each company uses its own naming system.

APT (Advanced Persistent Threat) means a state-sponsored group attributed to a government with high confidence. FIN means a financially motivated criminal group. UNC means uncategorized. Researchers have seen a set of related break-ins and are fairly sure it's one group, but they don't yet know who it is or what they want. Once they figure that out, the UNC label gets replaced with an APT or a FIN name.

Google and Microsoft have both introduced new naming systems recently, so the same group often appears under several different names. The links below are the current references.

Further reading: Google's threat actor naming system · Microsoft's naming taxonomy and full actor list

A worked example

Say you're building a SaaS app where users sign up, store their data, and pay you a subscription. Here's what a real threat model looks like:

What can go wrong:

• An attacker dumps the user database through a SQL injection bug
• An attacker compromises our domain and serves a malicious version of the site
• A team member's admin account gets phished and they delete production data
• A malicious npm package in our build pipeline injects code that steals user sessions
• Our database password is committed to a .env file in a public repo

What we're doing about it:

Threat	Control
SQL injection / data leak	Use an ORM (a library that handles database queries safely), require code review before merging
Domain compromise	Use Cloudflare with registry lock (a setting that prevents anyone from transferring your domain), enforce hardware MFA on the registrar account
Phished admin account	Hardware MFA (a physical key you plug in to log in, like a YubiKey), keep admin accounts separate from daily-use accounts
Supply chain attack	Run Socket.dev on every PR (it scans dependencies for known malicious packages), lock dependency versions so updates don't sneak in
Leaked secrets	Use a secrets manager like 1Password or AWS Secrets Manager, never put keys in .env files committed to a repo

Each of these tools and concepts gets covered in detail in later lessons. The point right now is to see how a threat model works: list the bad outcomes, then list what stops each one.

If you're building something that touches user funds (a crypto app, a marketplace, a payment integration), add things like multisig wallets and audits to the list. The stakes determine the controls.

The cheat code: match the security to the stakes. If the worst outcome is "a user has a bad experience," your bar is low. If it's "we lose all our users' data or money," your bar is much higher.

---

Part 2: Social Engineering and Phishing Defense

Phishing is when someone pretends to be a person or company you trust in order to get you to hand over a password, a key, or access to something.

Most hacks do not start with code. They start with a message.

Why you'll mess up

Even smart, technical people get phished. Four mental traps make it possible:

• Overconfidence. You think you can spot a fake. The attacker knows you think that.
• Confirmation bias. A warning from your CEO is expected and normal, so you don't double-check.
• You're tilted. You're tired, distracted, or in a rush. Your guard is down.
• Urgency and authority. "Quick, sign this before the deal closes." "The CEO needs this now."

Most successful phishes exploit at least one of these.

Trojan horse phishing

Here's a real attack pattern. An attacker sends you an obviously fake email from a typo-squatted domain like ross@gooogle.com. You spot it instantly. "Wow, that was easy. We're doing great."

Then they send a second email, this time from a much better fake like ross@google.co. The email looks like it's from your CEO, warning you about phishing and including a "helpful" anti-phishing PDF guide.

That PDF is malware.

This works because the first email made you feel safe. You let your guard down on the second. The "warning from leadership" matched what you'd expect to receive. You opened the file.

Impersonations and meeting phishing

Two patterns to watch for:

Account takeovers. Someone you actually know gets their Telegram or Discord account compromised. The attacker now has your friend's history, photos, and tone. They DM you a Calendly link.

Platform ambiguity. Telegram lets people set their display name and bio to anything. A profile that shows "Keone" with a verified-looking checkmark in the name is not actually verified. The blue circle next to the name might just be an emoji they typed.

Fake meetings. You join a Zoom call, see your colleague's face, hear their voice, and a popup says "audio devices not recognized correctly, click Repair." That repair link installs malware. Voice and video are trivial to fake in 2026.

The rule

Confirm any unsolicited or unusual communication out-of-band.

If you get a Telegram message asking you to sign something, call the person. If your CEO emails you with an urgent request, ping them on Slack. If a meeting feels off, leave and reschedule.

The attackers are betting you won't take the extra 30 seconds. Take the 30 seconds.

---

Part 3: Malicious Files, Ads, and Extensions

Files

The rules are simple:

• Unsolicited files: never open, download, or interact with them. Even if they look like a resume, a deck, or a contract.
• Expected files: request a Drive link instead. A shared Google Drive link is far safer than a downloaded .docx or .pdf.
• Anything ending in .exe, .dmg, .scr, .app, or .zip from an unknown source is suspect by default.

If someone insists you must download and run a file to interview, demo, or "verify" something, you are being phished. Real companies do not work this way.

Ads

Two rules that will save you a lot of money:

Never click sponsored links from a Google search for a crypto product. Scammers regularly run ads that display the correct URL but redirect to a drainer.

Never click unsolicited links on X, Telegram, or Discord. This is true even if the link comes from a "verified" account. Verification can be bought, accounts can be hijacked, and DMs can come from impostors.

Browser and editor extensions

Extensions run with massive privileges. A malicious extension can read every page you visit, including your wallet popups.

• Don't trust extensions, verify them. Check the publisher, the install count history, and recent reviews.
• A trusted developer name is not enough. Attackers publish lookalike extensions with similar names and logos, then pay for bot installs so the fake outranks the real one in search. In 2025 a fake Solidity extension on Open VSX reached nearly two million installs this way, and one developer who installed it lost around $500,000 in crypto.
• Less is more. Every extension you install expands your attack surface. Audit your installed extensions every few months and uninstall anything you don't actively use.

For VS Code specifically: a recent supply chain attack hijacked real developer accounts on Open VSX and pushed malware through legitimate extensions. 22,000 installs happened before removal. Even "trusted" can change.

---

Action items

1. Threat model: Open a Notion doc, write one paragraph about your project, and list 5 specific bad outcomes. Do this today.
2. Phishing test: The next time you get an "urgent" message from a teammate, pause and verify out-of-band before doing anything.
3. Extension audit: Open your browser and code editor, list every extension installed, and uninstall anything you don't recognize or actively use.
4. Bookmarks: Bookmark the real URLs for every crypto site you use. Stop searching them on Google.