ARTICLE

What should founders actually do to keep their company secure?

— ·Wilson Spearman ·9 min read

Brief

Wilson Spearman’s YC thread asks a pragmatic startup question: after incidents like the Axios supply-chain attack, the Mercor hack, and the LiteLLM package issue, what should an early-stage company actually do to stay secure without overinvesting in check-the-box compliance? The strongest consensus was around reducing supply-chain exposure and limiting blast radius. Commenters recommended delaying installation of newly released packages, disabling install scripts when possible, pinning GitHub Actions and container builds by hash, and using lockfiles rather than blindly auto-updating dependencies. Examples included npm’s ignore-scripts=true and min-release-age=3, pnpm’s minimumReleaseAge 4320, and uv’s exclude-newer = "P7D".

Beyond dependencies, the advice focused on identity, access, and incident readiness. Several commenters argued founders should avoid storing long-lived credentials on developer machines, prefer IAM identities and short-lived federated credentials, and fetch secrets from systems like AWS Secrets Manager or 1Password instead of local .env files. Device controls such as EDR tools like SentinelOne, MFA, password managers, and biometric-protected SSH keys were recommended alongside process controls like backups, architecture diagrams, code review requirements, and a basic incident runbook. The thread also pushed back on equating SOC 2 with real security: the better approach is to define a threat model, decide what matters most pre-product-market-fit, and build pragmatic controls around employee devices, production access, CI/CD hygiene, and recovery procedures.

Why it matters

Multiple commenters recommended delaying adoption of newly published dependencies to reduce supply-chain risk: Adam Dorfman suggested a 7-day wait (`uv` `exclude-newer = "P7D"`), while Andrew Israel cited npm settings `ignore-scripts=true` and `min-release-age=3`, plus pnpm’s `minimumReleaseAge 4320` and `ignoreScripts true`.

Key details

  • The thread emphasized pinning and locking dependencies across the stack: Adam Dorfman advised pinning GitHub Actions, pre-commit hooks, and Docker builds to specific hashes rather than version tags, and Akul Gupta said the Axios-style incident would be better mitigated with lockfiles and pinned versions than with application security scanners.
  • A consistent recommendation was to minimize credential exposure by avoiding long-lived local secrets: Adam Dorfman recommended IAM-based auth, IAM federation, and short-lived credentials via AWS IAM Identity Center instead of API keys, and storing secrets in AWS Secrets Manager or 1Password Secrets rather than `.env` files or environment variables on developer laptops.
  • For small teams, Andrew Israel framed the main security priorities as employee devices, production access, and developer education; his examples included preventing direct pushes to `main` without review, using hardware/biometric-protected SSH keys via Secretive instead of `~/.ssh`, and ensuring any local AWS credentials have minimal privileges.
  • Basic operational hygiene came up repeatedly: Jorrel Sto Tomas recommended backups, regular key rotation, incident runbooks, MFA everywhere, and patching; Alex Chantavy added EDR/antivirus such as SentinelOne, a password manager like 1Password, architecture diagrams, clear visibility into logs, and knowing exactly which package versions (for example Axios) are present in the environment.
  • Several commenters argued that security work should be threat-model driven rather than compliance-led: Joshua Goldbard said founders should define what can break, who owns recovery, and what level of attestation is actually needed, while Bryan Onel criticized SOC 2 tooling from vendors like Vanta, Drata, and Secureframe as often producing an “illusion of security” rather than real hardening.
Source evidence

title: What should founders actually do to keep their company secure?
author: Wilson Spearman
source_url: https://bookface.ycombinator.com/posts/99323

word_count: 2095

What should founders actually do to keep their company secure?
Seems like there has been a massive uptick in threats recently (axios supply chain
attack, Mercor hack, LiteLLM
package). At the same time, there’s a lot of discourse about things that
startups currently do that don’t actually seem to improve security (SOC II).
So my question is: what should I actually do to keep our company secure? We don’t have enterprise customers and we
don’t handle PII beyond emails, but obviously I don’t want to get PWN’d (we spent all day yesterday rotating keys
because our engineer who’s finishing his last semester of college got his laptop taken over by the axios supply chain
attack installing the package for class).
Would love to know what the more experienced would recommend to a small YC team :)

Comments

