DEV Community: Anmol Maheshwari

We Built a Hackathon Platform Where Every Rule Lives at the Layer That Can't Be Bypassed

Anmol Maheshwari — Sun, 04 Oct 2026 13:08:26 +0000

Hackathon Raptors gave every team at DOGFOOD 2026 the same brief and 72 hours: build the submission-and-judging platform they would actually run. The winner gets forked into production.

We're a team of two. Our submission is Dogfood — 9 Spring Boot microservices behind a gateway, a React frontend, PostgreSQL with Row-Level Security, RabbitMQ for the async event mesh, Redis, MinIO, and a judging engine built around z-score normalization with Bayesian shrinkage.

This is the question we kept returning to while building it:

Where is this rule actually enforced?

Not "does the UI hide the button." Not "does the frontend route guard redirect you." Where in the stack does the rule live, such that bypassing it is architecturally impossible?

That question shaped every significant decision we made — including which tools we reached for and why.

Hiding a rule is not the same as enforcing it

The hackathon spec says it plainly: role isolation must be enforced in the backend, and if it only works because the UI hides a button, it does not work.

The naive version of "judges can't see each other's scores" is a frontend route guard plus a controller that trusts a judge_id from the request body. Anyone with curl and a valid token can swap the ID and get another judge's scores back.

We enforce it twice, and the second layer is the one that matters:

Layer 1 — Application: every score query filters by judge_id taken from the verified JWT claim (X-User-Id injected by the gateway), never from a request parameter.

Layer 2 — Database engine: PostgreSQL Row-Level Security keyed on a session variable set from that same claim before every query:

SET LOCAL app.current_user_id = '<uuid-from-jwt>';

CREATE POLICY judge_own_scores ON judging.scores
  USING (
    judge_id = current_setting('app.current_user_id')::uuid
    OR current_setting('app.current_role', true) IN ('ORGANIZER', 'ADMIN')
  );

Even if the application code has a bug, the PostgreSQL kernel silently drops rows that don't belong to the requesting judge. The acceptance suite's T2 check — judge cannot see peer scores — passes not because we wrote a special case for it, but because the rule lives at a layer that the request can't talk its way around.

The deadline is a domain constraint, not a UI feature

A deadline shown in the frontend is a suggestion. A deadline checked against a client-sent timestamp is a suggestion with a race condition.

The Submission Service enforces the cutoff on the server with a Redis distributed lock (SETNX) and compares against the event's stored deadline using server time. The client's clock is never trusted. A submission attempted after the deadline is rejected regardless of client clock skew or network latency.

The rule lives where authoritative time lives.

The math problem hiding inside score averaging

Consider three judges scoring the same projects:

Judge A (Generous): scores 8, 9, 10. Mean = 9, StdDev = 1.
Judge B (Harsh): scores 2, 3, 4. Mean = 3, StdDev = 1.
Judge C (Neutral): scores 4, 6, 8. Mean = 6, StdDev = 2.

Project X gets a 9 from Judge A, a 4 from Judge B, and an 8 from Judge C. Raw average: 7.0.

But look at what those scores actually mean relative to each judge's baseline:

Judge A's z-score for X: (9 - 9) / 1 = 0 — exactly average for them
Judge B's z-score for X: (4 - 3) / 1 = +1 — above average for them
Judge C's z-score for X: (8 - 6) / 2 = +1 — above average for them

Normalized average: +0.67. Judge A gave the highest raw score but contributed zero ranking signal — it was just their baseline. Judge B gave a low raw score but it was actually a positive signal relative to how they score everything.

This is what per-judge, per-criterion z-score normalization does:

z = (raw_score − judge_mean) / judge_std_dev

It corrects both a judge's central tendency (hawk vs. dove) and their spread (a judge who clusters scores in a narrow band). Min-max scaling only fixes the range — z-score corrects central tendency too.

Bayesian shrinkage: what to do when a judge has only reviewed 2 projects

Z-scores have a failure mode: a judge with 1 or 2 reviews gives you noisy estimates of their own mean and standard deviation. If that judge happens to draw a genuinely strong project, their normalized score can swing the leaderboard disproportionately.

