Solo Builders Have a Security Blindspot. Here's What It Costs.

Most solo builders have an implicit deal with themselves about security.

It goes something like this: the app is small. Nobody is attacking it. When it gets bigger, I'll deal with it properly.

This is almost always wrong — and the cost of being wrong almost never looks like a Hollywood hack. It looks like a slow leak nobody notices until the damage is done.

gstack's cso skill runs a Chief Security Officer audit across your entire project. 14 phases covering secrets archaeology, dependency supply chain, CI/CD pipeline security, LLM-specific vulnerabilities, OWASP Top 10, and STRIDE threat modeling.

The first time I ran it, I thought I'd see minor issues. I was wrong about that too.

What 14 Phases Actually Covers

The /cso audit runs in two modes: daily (high-confidence, fast) and comprehensive (full threat model). The comprehensive mode covers:

Phase 1-3: Infrastructure and credentials Secrets archaeology — scanning git history, environment files, configuration for accidentally committed keys, tokens, and passwords. This catches the API key you added to a .env file six months ago and forgot to rotate.

Phase 4-6: Dependencies Supply chain analysis — checking whether your dependencies have known CVEs, whether you're pulling from verified sources, whether a compromised package could be silently executing arbitrary code in your build pipeline.

Phase 7-9: Application layer OWASP Top 10 coverage — injection vulnerabilities, broken authentication, insecure direct object references, the ten categories of application security flaw that account for the majority of real-world breaches.

Phase 10-12: AI-specific risks LLM attack surface — prompt injection, context extraction, model misuse via crafted inputs. This is the category that barely existed three years ago and is now the primary attack vector against AI-native applications.

Phase 13-14: Architecture STRIDE threat modeling — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. A structured framework for asking "how would someone attack this system?" before they do.

The Problem With "We're Too Small to Matter"

The logic of "nobody is targeting us" makes a reasonable-sounding assumption: that attackers are selective.

In practice, most attacks are not targeted. They're automated. A script scanning the internet for exposed API keys, misconfigured S3 buckets, or applications vulnerable to common injection patterns doesn't care about your ARR. It cares about whether your application is vulnerable.

Small applications get breached constantly. They're often the most interesting targets precisely because their owners assumed they were too small to bother.

The cost isn't always obvious. A compromised API key might quietly generate thousands of dollars in usage fees over weeks before you notice. A leaked user database from a small app becomes credential-stuffing ammunition used against larger targets — and you're now part of someone else's breach story.

The reputational cost of a security incident is also asymmetric. A large company survives a breach. It becomes a news story, they issue a statement, and the incident fades. A small company or solo product often doesn't survive the same event — not because of the technical damage, but because user trust is the entire asset.

The LLM Attack Surface Is New and Underestimated

The CSO skill's coverage of LLM vulnerabilities is the part that surprised me most.

If you're building an AI-powered product, you have attack vectors that didn't exist three years ago. Prompt injection — where user input manipulates the model's behavior in unintended ways — is the most obvious, but it's not the only one.

Context extraction lets attackers probe your system prompt and internal instructions. Model misuse turns your application into a tool for generating harmful content or bypassing the content policies you thought were protecting you. Jailbreaking through carefully crafted inputs can escalate the effective permissions of the model.

These aren't theoretical risks. They're actively exploited in production AI applications today.

Most solo builders building AI-native products are operating with zero coverage for this entire category. They've thought about SQL injection and haven't thought at all about prompt injection.

Security as Architectural Thinking

The most valuable thing the CSO audit does isn't catch specific vulnerabilities. It's force STRIDE-based architectural thinking.

STRIDE asks you to look at your system from an attacker's perspective: who can impersonate a legitimate user? What data can be tampered with? What operations can't be undone? What information is exposed that shouldn't be? What can be overwhelmed? What privileges can be escalated?

Most developers build systems from an optimistic perspective — thinking about what the system should do. Security requires the pessimistic complement — thinking about what the system allows that it shouldn't.

Running that audit regularly, not just before launch, is what separates teams that catch problems early from teams that get surprised.

The CSO skill makes that audit accessible to builders who don't have a security team, a security culture, or a security budget.

Which is most of us.

---

AI Skill Daily 005. Part of the gstack series — 35 specialist skills from garrytan/gstack.