A white belt's first month in jiu-jitsu goes like this. They watch a black belt armbar someone in a competition video. They show up to class. Somewhere in the middle of their first roll, they see the armbar lying there — their training partner's arm extended at the wrong angle, in reach, available. They grab it. They throw their leg over. They commit. The arm comes free. The training partner sweeps them. They end up on bottom side control. They tap to a shoulder lock ninety seconds later.

The lesson is "position before submission." It is the most-repeated cliché in jiu-jitsu, and it is a cliché because it is true. The arm was there. It was catchable. But the position was wrong — the white belt didn't have hip control, the leg was loose, the head was free, the elbow was the wrong way relative to the body. Submission attempts from bad positions don't fail because the technique was wrong; they fail because the position wasn't earned.

The hierarchy is something like: back > mount > side control > knee on belly > guard > half guard > full guard > the position you're worried about. Position is what gives a submission room to work. The submission is the consequence of position. You don't reach for the consequence first.

I think about this a lot in security work, because security work has the same shape.

The exciting thing and the boring thing

Most security organizations want to do the exciting thing. Threat hunting. Red teaming. Machine-learning-based anomaly detection. Hunting APTs across the East Asian regional VPN concentrators. There is a conference circuit, a community, and a Twitter discourse around the exciting thing. Recruiters use the exciting thing in job postings. Vendor booths at RSA use the exciting thing as the lead visual.

The boring thing is asset inventory. Knowing what computers you own. Patch management. Pushing this month's CVEs out before they're exploited. MFA enforcement on every login, including the legacy ones. Log centralization with retention you can actually search. Principle of least privilege on the dozen service accounts that nobody's audited in three years. Backup, and — critically — tested restore. Incident response runbooks that have actually been run.

Every one of these is the security equivalent of position. You cannot threat-hunt effectively if you do not know what assets you own. You cannot analyze anomalies if your logs are not centralized. You cannot red-team effectively if half your endpoints don't have basic hardening. The exotic controls all assume you've earned position. If you haven't, the exotic controls don't work, in the same way the armbar doesn't work from the wrong angle. You will still tell yourself you have an EDR. You will still tell yourself you have threat hunters. But the work isn't doing what you think it's doing, because the position underneath it isn't there.

What we built first

The grapplers.club codebase has a build order that more or less follows this discipline. Walking through it chronologically is more instructive than walking through it by feature.

The first five hundred lines of worker.js are not features. They are positions. Specifically:

This is what the first commits look like. None of it is a feature. None of it is what a member or an admin sees. None of it generates a screenshot worth posting. Every one of these is the platform's version of mount and side control — the position that everything else gets built on top of.

The operational side has its own positions. A cron job on a Debian server runs backup.py nightly, pulling snapshots of both KV namespaces and the R2 bucket through the Cloudflare REST API. The Debian server itself is backed up to an encrypted NAS. The NAS mirrors offsite. So the snapshot chain runs prod → Debian → encrypted NAS → offsite mirror, three tiers with no single point of failure. Restore has been exercised. restore.py is not a wish.

The features came after. RSVPs, training logs, sparring challenges, the throwdown board, the technique library, the missions system, the gamification. All of those are submissions. They work because the position is there.

What we did out of order

This is the honest part. Position-first is the discipline; nobody actually executes it perfectly. The grapplers.club build has its own list of submissions-reached-before-position-was-earned:

Each of these is a submission-attempt-from-poor-position. Each is going to bite eventually. The list exists so the bites are not surprises.

Why it's hard

Both in jiu-jitsu and in security, the appeal of skipping position is real. The submission is dramatic. The position is invisible. A black belt mounted on top of a smaller white belt and crushing them for four minutes before the tap is not what a casual fan came to watch. The casual fan wants the flying triangle. They want the leg lock from outside reaper hooks. They want the heel hook that finishes in nine seconds.

Security has the same problem. Promoting "we hardened our IAM policies this quarter" does not make a great LinkedIn post. Promoting "we caught a sophisticated APT exfiltrating data through DNS tunneling" does. The reward systems — internal recognition, external résumé bragging rights, board-level attention — all flow toward the submission and away from the position.

The black belt knows this and trains the position anyway. They drill side-control maintenance for three years before they ever try a flashy submission. They get bored. They keep going.

The senior security engineer knows this and patches the endpoints anyway. They write the runbooks. They run the tabletop. They get bored. They keep going.

What to actually do

If you are starting a security program — at a startup, at a new role, in a new team — and you have a hundred items on the backlog, here is the position-first heuristic:

  1. Inventory. You cannot defend what you cannot enumerate. Endpoint list, account list, service list, third-party list. All of them. With owners.
  2. Authentication. Email and password is not authentication. MFA enforced on every account that matters. Single sign-on where possible.
  3. Patching. Every endpoint, every service, every container image. With an SLA.
  4. Logging. Centralized, retained for a meaningful window, with at least one human who can search it.
  5. Backup AND tested restore. Both halves.
  6. Least privilege. Service accounts, IAM policies, database users. Audit them. Strip what is not used.
  7. Incident response runbook. Written down. Practiced annually. With names and phone numbers.

Only after these are in place do you reach for the threat hunter, the EDR, the SIEM, the deception platform, the ML-based anomaly system. Those are submissions. They will not work unless the position is there.

The order is not negotiable. The order is the entire point.

Where this lands

This is the third article in a small series. The first one — zero npm packages — was about subtraction as a feature: by removing one class of risk (transitive dependencies) the residual threat surface fits in your head. The second one — what we don't track — was about subtraction again: by not collecting behavioural data, the privacy surface fits in your head.

This one is about order. It is not that there is one trick or one omission that makes a platform secure. It is that the things that look unglamorous — auth, CSP, output encoding, rate limits, cross-tenant isolation, asset inventory, patching, backups — have to come before the things that look exciting. If you do them in the wrong order, the exciting things are decorative. The submission you can land from a bad position is not really a submission; you got lucky. The threat hunter who is finding things in an environment with no patch program is not really hunting; they are cleaning.

Position first. Submission later. The order is the discipline. The discipline is the work.

I should probably have stopped at the WhatsApp group.