We apply Bayesian shrinkage with k₀ = 5 to handle this:

λ = k / (k + 5)

z_shrunk = λ × z + (1 − λ) × global_mean

Judge with 1 review: λ = 1/6 ≈ 0.167 — their score is dampened 83.3% toward the global consensus mean.
Judge with 15 reviews: λ = 15/20 = 0.75 — only 25% dampening, their calibration is trusted.

One edge case handled explicitly: a judge who gives every project the same score has σ = 0, causing division by zero in the z-score formula. We set σ = 1.0 in that case, which maps all their scores to z = 0 and contributes zero ranking signal. This is a verified invariant in NormalizationEngineTest.java.

The hawk/dove proof falls out cleanly: if Judge A (mean 8, σ 1) and Judge B (mean 4, σ 1) both score a standout project at +2σ above their own baseline (Judge A gives 10, Judge B gives 6), both produce z = +2.0. Their leniency difference becomes mathematically irrelevant.

Catching pre-built projects without shelling out

One integrity problem most platforms we studied don't address: a team builds most of the project before the event, pushes to a private repo, then makes one commit during it. The submission looks legitimate.

The Submission Service runs an in-memory Eclipse JGit scan on every submitted repository URL and records a risk score:

0 commits                           → risk 100  (EMPTY_REPOSITORY)
1 commit                            → risk 80   (SINGLE_COMMIT_DUMP)
>90% commits before event start     → HIGH      (PRE_HACKATHON_CODE)

Two decisions worth explaining:

Pure Java, no shell commands. Running git clone with a user-supplied URL is a command-injection surface. Eclipse JGit in a Java memory buffer removes it.

A signal, not a verdict. The scanner puts anomalies in an organizer review queue and never auto-disqualifies. A one-commit repo might be a legitimate solo build with poor git habits. Detection belongs to the machine; the decision belongs to a human.

Why not a monolith? Why RabbitMQ? Why Redis?

Fair questions for a 72-hour hackathon, where the simpler choice is usually the right one.

On microservices vs. monolith: the decision wasn't about scale. At fixture size — 40 projects, 30 judges — a well-structured monolith would have been fine. We split into services because the security boundaries are real and need to be structural, not just logical. The Submission Service must not be able to touch the judging schema. The Judging Service must not be able to write to submissions. When those concerns share a codebase and a connection pool, you're trusting developer discipline to maintain the boundary. When they're separate services with separate Flyway-managed schemas and no shared connection, the boundary is physical. You can't accidentally cross it.

On RabbitMQ: score submission is a write path that needs to stay fast, especially in the final hour of an event when judges are racing the deadline. If submitting a score also triggered synchronous re-normalization across all scores for the event, that write would slow down as the event grew. Instead, the score commits to PostgreSQL and publishes a score.submitted event to the dogfood.events topic exchange in under 50ms. Normalization recompute, audit log write, webhook dispatch, and notification all happen asynchronously on their own queues — audit.queue, certificate.queue, webhook.queue, notification.queue. The judge gets a fast response regardless of what follows.

On Redis: two separate jobs. The Voting Service rate-limiter uses a Redis token-bucket per IP/account — Redis's atomic increment operations make this correct under concurrency in a way a database counter isn't, without the lock overhead. The submission deadline lock uses SETNX because it needs to be atomic and shared across any instance of the Submission Service. Both are cases where Redis does something PostgreSQL can technically do, but with better latency and simpler concurrency guarantees for their specific access patterns.

What the architecture diagram doesn't show

Our README has an ASCII diagram of all 9 services. What it doesn't show is that the diagram is the output of one question asked repeatedly: where does this rule live, and can someone get around that layer from outside?

Deadline enforcement → Redis lock on the server, not a client timestamp
Score isolation → PostgreSQL RLS at the kernel, not a route guard
Score fairness → Bayesian normalization in the judging engine, not a post-event spreadsheet
Commit integrity → in-memory JGit at submission, not an organizer eyeballing GitHub profiles
Webhook trust → HMAC-SHA256 signed payloads, not plain HTTP callbacks
Concurrency safety → RabbitMQ decoupling, not synchronous blocking writes

