Security

Raise the Floor

You can't finish securing yourself. You can finish finding out.

Rahul Govind·May 30, 2026·9 min read

You already know you should be doing more about security. That has never been

the problem. The problem is that every time you sit down to start, you're

staring at a list with no bottom — scan the repos, rotate the keys, turn on MFA,

kill the old credentials, add a secrets manager, wire up logging, get it all

somewhere that can actually alert you — and each line is real work, a new tool

to trust and a new thing to maintain forever. A list like that doesn't get

worked through. It gets avoided. So you do nothing, feel a little guilty about

it, and the list waits for you exactly where you left it.

This is about doing one thing instead. Not the list. One thing, chosen because

it's the one you can actually finish today.

Prevention is a program. Detection is a question.

Here's why the list beats you, and it's structural, not a failure of your

discipline.

Most of what's on it is a program, not a task — something you stand up and

then tend forever. Scanning, rotation, posture, logging: there's no version of

those you "complete." And almost every one asks you to trust something new with

access to your code, your cloud, or your laptop. A pile of open-ended

commitments, each with a trust cost, is precisely the kind of pile a busy person

never starts.

Some of the list isn't like that. Turning on MFA is a discrete act you can

finish in ten minutes. So is deleting that ancient access key you haven't used

since 2023. If you do nothing else after reading this, do those — really, go,

I'll wait.

But notice what every one of those moves has in common: they lower the odds

that something goes wrong. None of them tells you when the odds lost anyway —

when a key slips out in a build artifact, a laptop walks, a contractor's machine

gets popped. That's a different and much smaller question: *if a credential of

mine gets used, will I hear about it?* It has a yes or a no, and you can move it

from no to yes this afternoon and be genuinely done.

That question is the floor. Not the most powerful control you could buy — the

cheapest one you can actually finish, and the only kind that speaks up when

everything above it has already failed.

The expensive part of a breach is the silence

Why answer that question first? Because the cost of a breach is dominated by how

long it goes unnoticed, not by the instant it happens.

Try it as an experiment. Ask a developer whether the last big supply-chain

attack hit them. Almost everyone says no. Then ask whether they're sure — and if

they're honest, it turns out "no" was a hope, not a finding. They have no way to

check. That gap, between feeling fine and actually knowing, is the thing dwell

time measures.

Mandiant's M-Trends 2026 put the global median dwell time at

14 days,

the typical stretch an intruder operated inside before anyone noticed. That number

rose from 11 the year before, which Mandiant attributes to attackers getting better

at evading defenses. And the median flatters reality. It gets dragged down by the

loud intrusions a ransomware crew announces itself; the patient intruder stays

hidden far longer. Mandiant clocked the median for cyber-espionage and North Korean

IT-worker cases at 122 days, four months inside before anyone noticed. The

quiet, financially-motivated intruder who just wants your compute or your data has

no reason to ring the bell, and against that one the silence is the entire game.

Then consider who isn't in those numbers at all. M-Trends counts organizations

that called in incident responders — outfits that had something watching and

still took weeks. The person who set up nothing doesn't have a dwell-time

median. Their clock runs until the bill arrives, or a stranger emails them, or

never. Being breached is bad. Being breached and blind is the part that runs up

the cost — and it's the part you can fix cheaply.

The cheapest thing you can finish is a tripwire

So build the cheapest possible detector: a tripwire.

A tripwire — a canary, a honeytoken; the names vary — is a credential whose only

job is to be stolen. You place something that looks like a real API key or cloud

credential where an intruder would plausibly find it. It grants access to

nothing real. It just sits there. The moment someone uses it, you get told:

who, from where, and what they tried.

Credentials are the right bait because they're the road attackers actually take.

Verizon's 2024 DBIR found that the use of stolen credentials was the single

most common initial action in breaches, present in

24%

of them and involved in 77% of web-application attacks.

And if you're thinking that's enterprise stuff, nobody's coming for me — that's

the part the speed numbers settle. When Clutch Security scattered AWS keys around

the internet, the ones on GitHub were found and used

within minutes,

often before AWS's own leaked-key warnings could fire. Orca's honeypot study

