Threat Modeling for Tech-Aware Users 2026: STRIDE Beyond Corporate

Table of Contents

• Why generic threat modeling fails tech-aware users
• EFF SSD adapted: assets, adversaries, capabilities
• STRIDE for non-corporate profiles
• Risk matrix: solo dev on Mac, iPhone, GitHub, AWS
• Mitigations by tier
• Six profiles: assets, adversaries, priority mitigations
• Annual review: re-evaluation checklist

Why generic threat modeling fails tech-aware users

The NIST Cybersecurity Framework 2.0 (published February 2024) is a solid governance document. It does not tell you what to do when a random OSS maintainer discovers that a malicious PR just landed in a package with 40,000 weekly downloads. Generic consumer security advice — "use a password manager, enable 2FA" — is necessary but not sufficient for anyone whose digital surface area looks like: three GitHub organizations, an AWS root account, a CI pipeline with deploy keys, a public SSH endpoint, DNS managed through Cloudflare, and a dev machine that also accesses personal banking.

The gap is not about sophistication. It is about specificity. Consumer guides model a threat profile of "account takeover by opportunistic attacker." A developer or sysadmin's realistic threat profile includes: targeted supply-chain injection, CI/CD secrets exfiltration, SSH key theft from a compromised dotfiles repo, and social engineering from someone who has read your commit history and knows your deployment stack.

EFF's Surveillance Self-Defense (ssd.eff.org) correctly frames security as a function of your specific situation — assets, adversaries, capabilities, likelihood, consequences. The consumer-focused guides skip the first step: precisely enumerating what you actually have that is worth attacking.

For this reason, the methodology below starts with asset enumeration specific to technical practitioners, then maps adversaries with realistic capability assessments, before touching any mitigation recommendations.

See the pillar guide on browser privacy in 2026 for the broader privacy landscape this threat model sits within.

EFF SSD adapted: assets, adversaries, capabilities

Asset enumeration for technical practitioners

Before categorizing threats, enumerate what you actually own. For a typical indie developer or OSS maintainer in 2026, the asset inventory breaks into five categories:

Identity assets: GitHub/GitLab accounts (tied to a public reputation and organizational permissions), cloud provider root accounts (AWS, GCP, Azure), domain registrar accounts (the root of your web presence), email accounts (the recovery path for everything else), and package registry accounts (npm, PyPI, crates.io — the blast radius of a compromise here extends to every downstream consumer).

Infrastructure assets: Production servers and containers, DNS zones, TLS certificates and CA configurations, SSH keys (especially deploy keys with write access to repositories), cloud IAM roles and service accounts, secrets stored in .env files or secret managers.

Code assets: Private repositories, CI/CD pipeline configurations, dependency lockfiles, signing keys for commit signing or package releases.

Financial assets: Stripe/payment processor accounts, domain renewal payment methods, cryptocurrency wallets if applicable.

Reputational assets: Your public commit history, your package publish access, your social accounts tied to your professional identity.

Adversary taxonomy

EFF SSD uses a five-level adversary taxonomy. Adapted to the tech practitioner profile:

Opportunistic attackers scan the internet for exposed credentials, unpatched services, and reused passwords. They are automated, high-volume, and low-sophistication. They will find your EC2 instance with port 22 open within minutes of launch if it is on a residential IP range. This is the baseline threat that security fundamentals address.

Targeted attackers (criminal or competitive) have identified you specifically as a target of financial value. They will craft spearphishing against your specific stack, attempt supply chain injection into your dependencies, and monitor your public activity for operational intelligence. Reaching this tier requires either meaningful revenue, custody of valuable data, or visibility in a financially interesting space.

Nation-state actors operate with essentially unlimited persistence and a broad set of zero-day capabilities. For most practitioners, this threat tier requires exceptional circumstances: working on sensitive government infrastructure, being a political dissident, or being a journalist covering intelligence services. The existence of this tier matters for calibration — you should not design all mitigations for nation-state resilience, because the cost/complexity trade-off is untenable for most situations.

Insider threats are people with legitimate access who act maliciously or negligently. For solo practitioners this is less relevant; for OSS maintainers with multiple collaborators, it is significant — a compromised maintainer account, a disgruntled contributor with merge rights, or an accidental secret commit from a trusted contributor all fall here.

Capabilities matrix — for each adversary type, assess what resources they have: credential databases, infrastructure for phishing, zero-day exploits, legal compulsion, physical access. Crossing asset value against adversary capability produces the realistic threat space you need to address.

STRIDE for non-corporate profiles

Microsoft's STRIDE framework (1999, Adam Shostack) categorizes threats into six classes. Corporate security teams apply it to data flow diagrams of application architectures. For individual practitioners, apply it to your personal infrastructure topology.