Adam Dorfman (Tower (W24)) (1 day ago)
Honestly these kinds of supply chain attacks are really difficult to completely mitigate. The quick wins:
Set min 7 days wait for package release
uv → pyproject.toml → [tool.uv] → exclude-newer = "P7D
pnpm, npm, etc. have equivalents.
Pin all of your GH actions, pre-commit hooks, docker container builds to specific hashes rather than version numbers. Github Actions is apparently a landmine for vulnerabilities.
Use socket firewall in containers and on your local systems to prevent you from accidentally installing compromised versions of packages.
Minimize the number of packages you’re using - this one is a balancing act, but every additional package is surface area for attacks.
When possible, avoid API keys. AWS, Azure, and GCP all let you use your IAM identity (which is automatically assigned to tasks/containers) to authenticate to services. They all also support IAM federation, letting you use your AWS IAM identity to access Azure resources, GCP resources, and vice versa. In dev, you can use the AWS CLI + IAM Identity Center to use SAML/OAUTH for sign in with short lived credentials stored on device, rather than having long-lived credentials stored on device - Azure & GCP have equivalents.
Separate your dev environment from your prod environment, ensure all API keys you have are scoped to minimum permissions and environment, and make sure to use separate credentials for each dev so that you don’t affect everyone with one mistake.
For both prod and dev, avoid storing credentials on device in env files and environment variables. It’s more secure to fetch them at startup time from AWS Secrets Manager, 1Password Secrets, or any equivalent.
Do a security audit for gaps - AWS has Security Hub, Google and Azure probably have equivalents. They’ll automatically give you a bunch of recommendations for security hardening improvements you can make. AWS’ defaults are pretty awful, but the security hub fortunately catches a ton of the issues.
Avoid having SSH keys, GPG keys, a

Andrew Israel (PropelAuth (W22)) (1 day ago)
For small teams, there’s usually a few major things to worry about: employee devices, production access, and dev education.
On the employee devices side, a few small things that can help specifically for some of the supply chain attacks is having your package manager not run install scripts and not take recently published dependencies. For the axios case, this would’ve helped both because the malicious package was too new to be installed and because it wouldn’t have had an effect if it was installed.
For npm, this means adding this to your ~/.npmrc:
ignore-scripts=true
min-release-age=3
(and updating npm, they only added support for min-release-age recently). Most package managers have this concept, although they are not super consistent, so for pnpm for example you’d run:
pnpm config set --global minimumReleaseAge 4320
pnpm config set --global ignoreScripts true
In the python ecosystem, it’s a little bit harder. I don’t believe pip has both of these concepts, but uv does w/ settings like exclude-newer and no-build.
One of the nice things about being small is you can just tell everyone to set this up / sit them with while they do it.
But shit happens, and so the other thing to do is minimize the possible damage from those types of attacks. It’s going to be specific per company, but a good rule of thumb is to avoid having a secret / key stored locally wherever possible. For git, for example, you can have employees create ssh keys in secretive (instead of in ~/.ssh) which makes hard to steal and means they can’t be used without a fingerprint scan/password entered. You should also protect from this on the github (or equivalent) side by preventing pushes directly to main without a code review, especially if you have anything that auto-deploys.
There’s a similar story for aws credentials, you just shouldn’t have them locally and if you do need them locally, you’d want the credentials you store locally have basically no access. The only access you give them is to be able

Akul Gupta (MindFort (P25)) (about 10 hours ago)
use
MindFort. Continuous testing of your application is the best thing you can do.
Also, use this prompt with your coding agent, will get you 80% of the way there for free.
Ultrathink. You are an expert application security engineer. Your task is to conduct a thorough security audit of this codebase.
Before starting, ask me scoping questions to focus the audit effectively:\
Which parts of the codebase are highest priority or most recently changed\
What's deployed vs in development\
Known areas of concern or previous findings\
Auth model and multi-tenancy architecture\
Whether to include dependency/supply chain analysis\
Any compliance requirements (SOC2, etc.)
Once scoped, systematically review the code covering: auth & authz, injection & input validation, secrets & config, API security, data protection, infra/container misconfigs, LLM/agent security (prompt injection, sandbox escapes, unsafe tool calls), and business logic flaws. Only report issues grounded in actual code — no hallucinated findings.
After completing the full review, compile all vulnerabilities into a single markdown file with each finding listing: severity (Critical/High/Medium/Low), file & line, vulnerable code snippet, explanation, and CWE ID.
Then create a remediation plan in the same file that:\
Groups related fixes into logical workstreams\
Orders them by severity and dependency (what must be fixed before what)\
Provides concrete code fixes for each vulnerability\
Estimates relative effort (quick fix / moderate / significant refactor)
Do not fix anything. Only produce the report and plan. Wait for my approval before making any changes.

CreativeMode (S24) (about 9 hours ago)
I’ve tried these audit prompts from Codex for example and they really haven’t flagged anything useful. Would MindFort have prevented the Axios vulnerability in particular? For us the risk was a developer running pnpm install without minimum-release-age

Akul Gupta (MindFort (P25)) (about 9 hours ago)
For that specific attack, no. MindFort finds vulnerabilities in your application. This was a supply chain attack, the best mitigation for this is lockfiles & pinned versions. Would recommend setting them up on all your dependencies.