clocked an exposed GitHub key

used in two minutes.

The bots scraping every public commit don't know you're one person with a side

project, and they don't care. Indiscriminate is the whole business model.

And here's the part worth saying plainly: attackers cheat. That's the whole job —

they lie about who they are, hide in traffic that looks ordinary, and run on

trust they were never given. Defense mostly answers by playing fair: a higher

wall, a stricter rule, and hope. A tripwire doesn't play fair. It's a lie told to

a liar — bait that means nothing to an honest user and everything to someone who

shouldn't be there. For once, the dirty trick is on your side.

That's what turns their speed inside out. The one thing an intruder is fastest at —

grabbing a credential and trying it — becomes the thing that gives them away. You

don't have to catch them. They catch themselves.

It hands you a file instead of taking your keys

There are a hundred detectors you could stand up. The reason a tripwire is the

right first one is how little it asks you to trust.

Look at what every other security tool wants before it helps you: an agent

running on your machine, a role inside your cloud account, OAuth scopes into your

repositories, a binary piped from some URL into your shell. Each is a new thing

to vet and a new way to get hurt. A tripwire is the opposite. It's an inert file

handed to you — nothing executes on your machine, nothing of yours is read,

and the only event the whole system ever produces happens somewhere else, on the

provider's side, the moment an attacker tries the key. You aren't granting

access. You're receiving a file.

Everything else about it follows from that. There's nothing to install or

integrate, so it can't break what it isn't part of. It covers code you already

shipped — the old repo, the handoff from two years ago — with no cleanup. And

it's quiet by design: no dashboard, no tuning, no weekly triage, until the day it

has something worth saying.

What it catches — and what it doesn't

A tripwire is worth setting precisely because its alert means something. So be

clear about what trips it and what doesn't.

Reading the file does nothing. Looking at the key does nothing. The alert fires

on use — when someone takes the credential and authenticates it against the

real service. That's why the false-positive rate is so low: a curious reader

generates silence, and a legitimate developer almost never points a live client

at a credential they found in a stranger's file. It isn't magic, though — a

secret scanner that validates keys, or an AI agent you hand the bundle to, can

trip it too. Those are few and easy to tell apart from a stranger in a hosting

region you've never used, and the signal is still the same: deliberate use, not

mere exposure.

Two honest limits. A tripwire reliably catches the fast, broad, automated theft

those two-minute numbers describe; a patient, targeted attacker who fingerprints

decoys can sometimes step around one. And silence is not a clean bill of health —

no alert means nobody tripped this wire, not that nothing happened.

Which is the real caveat: a tripwire does not protect you. It doesn't patch,

block, or rotate anything; it lowers the time you spend not knowing, not the odds

of getting hit. It's the wire across one doorway, not a wall around the house. So

do the rest too — MFA, real credential hygiene, scanning, all of it. The floor

isn't the ceiling. It's just that a wire you actually strung today is worth more

than a wall you'll start building "soon," and soon is the word that's kept you

at zero this whole time.

The whole thing is two steps

This part should feel anticlimactic. That's the point.

Tripwire is the version of this we built, and the whole

thing is two steps. You give an email — it's where the bundle link arrives and

where an alert would land, and that's all it's for. You download the bundle that

comes back: a

small, ordinary-looking project with realistic decoy credentials already sitting

in it, the kind that return a plausible response when someone tries them, so

they're worth trying.

Then you place it. Commit it to that abandoned side-project repo. Drop it on the

shared drive the old contractor still has access to. Paste it into the docs you

feed your coding agent. Pick the spot where a snoop would look, leave it, and get

back to work. There's nothing to run and nothing to maintain; it sits there until

someone, somewhere else, tries one of those keys for real — and then your phone

buzzes with the surface that carried it, the source, and the action.

Raise the floor

You are not going to finish securing yourself. Neither am I. The list has no

bottom, and pretending it does is exactly how it keeps winning.

So stop trying to win it today. Make the one decision you can finish instead:

refuse to be blind. String one tripwire, get back the ability to know, and then

go right back to feeling guilty about everything else on the list.

Raise the floor. The ceiling can wait.