Code Security Audit — Redacted Sample

What this is. A sanitized excerpt of an internal self-audit — we ran our own code through our attack-first review method ("dogfooding"). Target identifiers are redacted; the methodology, findings, severities and data-flow traces are verbatim. This is a representative sample of a client deliverable, not a marketing mock-up.

Why "attack-first + falsification" matters (the method)

Most scanners optimise for recall — they surface everything that pattern-matches a weakness and leave you to sort signal from noise. We optimise for precision under an adversary: every candidate must survive a step whose only job is to disprove it.

Recon ─▶ Parallel Hunt ─▶ Adversarial Falsify ─▶ Capability Filter ─▶ Independent Verify
 map     many hypotheses    "prove this is NOT     "is it reachable    read-only grader,
 sinks   in parallel         real" (default:        by a real actor?"   different context
 & inputs                    refuted)                                    (maker ≠ grader)

On this run the falsification step dropped 2 of 10 candidates as false positives (see Falsification drops below). A verified-only report is worth more than a long one: you spend remediation budget on real defects, not on triage.

Trust model (this is what caps severity)

The service binds 127.0.0.1 only (gateway.py:475) and authenticates every route except /health with a single shared install token X-Api-Token (secrets.token_urlsafe(24), constant-time compare :273). There is exactly one principal — any local process holding the token — so no cross-tenant boundary exists. This caps every finding: "read/write any task" is the authenticated baseline, and blast radius is one loopback host. The highest-value finding (F-001) is principal-independent (attribution spoof + destructive), hence Medium; everything else is Low. Honest scoping beats severity inflation.

Summary

Each finding shipped with a static PoC and an exploit test (written, not run).

Findings

F-001 — Answer spoofing + forced deletion of any pending task

The fix — shipped & re-tested the same day (identifiers redacted, logic verbatim):

  # POST /answer handler
- # any caller could answer ANY id — existence unchecked, author hardcoded
- append_reply(author="worker", reply_to=req["reply_to"], text=req["text"])
+ # a reply must answer a real, still-OPEN request — everything else is refused
+ if read_request(reply_to) is None:      # no such open request  -> 404
+     return 404
+ if already_answered(reply_to):          # can't double-answer    -> 409
+     return 409
+ append_reply(author="worker", reply_to=reply_to, text=text)

Re-test after the fix: the spoof path now returns 404 and appends nothing; a pending request survives the cleanup sweep (it can no longer be forced into the "answered" set by an attacker). Both prongs — attribution spoof and forced deletion — close at the same guard. Time from confirmation to verified fix: same day.

F-002 — next_id() TOCTOU race

F-003 — Unbounded request-body read (/submit, /upload)

F-004 — Unbounded base64 attachment decode + disk write (/upload)

F-005 — Unbounded request-body read (/answer)

F-006 — Global rate-limit shared-budget DoS

F-007 — Unauthenticated /health triggers filesystem scrub

F-008 — Auth token in cleartext file + stdout

Resolved input inventory (completeness artifact)

A finding list is only trustworthy if it also proves what was checked and cleared. Every externally-controlled input was traced to a disposition (redacted field names):

All inputs resolved. Findings not tied to a single input (concurrency, global rate-limit, zero-input /health) are captured as F-002 / F-006 / F-007.

Not found / excluded (checked-but-clean classes)

• Injection (SQL / command / code / SSTI / deserialization): 0 hits for eval / exec / subprocess / pickle / yaml.load / os.system in production paths.
• Path traversal (file ops): SAFE — id sanitizer strips separators before any join.
• IDOR (cross-principal): not expressible — single shared-token principal; "read any task" is the authenticated baseline (this is why it's excluded, not overlooked).
• XSS / open redirect / SSRF: no HTML render sink, no user-controlled outbound origin, no redirect sink.
• AuthN bypass: every non-/health route enforces a constant-time token compare; no skip-auth branch exists.

Sweep verification (did we catch every instance of each root cause?)

Every root cause maps 1:1 onto the findings — no orphaned instances.

Code quality / defense-in-depth (not exploitable as-is, but worth hardening)

Falsification drops (the candidates we killed)

Two hypotheses reached the adversarial step and were refuted — reported here on purpose, because what a scanner discards is as diagnostic as what it keeps:

• Cross-principal IDOR — false positive on a single-principal model; the path-traversal prong was independently blocked by the id sanitizer. Dropped.
• Unlocked ledger append — the torn-write self-heals (unparseable lines are skipped on read); subsumed by the concurrency finding F-002. Dropped as a standalone.

One-line honest summary

A tightly-scoped local service with a single real design defect (F-001) and a cluster of routine hardening gaps — 1 Medium, 7 Low, zero inflation, two false positives caught before they reached the report. That is what a verified deliverable looks like.

Redacted sample · attack-first review · read-only mode · maker ≠ grader.

Remediation — what happened after this report

The report above is a snapshot of the run on 2026-07-19 and is not rewritten. This is the addendum: what was changed, when, and how the change was checked. Verification was done by a pass written against each fix — maker ≠ grader applies to the repair too.