The honest answer is continuously, but that's unhelpful without saying what runs when.
On every pull request
This is the one that matters. Scan the diff, not the repository, seconds rather than minutes, and the findings are about code the author wrote this morning.
Cost of fixing scales with how long the code has existed. A finding on an open pull request is a change to work in progress. The same finding three months later is an incident, a rollback plan and an argument about priority.
Nightly, full repository
Diff scanning only sees what changed. Some issues only appear in combination. New code interacting with old code, and a full scan catches those.
Run it against main overnight where it can take as long as it needs. Nobody's waiting on it.
On every dependency change
Separate trigger, different reason. New CVEs get published against libraries you already use, so your risk changes without your code changing at all.
Dependabot or equivalent handles this automatically. Enable it and let it open pull requests.
Where "quarterly" comes from
Periodic scanning is a compliance artefact. Some frameworks ask for evidence of regular vulnerability assessment, and quarterly satisfies the letter of it.
It's a poor security cadence and a reasonable audit one. If you're scanning on every pull request you're comfortably exceeding what quarterly requires, and the pipeline record is better evidence than a scheduled report. It shows every change was checked, not that someone ran a tool four times a year.
What actually breaks this
Not the schedule. The backlog.
Scan frequency only matters if findings get resolved. Teams that scan on every commit and never fix anything are in the same position as teams that scan quarterly, with more dashboards.
Two things keep it honest. Baseline existing findings so the gate only fails on newly introduced ones, otherwise every pull request goes red and someone disables the check. And attach an owner and a deadline to the backlog, or it grows indefinitely.
The gap between finding and fix is where most scanning programmes fail, and no amount of scanning more often closes it. That's the part Kolega works on: findings arrive with a reviewable fix attached rather than as work for someone else's sprint.