The Minimum Viable Security Program for a One-Engineer Org

You are one engineer. You have five repos, a production database, three customers who will leave if you have an outage, and exactly no budget for a security team. Every "build a real security program" guide on the internet was written for a company with thirty engineers, a CISO, and a SOC 2 audit on the roadmap. None of it applies to you.

This post is what I would actually tell a founder in that profile. It is shorter than the standard advice because the program that fits the one-engineer profile is shorter.

---

Start with what you are not doing

The most useful thing I can do for someone at this scale is take items off the list. Most security advice for small teams is borrowed from advice for medium teams, which was borrowed from advice for large teams. The borrowing rounds off the parts that fit the originating context. When the originating context was "an organization with thirty engineers," the advice that gets to you assumes thirty engineers worth of slack.

You do not have thirty engineers worth of slack. You have one engineer worth of slack. Here is what you are not doing.

You are not running an annual pen test. A real engagement costs more than your monthly runway and produces a report you do not have the bandwidth to remediate from. Defer it to year three at the earliest, when you have a customer requiring it or a dedicated person to manage it.

You are not hiring a security engineer. Even if a security engineer cost what they cost in 2014, you do not have the management bandwidth for a hire whose work you cannot directly evaluate. Defer this until you have the company shape to support it — somewhere around your tenth engineer.

You are not pursuing SOC 2 in your first eighteen months. The compliance overhead alone — control mapping, evidence collection, vendor management — is a half-time job. Pursue it when a deal explicitly requires it and not a quarter sooner.

You are not threat-modeling in a stakeholder workshop, building a vulnerability management ticketing system, or staging a quarterly tabletop exercise. None of those produce more security per hour than the alternatives below for someone in your profile.

What you are doing is one continuous control done well, plus three operational habits that compound.

The one control: PR-time code-security review

A single discipline catches the bug classes that ship the most vulnerabilities in 2026. eval() on untrusted input. SQL injection. Path traversal. Stored credentials. Insecure-by-default cross-user data sharing. Postinstall hooks in your dependency tree. The OWASP Top 10 applied to whatever AI-shaped surface you shipped this sprint.

The Microsoft Semantic Kernel and Spring AI five-CVE week earlier in May was a public embarrassment for two large vendors specifically because of this. Five CVEs across two flagship frameworks in seven days, every bug class recognizable from the 2005 OWASP Top 10, shipped by Microsoft and the Spring ecosystem because the frameworks were not audited as the web/distributed systems they are. The bugs were not caught because the discipline was not there.

Your code is not exempt. If anything, the one-engineer profile makes the discipline more important, not less. You do not have a second pair of eyes on every PR. You are merging your own changes. The scanner is the second pair of eyes.

The mechanics are concrete:

• Every PR runs a code-security review before it merges. Automated, in CI, on every push. Not on a schedule, not before releases, not as a quarterly cleanup. Every change.
• The review covers three things. SAST for the bug classes listed above. SCA for your dependency tree, checked for known-bad versions and suspicious install behavior. Secrets detection across the diff, because credentials leak more often than anyone admits.
• Findings show up at PR time. Not in a quarterly report. Not in an inbox you will not check. Inline in the PR, on the diff that introduced them.
• You read the findings before you click merge. That is the entire human-in-the-loop. No team, no escalation tree, no triage process. Just you, reading what the scanner caught, deciding what to fix now and what to ship.

This is the PR-as-disclosure framing applied to the one-engineer context. Every change merged to main is, from the attacker's perspective, a publication event. You do not get a private patch cycle on public code. The earlier in your cycle the review fires, the smaller the window between "you wrote a bug" and "an attacker is reading your code." For a one-engineer org, the cycle is short and the window has to be shorter.

Three operational habits that compound

1. Treat secrets as plutonium

Never in code. Never in a .env you commit by accident. Never in a Slack DM. Never in a screenshot you paste into a support thread. Never in a Notion doc that you forgot was set to public.

Use a secrets manager from day one — 1Password, Doppler, AWS Secrets Manager, HashiCorp Vault, whatever fits your stack. The choice matters less than the discipline. The discipline is "the only place a production credential lives is the manager; everywhere else it is a reference to the manager."

Rotate when in doubt. The cost of rotation is hours of your time and a brief deploy disruption. The cost of a leaked production credential, depending on what it grants access to, is the company. The math is one-sided.

If you have already committed a secret to a repo and you are reading this and thinking "I should probably check" — yes. Check now. Treat any secret that ever lived in a public-repo commit as compromised. Rotate it. The git history will not save you; the secret was already in someone's clone before you noticed.

2. Pin your dependencies

Hash-pin where the ecosystem supports it. Lockfiles with subresource verification on npm. --require-hashes on pip. Content-addressed digests on container images. Disable postinstall scripts by default (npm install --ignore-scripts); allowlist the few packages that genuinely need them.

