Audit

Our systems are small enough to be read end to end. This page shows exactly how we prove it.

Why this page exists

We promise audits in days, not quarters. Promises need proof, so this page is our public commitment: every claim here is backed by a concrete artifact from the SRARS audit evidence kit. Where a number is still being measured, we say so — we do not publish estimates as facts.

The audit checklist

Every SRARS system can be verified against this checklist. Each item maps to a real, inspectable artifact — not a document written after the fact. The artifacts below are from this very website.

  • Explicit data model. The full schema is a handful of readable SQL migrations: posts and contact messages in 002_site_content.sql, admin users and sessions in 003_admin_auth.sql. Every column is named, typed and commented.
  • Typed contracts. Every page is a generated Go function (Templ): a template that does not compile is a build that does not ship. Data flows through plain structs — handler fills, component renders, nothing implicit.
  • Observable behavior. The metrics strip in this site's footer is the live sample: request and error counts, latency percentiles, unique visitors and uptime, published by the server itself every five seconds.
  • Complete change trail. Migrations are append-only and recorded by name in schema_migrations: any database state can be traced back to the exact migration that produced it. Admin writes are session-gated and CSRF-validated.
  • Minimal attack surface. The production image is built FROM scratch: no shell, no package manager, no interpreter — one static binary, CA certificates and timezone data, running as non-root (uid 65532). There is nothing inside the container to pivot to.
  • Reproducible builds. One command goes from source to static binary: make build (CGO disabled, trimmed path, stripped symbols). The same command produces the same binary on any machine with the Go toolchain.

Measured verification time

The claim: a full audit of an SRARS system takes days, not quarters. This site has already been through two verification cycles:

  • External review: an independent security review of the whole codebase, container and auth model, by a reviewer with no prior familiarity with the codebase — the worst case for audit time. Scope: SQL injection, XSS, CSP, password hashing, sessions, CSRF, rate limiting, proxy header trust, IDOR, container hardening and dependency versions. Result: zero critical or high findings; three medium and two low, all fixed in the same session. The full report is in the repository (docs/SECURITY.md).
  • Production hardening cycle: a second verification pass at launch: automated vulnerability scan (govulncheck) found ten standard-library CVEs — upgraded and re-scanned to zero; the admin password was rotated to a 256-bit secret with argon2id parameters hardened (128 MiB, two passes); edge protection (HSTS preload, Cloudflare Access on the admin surface) was added and verified live against every admin route.
  • Regression evidence: launch-day fixes (a soft-404 in the router that served pages with HTTP 200, a stale cache-bust version that pinned clients to a broken stylesheet) are covered by regression tests in the repository — the same class of bug cannot silently return.

Both cycles were measured in days, not quarters — the external review in one session, the hardening pass in one afternoon. The codebase is small enough that one person re-verifies it end to end in an afternoon. That is the audit promise, demonstrated.

The change trail

Every mutation in an SRARS system is recorded: who, what, when and why. On this site, the trail is structural:

  • Schema changes are append-only migrations, recorded by name — the database itself is the change log.
  • Content changes (posts, sections, projects) go through the admin area: argon2id session, CSRF token on every write, numeric-parsed IDs.
  • Code changes live in version control with the generated templates committed — every rendered page traces back to its source.

Run it yourself

The strongest audit evidence is a system you can inspect without us in the room. SRARS systems are single static binaries with embedded databases: clone, build, run, verify.

  • Public repository: github.com/WhoseBiasDoYallSeek/fgoths-framework — the framework that generates systems like this one.
  • Build command: make build — one command from clone to a static Linux binary in bin/app.
  • Verification walkthrough: the data model is database/migrations/*.sql; the security report is docs/SECURITY.md; the design methodology is docs/DESIGN.md; the tests run with go test ./...