In trunk-based development, developers merge small changes into the main line at least daily, so security checks must run automatically on each merge and return quickly. Run fast dependency and code checks per merge, and push slower analysis to a scheduled job so the build stays green and short.
What trunk-based development means
DORA's capability page describes it as each developer dividing their work into small batches and merging into trunk at least once, and potentially several times, a day. Branches typically last no more than a few hours, in contrast with feature branches that take days or weeks. It calls the practice required for continuous integration, and says developers are responsible for keeping the build green.
That last point matters for security. If a security check fails the trunk build, the team is expected to stop and fix it.
What belongs in the per-merge path
DORA's continuous integration page says each commit should trigger automated tests that give feedback in a few minutes, and that tests should run in a few minutes or less. Hold security checks to the same standard.
| Check | Per merge? | Reason |
|---|---|---|
| Dependency vulnerability check against known advisories | Yes | Fast, and changes with every lockfile edit |
| License and policy check on new packages | Yes | Cheap and catches problems early |
| Static analysis on changed files | Yes, if incremental | Keep it scoped to the diff |
| Full dynamic test against a running app | No | Slow, run on schedule or per release |
| Full rescan of every dependency against new advisories | Scheduled | Advisories change without any code change |
Why a scheduled job still matters
A merge-time scan is a snapshot. A new advisory can arrive tomorrow against a dependency you merged last month. Continuous trunk merging does not remove that need, so keep a scheduled or continuous monitor that rescans what you already ship.
Steps to set it up
- Make the security check a required status on trunk and on pull requests.
- Set a time budget. If the check regularly takes longer than the tests, find out why before developers learn to ignore it.
- Decide in advance what blocks a merge. Start with a narrow rule, such as known exploitable critical findings, and widen it as you trust the signal.
- Define who fixes a red trunk. DORA's agreement is that fixing the broken build takes priority over other work.
- Report check duration and failure reasons weekly.
A failure mode to avoid
If the gate is flaky or noisy, developers merge around it or batch changes into larger ones, which is the opposite of the practice. Track the false positive rate of your checks as carefully as their speed.
Quick check
Should a vulnerability always break the trunk build?
No. Block on a narrow, agreed rule and report the rest as backlog. Blocking on everything trains people to bypass the check.
Does trunk-based development need feature flags?
Often, so unfinished work can merge without being visible. They are common but not the only way.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the gate checks and what it returns to the developer.
How Safeguard fits
Safeguard offers dependency scanning with policies and gates for pull requests, plus continuous monitoring for new advisories on shipped software. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Trunk-based development: https://dora.dev/capabilities/trunk-based-development/
- DORA, Continuous integration: https://dora.dev/capabilities/continuous-integration/
Last reviewed: 19 October 2026.
