Security review does not keep up with AI-assisted development unless it is automated, and “we review quarterly” means findings sit for a quarter. This is the pass I run: a few days to set up, runs without anyone remembering, and hands a person a reviewed fix rather than a scary email.
The principle
Detection and diagnosis are automated. Fixes are always a pull request a human reviews. Nothing patches production from its own signal. The logic lives centrally, in one place every project uses, so it cannot be forgotten or uninstalled per project.
Build order
Build it in this order. Each step is useful on its own, and the earlier ones are certain to pay. Click a step for the detail.
1. A security baseline and a ruleset. Decide once what secure means, then encode it as rules that run on every pull request.
Write down what secure means for your applications: authentication (tokens verified, algorithms pinned, admin gates that fail closed), tenant isolation (every object scoped to its caller before read and write), injection (parameterized everywhere, including dynamic fragments), outbound calls (no server-side fetch to a user-supplied URL without scheme and host validation), secrets (nothing to the client or logs, optional secrets fail closed), and jobs (cron endpoints require a secret and fail closed when it is unset).
Encode as much of that as possible in a static-analysis ruleset that runs in CI on every pull request. This is the step where a human decides the standard; everything after is machinery.
2. A scheduled sweep of the database advisors. Highest return for the least effort.
If you run on a hosted Postgres with built-in advisors, they already report missing policies, overly broad grants and functions running as the wrong role. Schedule the check across every project, store the results centrally, and create a ticket for any new finding. Configuration drift from hand edits is exactly what it catches.
3. A bill of materials from every build.
Each CI build emits its dependency inventory and stores it centrally. Nothing else changes yet.
4. A nightly match against vulnerability data. Priority driven by risk, not severity labels.
Every night, query the inventory against a public vulnerability database. Enrich each hit with two signals: whether it is on a known-exploited list, and its exploit likelihood score. Those two drive ticket priority, so an advisory in a package that is not reachable or has never been exploited becomes a low ticket, not a page.
5. Point the fix loop at security tickets. The loop must never merge its own work.
If you already have a loop that takes a well-formed ticket, branches, writes a test-driven fix and opens a pull request, point it at tickets tagged security. If you do not, build that loop first; it pays for every class of ticket, not only security.
What the pass will not find
Scanning finds known patterns. It does not find the logic flaw: the route that skips the visibility check every other route applies, the optional secret that fails open, the side effect that lets a caller grant themselves access. Those need a reader with a threat model. Two exercises sit beside the continuous pass:
- A quarterly adversarial pass. Give an agent the threat model and a staging environment with throwaway accounts, and let it try to break authorization. Static analysis probes patterns; this probes logic. Own apps only, staging only, never a third-party platform you merely integrate with.
- An annual human penetration test for anything that handles money or personal data. For an agency this is a liability question as much as a security one.
The static read, when you do it
When a human or an agent reads for security, read in trust-flow order rather than wandering: authentication, then routes and handlers, then the data-access layer, then schema and migrations, then every outbound call, then configuration and secrets, then background jobs.
Prioritize by impact: no-identity access first, then cross-tenant access, then injection, then outbound forgery, then secrets, then fail-open configuration. Report each finding as where, mechanism, exploit steps, minimal fix. List what was cleared as well as what was hit. The full read is its own playbook.
Costs and cadence
Setup is on the order of a week for the baseline and ruleset, and days for the rest. Running cost is the CI minutes and a scheduled job.
| What | When |
|---|---|
| Ruleset | every pull request |
| Database advisors | weekly |
| Inventory match | nightly |
| Adversarial pass | quarterly |
| Human penetration test | annually |
What it caught in the first month
Unglamorous things. Databases set up correctly and then changed by hand. Dependencies patched upstream weeks earlier. A function running as its owner rather than its caller. Each surfaced within a day of being introduced rather than at the next manual review, and each arrived as a pull request with a test.
Changelog
- 2026-09-05: first version.
- 2026-09-08: build-order steps collapsed to one-liners; cadence made a table; short version added.