Spoofing (account takeover). The spoofing threat for a developer is primarily account takeover: someone impersonates you on GitHub, your cloud console, or your registrar to perform actions under your identity. Attack vectors include: credential stuffing from breached databases, real-time phishing proxies (Evilginx2 can bypass TOTP 2FA), SIM swapping (to intercept SMS 2FA), and OAuth token theft through malicious GitHub Apps. The mitigation is phishing-resistant authentication — hardware FIDO2 keys — for accounts where a successful spoof has high blast radius.

Tampering (supply chain). A tampered artifact means modified code reaches production or end users. For a developer this manifests as: a malicious PR merged without adequate review, a dependency version bump that introduces a backdoor (xz utils, event-stream), a compromised build environment that signs a modified binary, or a stolen npm publish token. The mitigation stack includes: Sigstore/cosign for artifact signing, pinned lockfiles with hash verification, code review gates that do not trust automated bots, and SLSA provenance levels.

Repudiation (audit trails). Can you prove what happened and who did it? Git commit signing with SSH keys or GPG establishes a tamper-evident record of code changes. Signed commits do not prevent attacks but do establish accountability — critical if you need to demonstrate to downstream users that a specific commit was not authored by you. CloudTrail and equivalent audit logs for cloud actions serve the same function.

Information disclosure (leaked secrets). The most frequent high-impact incident in the developer world. A .env file committed to a public repository, an AWS key in a GitHub Actions log, a database connection string in an error message, or a private key embedded in a Docker image layer. git-secrets, truffleHog, and GitHub's secret scanning catch committed secrets; pre-commit hooks prevent them from landing. Rotating credentials immediately after any suspected disclosure is non-negotiable.

Denial of Service (availability). For a solo developer hosting a SaaS product, sustained DDoS can eliminate revenue. More subtle: rate limiting on your GitHub API calls or CI/CD pipeline exhaustion through a crafted dependency that triggers excessive build times. Mitigation at the baseline tier is Cloudflare or equivalent CDN/DDoS protection in front of public endpoints. At the infrastructure level, ensure that a single compromised dependency does not have the ability to exhaust your CI budget.

Elevation of privilege (CI/CD pipelines). A CI pipeline that runs with write access to the production environment and accepts arbitrary code from pull requests is an EoP vector: an attacker submits a PR that exfiltrates deploy keys or writes malicious code to production. GitHub Actions mitigates this with the pull_request event having read-only GITHUB_TOKEN by default, but many repositories override this. Separate workflows for untrusted PRs (read-only, no secrets) from trusted merges (deploy access) is the correct architecture. OIDC federation eliminates long-lived credentials in CI entirely.

Risk matrix: solo dev on Mac, iPhone, GitHub, AWS

A concrete example: a solo developer running a SaaS product on Mac (primary workstation), iPhone (2FA device and personal communication), GitHub (code and CI/CD), and AWS (production infrastructure). Scoring each vector using a simplified 1–5 probability × impact scale:

This matrix tells you where to focus first: GitHub and AWS root account protection, plus .env leak prevention. Everything else is important but not first in queue.

For reference on CVSS 3.1 scoring of specific vulnerabilities in your dependencies, the NVD database (nvd.nist.gov) provides base scores for CVEs; environmental and temporal modifiers let you adjust scores to your deployment context.

Mitigations by tier

Baseline (all tech practitioners, no exceptions)

Passkeys and FIDO2 hardware keys for GitHub, cloud consoles, domain registrars, and email. These are the accounts where account takeover has the highest blast radius. A compromised registrar account lets an attacker take over every domain and associated certificate. A compromised GitHub account lets them push malicious code and exfiltrate all repository secrets.

TOTP-based 2FA (Ente Auth, Aegis, 1Password TOTP) for every account that does not support passkeys. TOTP is not phishing-resistant but defeats credential stuffing at scale. SMS 2FA is worse than TOTP for accounts associated with a known phone number — SIM swapping is a documented attack vector.

Password manager with unique, randomly generated credentials for every account. Bitwarden and 1Password both integrate CLI tools for use in automation. See the password manager guide for engineers for CLI integration details.

Secret scanning pre-commit hook. Install truffleHog or git-secrets as a pre-commit hook. Run git log --all --full-history against your existing repositories to audit for historical leaks.

AWS root account lockdown. AWS root credentials should have MFA enabled with a hardware key, and the root account should have no access keys generated. All operational access should use IAM roles with least-privilege policies.

Intermediate

Dedicated hardware security key (YubiKey 5 NFC or equivalent). The YubiKey 5 supports FIDO2, PIV, OpenPGP, and OTP in one device. For FIDO2, register two keys and store the backup in a physically separate location.

