2 min read

Building an AI-native security pipeline for Stokum.net

Building an AI-native security pipeline for Stokum.net

I wrote before about the zero-trust architecture behind Stokum, encrypted tunnels, JWT auth, row-level tenant isolation, no implicit trust based on network location. That part's been running quietly for months now. It works.

But "the infrastructure is secure" was never the whole job. Fifteen years of AppSec taught me that architecture is only half the story, the other half is what happens to the code before it ever reaches that architecture. Every PR, every dependency bump, every Terraform change is a decision point, and most teams (mine included, historically) only catch the bad ones some of the time, usually late, usually manually.

So that's what I've been building lately: an AI-native security pipeline that sits directly in CI/CD and treats SAST, DAST, SCA, IaC scanning, Threat Modeling, and Code Review as defaults. The objective here is developer enablement: building a paved road with zero friction where security doesn't slow down the loop, but instead happens automatically on every push, with an AI agent doing the reasoning on top of the raw scanner output.

A few decisions I made early on, and why:

Self-hosted, not SaaS. Stokum already runs on infrastructure I control, an edge box on Linode tunneling into a local cloud running on repurposed hardware at home. The security pipeline lives there too. No sending source code to a third-party scanning service, no per-seat SaaS pricing, no vendor lock-in. Just open-source scanners (Semgrep, Trivy, Checkov, ZAP) doing detection, and an AI agent doing triage, prioritization, threat modeling, and review on top.

Gitea: My primary repos live on a self-hosted Gitea instance, and I wanted the pipeline to work there natively rather than assuming GitHub. Gitea Actions turned out to be close enough to GitHub Actions syntax that almost nothing had to change, the AI agent step is just another job in the workflow, calling out to an LLM API, reading scanner output, and posting findings back as a PR comment.

One reasoning layer, not four vendor "AI" add-ons. Rather than paying for the AI-powered version of each individual scanner, I run the deterministic scanners as-is and route all of their output through a single orchestrating agent. It reads the diff, reads the findings, filters the noise, ranks what's actually exploitable, and. when the change touches auth, data storage, or a network boundary, writes a short threat note before a human ever has to ask for one.

None of this is finished. The scanning stage is solid; the AI triage layer is in active development; the threat-modeling automation is still rough. But the shape of it is real, it's running against my own production app, and I'm learning the same lesson I learned building Stokum itself: every security decision looks different when you're the one implementing it, at 11 PM, watching your own CI pipeline turn red.

More on the actual pipeline design, the Gitea workflow file, and what the AI agent gets right (and wrong) in the next post. including how I'm tackling production runtime security and LLM guardrails next.