The microservices weren't the goal. They fell out of keeping each rule in the layer that owns it.

The moment the architecture pushed back

One thing no diagram captures: docker compose up ran out of resources on a local machine.

By the time all containers were up, the stack was consuming 3.13GB of RAM on a 7.4GB host and peaking at 1376% CPU across 12 cores — all before a single HTTP request had landed. Nine Spring Boot services each with their own JVM heap, plus PostgreSQL, RabbitMQ, Redis, and MinIO, adds up fast.

We moved to a cloud shell instance, which was only possible because my teammate had a student subscription. Without it, we would have been cutting services under time pressure.

That's an honest cost of the microservices decision, and we'd rather say it than hide it. The fix — capping each service's JVM heap with -Xmx in the Compose file — is straightforward. Most of these services don't need 512MB each at hackathon scale. But we ran out of time before we could tune it, and the spec asks for something that runs on a laptop. Ours runs, but comfortably only on a machine with enough headroom, and that's worth saying plainly.

What we claimed and what we proved

.dogfood.toml claims T1 and T2. The acceptance suite verifies exactly that — 7 of 7 checks passing:

T1  gallery is public ................. PASS
T1  project from fixtures shown ....... PASS
T1  closed event refuses submissions .. PASS
T2  judge sees own scores ............. PASS
T2  judge cannot see peer scores ...... PASS
T2  participant blocked ............... PASS
T2  csv export works .................. PASS

claimed T1 T2, verified T1 T2

Quadratic voting, Ed25519-signed certificates, the OpenAPI spec, and bulk export are implemented, but the acceptance suite doesn't cover them, so we don't claim them in .dogfood.toml.

A judging platform that is vague about what it can prove is hard to trust. We tried to be exact about our own limits.

Repo: github.com/codewisp-ai/DogFood
Stack: Java 21 · Spring Boot 3.3 · PostgreSQL 16 · RabbitMQ 3.13 · Redis 7 · MinIO · React
License: MIT · docker compose up -d

Built for DOGFOOD 2026 by Hackathon Raptors. #Dogfood2026

My "reproducible" build kept returning the same hash after the code changed. That was the bug.

Anmol Maheshwari — Sat, 05 Sep 2026 15:01:12 +0000

TL;DR: I built ZeroTrust — a supply-chain security scanner, zero third-party dependencies, go.mod with no require block — for the Zero Dependency Hackathon (Track E). It catches phantom packages, typosquats, lifecycle-hook backdoors, obfuscated payloads, and eval()-style dynamic execution. The scanner passed every test I wrote for it. Three times, my own verification process tried to hand me a result that looked correct and wasn't. This is what a tool built to catch deception looks like when it nearly deceives its own author.

The dependency that couldn't be the point

You already know why this hackathon exists if you've read the brief: chalk and debug, 2.6 billion combined weekly downloads, one phished maintainer account, a crypto-clipper hiding in memory. Shai-Hulud republishing itself into hundreds of packages days later. xz, two years of patient trust-building, one code review away from a backdoor on every Linux server on earth. And now the newer, quieter version of the same problem: AI coding assistants hallucinate package names 19.7% of the time, and attackers have started pre-registering the names the models reliably invent — a supply-chain attack where the victim never even makes a typo, because the machine makes it for them.

So I built the tool that's supposed to catch exactly that — and I built it with an empty manifest, because a security scanner that asks you to trust more strangers to protect you from strangers has already lost its own argument.

$ cat go.mod
module zerotrust
go 1.22

$ go list -m all
zerotrust

That's the entire dependency tree. Everything else — a Bloom filter, a prefix Trie, a TOML tokenizer, a rate limiter, ANSI terminal styling, a SARIF 2.1.0 emitter — is hand-rolled against Go's standard library. Eleven substitutions, each with its own entry in STDLIB.md, because a claim like "zero dependencies" is worthless if it isn't also checkable in under five seconds.

That instinct — don't just claim something, make it checkable — is what turned this into a much more interesting three days than "write five detectors and call it done."

Five detectors, one honest question underneath all of them

