Adopt It Yourself

VibeSecOps isn't proprietary. If you want to build with AI without it degrading into vibe coding, here's the practical playbook.

VibeSecOps isn't a product or a secret. It's a discipline anyone can adopt, and we'd rather the practice spread than keep it to ourselves. If you're building with an AI coding assistant and want the speed without shipping the bugs a first-year intern would catch, here's the playbook.

The ten practices

1. Write down the rules before the first commit, not after. Rules are far easier to enforce when they predate the code. A CLAUDE.md (or the equivalent for your assistant) that the AI reads before every session is the foundation.
2. Make the rules machine-checkable wherever possible. A lint rule beats a written sentence; a CI job beats both. Anything you care about, turn into a check that fails the build.
3. Treat documentation as code. Threat model, architecture decisions, security notes — update them in the same change as the behavior they describe. Documentation tied to the code can't drift for long.
4. Enforce branch protection from day one, even solo. Zero required reviewers is fine when you're the only developer. The value is the mandatory check suite, not the review ceremony — and your own commits should be subject to it too.
5. Run more than one scanner. A filesystem scanner and an image scanner disagree sometimes, and the disagreement teaches you what's actually shipping. A single scanner is a single point of failure.
6. Document accepted risks explicitly; never suppress them. When a finding can't be fixed yet, record what it is, why it isn't reachable, the upstream tracker, and a review-by date. A suppressed finding is invisible and rots; an accepted risk is visible and has a deadline.
7. Turn every bug fix into a regression test — especially security bugs. The test is the only thing that reliably stops the same bug from shipping twice.
8. Push back on your assistant, specifically. "That's a rule suppression and we don't do those" is far more useful than "no, try again." And when the pushback reveals a gap, make it a durable rule so the next session can't repeat the mistake.
9. Be honest about the gaps. If your test coverage is incomplete or a control is only partially implemented, say so. That honesty is exactly what makes the parts you have finished credible.
10. Understand what you ship. If you can't explain why a change is correct, don't merge it — regardless of which AI wrote it. This is the rule the other nine exist to support.

Start from the repository

The Vibe Sec Ops repository has a rulebook template, two complete reference pipelines (Bun/TypeScript and Go), includable GitLab CI/CD components for every gate above, and the accepted-risk, POA&M and triage templates. Section 8 of its METHOD.md is the afternoon-sized version of this page.

The one-line version

Where it can go wrong

The honest failure modes, so you can watch for them:

• A rulebook nobody enforces. If violations don't fail a build, the rulebook is a wish. Wire the checks.
• Verification theater. Skimming an AI diff and clicking merge is not verification. Read it, reproduce the claims, run the pre-flight yourself.
• Silent suppression. The moment "make the warning go away" becomes acceptable, unreviewed code has a path to production. Ban suppressions and grep for them in CI.
• Confusing "passes the type-checker" with "correct." Type-safe code can still be wrong. The human judgment is the point, not the formality.

Questions and critique welcome

VibeSecOps is the result of trial and error across our Bedrock platform and our Railway-hosted products — it will keep evolving. If you think a particular practice is still vibe coding because of some gap we've missed, we want to hear it. Reach us through the vulnerability disclosure and contact page.