Jorrel Sto Tomas (Formerly AnythingLLM (S22)) (1 day ago)
gotta love fud. my dad/co-founder was a CISO for 30 years across large enterprise healthcare and pharma, and even the most locked-down companies were always dealing with something.
honestly the basics still go a long way for a small team:
People: train everyone not to click links or install stuff without checking first — sounds obvious but it's still how most things get in
Process: be paranoid, keep backups, rotate your keys regularly, and have a rough runbook so you're not figuring it out mid-incident
Technology: MFA on everything, patch regularly, and if the anxiety is real just get cyber insurance
you got hit, you rotated keys, you're already doing it right. just make sure the process is in place before the next one.

Alex Chantavy (SubImage (W25)) (1 day ago)
Lots of good recommendations in this thread already. I’ll try add some. I’d go simple:
Protect your devices:
Install an antivirus (also known as an EDR for Endpoint Detection and Response) tool like SentinelOne that comes with Rippling or similar) on your laptops.
Use a password manager like 1Password
Enforce multifactor authentication
Protect your production infra:
No creds in source, ever. Use AWS SecretsManager or similar.
Be ready to rotate creds at a moment’s notice.
Be ready to answer “Do I have Axios in my env? At what versions?” at any given time.
Maintain an architecture diagram of how your system works. It will help you stay organized if there is an incident. Understand your internet ingress points, understand what identities have access to sensitive databases. What are your sensitive databases/crown jewels.
Know where your logs are. Make sure you know where to look to find login failures and successes.
And you can generally stay updated by reading HN. Recently HN has been really good about being up to date on supply chain problems like Axios, LiteLLM, Shai-hulud, React2shell, etc.

Joshua Goldbard (Fire Wallet (P26)) (1 day ago)
I try to work on secure software. It’s hard.
A few things to keep in mind:
What is your threat model?
What happens if this breaks?
Who is the key holder/responsible individual? What happens if they’re absent?
Practical things: Version control package updates. You don’t need to automatically update everything blindly. You can decide to update vs auto-updating.
How much attestation is enough? For many projects, you don’t need reproducible builds or hardware attestation. Understand what you’re trying to protect.
Lastly, accept some risk. Things will break, and you should have monetary and temporal bounds on recovery.
Chaos Monkey (https://netflix.github.io/chaosmonkey/) is very useful for developing an understanding of what can or cant break in your systems, and then designing control mechanisms around that. « Don’t bother doing chaos monkey pre-product market fit.
Product-Market fit matters. If you spend all of your time building hardened systems that you forget to actually get customers, that’s not correct.
In short: figure out what your threat model is and adjust your defensive posture accordingly.
Happy to chat about securing software with anybody who has questions.

Cayden Liao (Veria Labs (F25)) (1 day ago)
We’ve been helping the LiteLLM team out with their security post-breach, been thinking a lot about the general question of keeping companies secure, would love to talk!
Some of the common threads that seem to be top of mind given the recent issues; there’s a lot of best practices that should be followed, like keeping good supply chain and CI/CD hygiene, setting up a proper incidence response plan, etc.

Aakash Shah (Wyndly (W21)) (1 day ago)
use
GhostEye to avoid social engineering attacks

Tarun Vedula (Zatanna (W26)) (1 day ago)
Cayden Liao

Vaibhav Dubey (Plexe (P25)) (about 9 hours ago)
Use
MindFort!

Saad Jamal (Claybird (F25)) (1 day ago)
talk to Hex Security

Ahmad Khan (Hex Security (W26)) (1 day ago)
use
Hex Security

Bryan Onel (Oneleet (S22)) (1 day ago)
It isn’t the case that SOC II fails to secure companies by default. It is that GRC companies optimize for speed and the illusion of security rather than getting it right.
Delve is an extreme example, but things aren’t much better if you look at Vanta/Drata/Secureframe, platforms that do not take the responsibility to actually make companies secure, but wash their hands of any wrongdoing because they’re just evidence collection platforms at the end of the day.
That is truly why Oneleet exists. We sell compliance, but we achieve it by aiming for security first. Not the other way around, which always leads to the illusion of security.

Benjamin Anderson (Cembla (S23)) (1 day ago)
Bryan are you guys still offering the “everything but the audit” security package for YC companies? I thought I remembered about you posting this in the past and it sounded like a great deal (was like $1–2k?), but I can’t find information about it now.

CreativeMode (S24) (1 day ago)
This sounds excellent as someone who doesn’t need compliance but needs to be secure :)

Bryan Onel (Oneleet (S22)) (1 day ago)
That is exactly why we developed it! 🙂
Upside is also that it will get you to about 50-70% of SOC 2 compliance (range is wide because SOC 2 is super flexible, and every company’s program is and should be different). So if you do want to make the plunge and do SOC 2, audit readiness can be achieved pretty quickly.

Bryan Onel (Oneleet (S22)) (1 day ago)
We still are! It only costs $100 per month, and you get all platform capabilities and unlimited vCISO support for the Oneleet Core Security Framework.
Note that the manual penetration test is not included. SAST, DAST and AI pentesting are however included.