ZeroTrust runs five checks, offline by default: phantom-package detection (Bloom filter + Trie against a curated, provenance-documented corpus), typosquat detection (hand-rolled Levenshtein distance), lifecycle-hook scanning (the exact mechanism Shai-Hulud used), Shannon-entropy scanning for obfuscated payloads, and lexical detection of dynamic-execution calls (eval, child_process.exec, os.system).

Every one of those detectors exists to answer one question: is this thing actually what it claims to be?

Which made it uncomfortable, in a useful way, when my own build pipeline started asking me the same question back.

Bug 1: the reproducible build that lied by staying the same

make verify-reproducible builds the binary twice and diffs the hashes. Simple, and it passed — the same hash, every single time I ran it, across multiple sessions:

A6DB0B58130997745CFF9798B0FDCF6BBD28DE03910F1F0E34BDB0AB6472E985

That should have felt like success. It felt wrong instead, for a reason that took me a while to name: real code had changed in between those checks. JSON output landed. SARIF emission landed. Severity-aware exit codes landed. A reproducible build is supposed to mean identical source → identical bytes — it is emphatically not supposed to mean the hash never moves no matter what I do to the source. One of those is determinism. The other is a build that isn't actually rebuilding what I think it's rebuilding, or is embedding something that has nothing to do with my code.

It was the second one. Since Go 1.18, go build stamps the current git commit hash and a timestamp into the binary by default — vcs.revision, vcs.time — unless you explicitly pass -buildvcs=false. My "stable" hash wasn't proof of a clean build. It was a coincidence of which git commit happened to be checked out at each of my testing sessions.

The proof that this was really it: I made a doc-only commit — zero code changes, just Markdown — and rebuilt.

14D9E8B23FF9786D54F7F82764CCC8B587F9E59E97743026DFBD74226FC6714D

Different hash. From a commit that changed nothing but a README. If a Markdown edit can move your "reproducible" hash, the hash was never measuring what the bonus claim says it measures.

Fixed with one flag, everywhere the binary gets built:

makefile
go build -trimpath -buildvcs=false -ldflags="-buildid= -s -w" -o ./bin/zerotrust .

And a final, actually-trustworthy pair:

Build 1 SHA256 (windows): D112B856931D9473E5DF7EC6175E4412FA8D0CE8F76FAF5AE7E6C0438ACB1E9E
Build 2 SHA256 (windows): D112B856931D9473E5DF7EC6175E4412FA8D0CE8F76FAF5AE7E6C0438ACB1E9E
REPRODUCIBLE BUILD VERIFICATION: PASS

Still identical. But now I'd earned the right to say so, because I'd also watched it correctly fail to be identical when it should have — the doc-only-commit test is what turned "the hash matches" from a hope into an actual falsifiable check. A reproducible-build claim you haven't watched break is a build you haven't actually verified — you've just watched a coincidence hold twice.

Bug 2: the safety claim I couldn't check on my own machine

go test -race ./... is how I back up "no data races in the concurrent worker pool." On my own Windows dev machine, it didn't run at all:

cc1.exe: sorry, unimplemented: 64-bit mode not compiled in

The race detector needs CGO, CGO needs a working 64-bit C compiler, and my local MinGW toolchain was 32-bit-only. For a real stretch of this build, "the race detector passes" was a claim I genuinely could not verify on the machine I was developing on. Not a cosmetic annoyance — a security tool's own concurrency-safety claim, unverifiable, on the platform I was actually shipping from.

I didn't fix the toolchain. I changed which environment got to answer the question:

bash
docker run --rm -v ${PWD}:/app -w /app golang:1.22 go test ./... -v -race

Clean pass, real Linux, real ELF binary, real 64-bit cc. Then a third, fully independent confirmation once the repo was pushed — GitHub Actions' own ubuntu-latest runners, green on every push since:

ok      zerotrust/tests 5.756s

Same source, three separate environments, one of which genuinely couldn't tell me the answer at all. The lesson isn't "Windows is bad" — it's that a claim your own dev machine can't check is a claim you don't actually have yet, no matter how confident the surrounding code looks.

Bug 3: the validator output that was lying about what it validated

I claimed a real SARIF 2.1.0 subset, so I ran Microsoft's own sarif-multitool validate against it — the point being that "the JSON parses" and "a schema validator accepts this as real SARIF" are different claims, and only one of them is worth putting in a README.