Separate development machine or VM for highest-sensitivity operations. If your daily-driver machine runs arbitrary npm install from many projects, its credential store is exposed to any package that executes a malicious install script. A dedicated, hardened VM with only the tools needed for financial account access or sensitive infrastructure management limits the blast radius of a workstation compromise.

Commit signing. Configure SSH commit signing (supported by GitHub since 2022) or GPG signing for all commits. Enable branch protection rules requiring signed commits on main/release branches.

Audit cron. A weekly automated check: aws iam generate-credential-report to review IAM credentials, gh api /user/installations to audit GitHub App permissions, dig axfr equivalent checks for unauthorized DNS changes. These are detectable signals of account compromise that occur before an attacker achieves their objective.

Dependency pinning with hash verification. Lock dependencies to specific commit SHAs or content-addressed hashes, not floating semantic version ranges. For npm, npm ci with a committed package-lock.json; for Python, pip-compile with hashed requirements; for Go, go.sum is already hash-based.

Advanced

Tailscale (or Headscale) for infrastructure access. Expose nothing on the public internet that does not need to be public. SSH, admin panels, monitoring dashboards, and staging environments belong on a Tailscale mesh. Pair with Tailscale ACLs to enforce least-privilege network access between devices. Headscale (self-hosted coordination server) eliminates the dependency on Tailscale's coordination infrastructure.

Separate browser profiles per context. Financial accounts, development work, general browsing, and social media should run in isolated browser profiles or separate browser binaries. Firefox with Multi-Account Containers achieves container-level isolation within one binary. This prevents cookie and session correlation across contexts. See the network leak detection guide for detection methodology.

Isolated build environment. CI should run in ephemeral environments with no persistent credentials. For local builds, a container or VM with no host credential mount ensures that a malicious build script cannot harvest the host's SSH agent, cloud credentials, or keychain.

VPN for sensitive network contexts. A no-log, audited VPN on untrusted networks (public Wi-Fi, hotel ethernet) prevents passive interception of unencrypted traffic and hides your IP from destination servers. The VPN guide for tech-aware users covers the evaluation methodology for providers.

Six profiles: assets, adversaries, priority mitigations

Annual review: re-evaluation checklist

A threat model is not a document you produce once and file. The threat surface changes as your activity changes. The following events each require an immediate re-evaluation:

Trigger events requiring immediate re-evaluation:

• New project becomes publicly visible (ProductHunt launch, GitHub stars crossing 1,000, press mention)
• You gain administrative access to infrastructure you did not control before
• A security incident touches any account in your ecosystem, even indirectly
• Revenue crosses a threshold that makes financial attack economically rational
• You receive a message that could be targeted social engineering
• Your name appears in a context that increases doxxing risk

Annual re-evaluation checklist:

1. Re-enumerate all assets. What accounts exist that did not six months ago? What services have you added to your stack?
2. Audit access tokens. Run gh auth list, aws iam list-access-keys --user-name <all users>, gcloud auth list. Revoke anything not actively used.
3. Review 2FA methods. Have any accounts been downgraded from hardware key to TOTP, or from TOTP to SMS? Fix regressions.
4. Check for exposed secrets. Run truffleHog across all repositories including private ones. Run Grype or equivalent against container images.
5. Update dependency lockfiles. Pin to current known-good versions, review changelog for security-relevant changes.
6. Review cloud IAM policies. The principle of least privilege erodes over time as permissions are added for convenience and never removed.
7. Test backup restore. An untested backup is not a backup. Verify that your encrypted disk images, database snapshots, and seed phrase backups are intact and recoverable.
8. Reassess adversary tier. Has anything in your professional or public profile changed that would elevate you to a higher-value target?

The NIST CSF 2.0 Govern function formalizes this kind of continuous improvement loop at the organizational level. For individuals, the equivalent is a calendar reminder, a structured checklist, and the discipline to execute it even when nothing has gone visibly wrong.

The EFF publishes updated guides at ssd.eff.org on a rolling basis. The MITRE ATT&CK Matrix (attack.mitre.org) is updated quarterly with new adversary techniques derived from real incidents — useful for checking whether any new TTPs are relevant to your profile.

Building a reliable threat model is not a one-afternoon exercise. It is the habit of systematically asking, for each significant change in your attack surface: what could an adversary do with this, and is the cost of preventing it lower than the cost of the incident? The frameworks above — EFF SSD, STRIDE, CVSS 3.1 scoring — give you reproducible language for that conversation, whether it is with yourself, your collaborators, or a security professional you consult when the stakes are high enough to warrant outside review.