Treat a transitive dependency update like an unsolicited PR from a stranger, because that is exactly what it is. The maintainer of a package three levels deep in your dependency tree just changed something in code that runs on your machine, your CI runner, and your production deploy. The change has not been reviewed by anyone you trust.

The wallet-stealer pattern survey and the postinstall hooks bug class post both document what happens when the dependency layer is left ungoverned. Compromised packages ship payloads that walk a hardcoded list of paths on your developer machine and exfiltrate whatever they find. Your developer machine is your production deploy surface; the same secrets the payload finds locally are the secrets it finds in your CI runner. Hygiene at the dependency layer is hygiene at every downstream layer.

For a one-engineer org, "pin and audit" is a five-minute discipline per PR: when the lockfile changes, you read the diff. Not the entire package, just the diff. Anything unfamiliar — new postinstall hook, new transitive dependency from a publisher you do not recognize, version jump larger than a patch — gets a closer look before the PR merges. Most of the time, this takes thirty seconds. Sometimes it catches the Trivy / TeamPCP-shaped compromise that would have ruined your week.

3. Be incident-ready, not incident-free

You will have an incident. Cap the timeline at "eventually." A small team that has shipped to production for a year and never had an incident has not had a security incident — they have had an unnoticed security incident.

The discipline that matters is "be ready when it happens." For a one-engineer org, that means a runbook. Three sentences is enough to start:

1. Where your data lives. List the specific datastores, hosting providers, and backup locations. Names, account IDs, region codes. If you cannot answer "where is the customer data" in twelve seconds at 11pm on a Saturday, the runbook has a gap.
2. Who you call (or which provider's status page you check). The on-call rotation for your hosting provider. The number for your bank's fraud department, if you handle money. The escalation path for your auth provider. Include phone numbers, not just URLs.
3. What you turn off first. The kill switch sequence. If you suspect a credential is compromised, which credential do you rotate first? If you suspect your deploy pipeline is compromised, which job do you cancel? Pre-decided, written down, tested.

Test it once a quarter by reading it aloud and noticing what you do not know. Add the gaps to the runbook.

The reason this matters more than the polished version of "incident response" is that when something breaks at 11pm on a Saturday — and it will — you are the on-call rotation. You will not remember which CDN hosts your assets, which keypair signs your deploys, or which support channel actually responds in under twelve hours. The runbook is for you, at 11pm, when you are tired and panicked. Write it for that person.

What you are trading off

This program does not give you defense-in-depth. It does not give you a SIEM. It does not give you a 24/7 SOC. It does not protect you from a determined nation-state adversary. It does not give you a clean SOC 2 report, a compliance attestation, or a security page on your marketing site that anyone is going to read.

What it does is run the one control that has to run at attacker speed — code-security review on every change — without you having to staff or schedule it. And it bakes the three operational habits that compound from week to week without requiring quarterly check-ins. Those four things together cover the threat surface that one-engineer orgs actually get hit by: shipping a bug, leaking a secret, installing a compromised dependency, getting overwhelmed by an incident.

The threat surface they do not cover is "well-resourced targeted attacker." If you are that profile of target, you need a security program, not a minimum-viable starter pack. Most one-engineer orgs are not that profile. Most one-engineer orgs are at risk from the same broad-spectrum threats every shipping codebase is exposed to. This program defends against those.

You will outgrow it. The moment you have a second engineer, the runbook has to grow. The moment you have a security-relevant customer (one with a vendor questionnaire that takes more than an hour), SOC 2 enters the conversation. The moment you ship to a regulated vertical, the program has to formalize. All of those are good problems and you should expect to have them in the next eighteen months if the product is working.

For now, do one control well and three habits consistently. That is more security per hour of your time than any other allocation, by a wide margin.

How Rafter fits

Rafter (rafter.so) is opinionated about the PR-time gate above. rafter run reviews a diff for the bug classes that scale when attackers have AI — SAST plus SCA plus secrets, on every change, before the change ships. --mode plus adds agentic deep-dives where pattern matching is not enough. rafter secrets . is a local-only secrets check that needs no signup, so you can audit a repo offline before deciding whether to do anything else.

The product was designed specifically for the workflow above — one engineer or a small team, no dedicated security person, scanner findings on every PR, human review at merge time. The mechanics fit because the constraints fit.

Rafter is on AppSumo as a lifetime deal right now. Limited time. The deal exists for exactly the one-engineer profile this post is written for — a tool you are going to run on every PR for years, paid for once. Search "Rafter" on AppSumo, or grab it at appsumo.com/s/1yvki7f/ before the window closes.

The window closes when AppSumo says it does. The program above is the program either way.

---

Further reading

• A lifetime license for a lifetime threat
• Mythos and the three-month window
• Why pre-commit beats PR-time scanning
• Wallet-stealer payloads in package ecosystems
• Postinstall hooks as a bug class
• Five CVEs across AI agent frameworks
• A year of AI developer-tool supply-chain attacks
• Secrets detection guide
• Transitive dependency risks