The fix for security review that only happens when someone remembers is not a bigger audit. It is a pass that runs on a schedule and cannot be uninstalled per project.
The team that needed it maintained a dozen live applications, each built quickly with AI-assisted development. Dependency vulnerabilities, database configuration drift and plain coding mistakes could all sit unnoticed for months. The applications were not unusually bad. The review cadence was.
The shape
Five pieces, in the order they were worth building.
A baseline and a ruleset. A written security baseline for every application, covering authentication, tenant isolation, injection, data exposure and secrets handling, and a static-analysis ruleset that encodes it. This is the part where a human decides what “secure enough” means for these systems.
A scheduled sweep of the database advisors. The hosted database already reports misconfigurations: missing policies, overly broad grants, functions running as the wrong role. Run it on a schedule across every project and turn any new finding into a ticket. Highest return for the least effort, given how much of the estate sits on the database.
A bill of materials in the build. Every build emits the list of what it depends on, stored centrally.
A nightly match against known vulnerabilities. The inventory is checked each night against public vulnerability data, enriched with whether the vulnerability is known to be exploited and how likely exploitation is. That enrichment drives the ticket priority, so a critical-sounding advisory in a package that is not reachable does not wake anyone.
Fixes as pull requests. The existing ticket-to-pull-request loop already knew how to take a well-formed ticket, branch, fix with a test, and hand back a pull request. Point it at security-tagged tickets and the loop closes: finding, ticket, draft fix, human review, merge.
The boundary that makes it safe
Detection and diagnosis are fully automated. Fixes are always authored into a pull request that a person reviews. Nothing patches production off its own signal.
That line is the same one I draw for error monitoring: automate the rollback when a build’s error rate regresses, because the failure mode is safe, and keep a human on anything that changes code.
What scanning does not find
Scanning finds known patterns. It will not find the route that skips the visibility check every other route applies, or the optional secret that fails open when it is unset, or the server-side fetch to a user-supplied URL. Those come from reading the code with a threat model in hand, in trust-flow order: authentication, then object-level authorization, then injection, then outbound calls, then secrets, then configuration that fails open.
So the continuous pass is paired with two separate exercises: a quarterly adversarial pass, where an agent is given the threat model and a staging environment and told to try to break authorization, and an annual human penetration test for anything that handles money or personal data. Different tools for different classes of bug.
What it caught
The first month’s findings were unglamorous, which is the point. Configuration drift on databases that had been set up correctly and then changed by hand. Dependencies that had been patched upstream for weeks. Issues now surface within a day rather than at the next manual review, and the same process runs for every new application the team ships, because nobody has to remember to turn it on.