New: The startup CTO's field guide to running security
Read the guide
Four signs your startup's security stack is coming apart at the seams, and what to do about it.
By Tim Olshansky, Co-founder of Fencer
Every startup security stack I've seen has some amount of duct tape in it. A code scanner here, a CSPM there, a GRC tool that needs feeding by hand, and countless spreadsheets. Most of the tools they're using weren't designed to talk to each other, so the person who built the stack gets stuck holding all the pieces together.
It happens because in the early days, security falls on whoever built the product, the pressure to move fast is constant, and the enterprise platforms built to consolidate all of this were designed for dedicated security teams, not CTOs with a product roadmap.
The duct tape works, and it can get you further than you'd expect. But every stack built this way eventually reaches the point where its tradeoffs start costing more than they're buying.
These four signs that the duct tape is wearing thin.
At my last startup, I had a monthly process: pull exports from each scanner, clean up the CSVs (half the time the exports weren't clean), collate everything into a master spreadsheet, and walk through it with the team. What was a duplicate, what was noise, what we were fixing by Friday.
It worked. But at some point I noticed that nobody else on the team could replicate it. The context for what each tool meant, how its severity scale compared to the others, what was a chronic false positive and what was new: all of that lived in my head.
The spreadsheet was the only coherent picture of our security posture, and I was the only one who could produce it. If I was out, the picture went dark.
What I didn't see until I was deep in it: my team's security hours weren't going into remediation. They were going into everything before remediation: cross-referencing findings across tools, deduplicating, separating genuine issues from noise, ranking what was left. The actual fixes were almost always small: a few lines of code, a toggle in a console, a new IAM rule. Fast once we'd decided what to do.
If this sounds familiar, your stack is generating more work than it's finishing.
Free scanners and native cloud tools generate findings constantly: container CVEs from base images that haven't been updated, misconfigurations from defaults nobody changed, detection rules that fired correctly six months ago and now just fire. Deciding which to suppress, which to triage, and which actually need a person is what your week becomes.
You can be productive and busy every day and not close a single vulnerability. The maintenance and the security work look the same on a calendar. The difference shows up when you ask honestly whether the work has reduced your exposure, and the honest answer is it hasn't.
Every control needs evidence: log retention policies, access reviews, change management records. You'll have been doing most of these things. You won't have been documenting them in a form an auditor can read.
A meaningful chunk of prep becomes retroactively producing proof for work that already happened. Not writing the policy, but proving the policy existed in a format somebody else can verify. The first time audit prep hits you as a two-week scramble, it's the tooling telling you it wasn't capturing what you were doing all along.
None of these patterns is a crisis in isolation. They become one when they're running together, and by the time that's obvious, the stack has usually been at its limit for a while.
At Zenput that moment crept up on me. I was spending more time babysitting the stack than using it: bouncing between tools, collating exports, figuring out whether a finding in one scanner was the same as another. The tools I'd duct-taped together had become the drag. I built Fencer because that time spent on the stack isn't security work; it's what gets in the way of it.
