October routes thousands of first-timers to your repo. The review order that keeps CI safe (pipeline first, deps second), grep for the three exfil shapes, fork-PR secret hygiene, per-job disposable runners, and how to reject a PR kindly
First PR of the season arrived October 2nd: account three days old, title fix typo, diff mostly a typo. Mostly.
October is the month strangers send you code, and if you maintain anything with a .git directory, your queue is about to have neighbors. Beautiful — and, if you're not careful, the month your CI meets someone's cousin's script. I've been the maintainer who flinched at a malicious hunk and the first-timer whose tiny PR got reviewed with kindness. Both wrote this post. The goal isn't keeping strangers out; it's keeping the door open without leaving it unlocked.
Review order: pipeline, deps, then everything
# 1. anything that EXECUTES — a typo PR that edits workflows is not a typo PR
git diff main...HEAD --stat -- '.github/' 'Makefile' '*.mk' 'Dockerfile' '*compose*.y*ml'
# 2. dependency deltas — typosquats live here dressed as helpfulness
git diff main...HEAD -- '*requirements*.txt' 'package.json' 'go.mod' 'Cargo.toml'
# three questions per new package: who maintains it, how old is it, why this one
# 3. then everything else, at the depth its blast radius deserves
The three exfil shapes (grep them)
Most malicious October diffs aren't clever — same three shapes, different variable names:
git diff main...HEAD | grep -nE \
'process\.env|os\.environ|getenv|/proc/self/environ' # environment going somewhere
git diff main...HEAD | grep -nE \
'base64|eval\(|atob|xxd -r' # obfuscation in an unobfuscated repo
git diff main...HEAD | grep -nE \
'curl .*(-d|--data|-F)|wget |requests\.post|fetch\(' # new outbound calls
The real tell is scope creep: the mismatch between the title's promise and the diff's appetite. A fix-typo that adds a network call, a cron, or a download gets the hard look. Paranoia is vague and exhausts you; a checklist is cheap.
The safe room: fork PRs and disposable runners
- Fork PRs never see secrets. Keep the platform defaults that make this true (approval required before a fork first-timer's workflow runs; no secret exposure to forks). A stranger's first PR should execute in a room with nothing valuable in it.
- Every job gets a throwaway box. My CI runs each job in a fresh microVM — on Krova Cloud a job spins a Cube with its own kernel and no public IP, then dies:
CUBE="ci-job-$PR_NUMBER-$RUN_ID"
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# run the PR's tests inside; fork PRs mount zero secrets
krova cubes delete "$CUBE" # teardown is the security feature
A poisoned cache from a malicious build can't greet the next build, because there is no next build on the same machine. When the room is safe, review relaxes from interrogation to conversation.
Be kind on purpose (with receipts)
The three-day-old account is someone's first week in this community. The checklist handles the threat; your words handle the human:
Thanks for this! The typo fix is perfect — merging. 🎉
One note: the workflow change isn't needed for the typo, so I've
split it into its own PR where it can get a proper review.
Welcome aboard — really glad your first one landed here.
Say thanks in every review including rejects. Explain a "no" in two sentences; a silent close teaches nobody. Never talk to a first-timer like a threat actor.
The honest part
You cannot deep-review a flood. Tier it: CI/deps/scripts get the full checklist; docs and typos get a fast, grateful yes. The tiering is the practice.
Automation flags shapes; humans read intent. A perfect auto-merge tool is just a faster door.
The safe room doesn't replace review. Isolation limits what a bad PR can do; only reading limits what a bad PR can become.
Keep the door open
October's queue is a gift pile. Some gifts are typos, some are gems, one might be wired. Open all of them — just open the wired one with the right room behind you.
Top comments (0)