The first attempt produced output I couldn't actually trust, and the reason was almost funny: the pasted validator output had ZeroTrust's own startup banner mixed into it — a stray line from the tool being validated, sitting inside what was supposed to be the validator's independent verdict. Contaminated evidence. I genuinely couldn't tell from that run whether sarif-multitool had validated anything or whether I was reading noise.

I caught it because the contaminating line was visibly out of place — it didn't belong to the tool that was supposed to be running. That's the same instinct the entropy scanner runs on every payload it looks at: something in this stream doesn't match what it claims to be.

Redo, deliberately isolated — generate the file to disk first, run the validator as a fully separate step, nothing interleaved:

bash
./bin/zerotrust --path . --format sarif > results.sarif
sarif-multitool validate results.sarif
# exit code: 0

Clean. Trustworthy, this time, because I'd removed the thing that made the first result unreadable rather than just re-running it and hoping for a cleaner-looking paste.

What I'm not going to pretend happened

Three real bugs is a true story. Five would be padding, and this hackathon specifically rewards naming your limits rather than hiding them — so here's what didn't have drama, stated plainly instead of dressed up:

The entropy threshold (7.2 bits/byte) was correct on every run I checked. No tuning story, no wrong version I quietly fixed. If there's an origin story for that exact number, I don't have one to tell you.
The tokenizer's blind spot (globalThis'ev'+'al' defeating lexical pattern matching) is a real, honestly-documented limitation — but I reasoned my way to it, I didn't watch it fail in front of me. Different kind of claim, and I'd rather say so than imply I caught it live.
The Bloom filter's false-positive rate measured 0.0449 against a <0.05 target on the very first check and every check after. No wrong m/k calculation I had to walk back.
Skipping the Single File bonus was a clean, upfront decision — the project's actual shape (four manifest parsers, two hand-rolled data structures, five detectors, a rate limiter, three output renderers) was never going to collapse into one file without sacrificing the test isolation and idiomatic package boundaries a senior Go reviewer would expect. I didn't start down that path and bail. I never started down it.

A write-up where every single corner has a dragon in it stops being credible around the third dragon. Some corners were just fine. Saying so is worth more than inventing tension that wasn't there.

By the numbers

$ go test ./... -v -race
...
--- PASS: TestBloomFilterFalsePositiveBound (0.03s)
    bloom_test.go:52: Actual false positive rate: 0.0449 (target: 0.0500)
...
PASS
ok      zerotrust/tests 5.756s
0 third-party runtime dependencies (go list -m all prints one line: zerotrust)
2,489 lines across 28 Go files

15/15 tests passing, race-detector clean, verified independently across Windows-hosted Docker Linux and GitHub Actions' ubuntu-latest
11 documented stdlib-for-package substitutions in STDLIB.md, each on the runtime path — none decorative
6 real attack-pattern findings caught in under a second against a seeded malicious fixture — phantom packages, typosquats, and a curl | sh postinstall hook
1 reproducible-build hash that was wrong for reasons that had nothing to do with the algorithm I thought I was testing
The thing worth taking from this

A scanner built to catch things pretending to be something they aren't spent its own build process doing exactly that to me, three separate times: a hash that looked stable because it wasn't actually being regenerated against new source, a safety guarantee my own machine was incapable of confirming, and a validation result contaminated by output that didn't belong to the tool producing it.

None of those were subtle attacks. They were the ordinary, boring failure mode of trusting the first result that looks clean. The entire pitch of this hackathon is that removing dependencies doesn't remove the need for engineering judgment — it just means every piece of that judgment is visibly yours, including the parts where you almost believed something that wasn't true.

The tool's job is to stop trusting things by default. Turns out that had to start with not trusting my own green checkmarks either.
GITHUB REPO
Built solo for the Zero Dependency Hackathon 2026, Track E (Security & Crypto Utilities). Repo, STDLIB.md, and deps-proof.txt are all public — the reproducible-build command is in the README if you want to try breaking it the way I did.

ZeroDependencyHack #Go #Security #SupplyChain #Testing #BuildInPublic