Trunk-based development usually lowers risk when it comes with fast automated tests, quick reviews and a way to hide unfinished work. Without those, it simply moves breakage to main faster. The practice is not a security control, but it makes many real controls easier to run.
What it is
DORA describes trunk-based development as a version control practice where developers make small changes and merge them into the main line at least once a day. Branches live for hours, not days or weeks. It is also described as a required practice for continuous integration, where automated tests run on every commit.
DORA's research associates a few habits with higher performance: three or fewer active branches, merging to trunk at least daily, and no code freezes or integration phases.
How it helps security
Smaller diffs get read. A change merged within a day is a small change. See the pull request size guidance for why that matters.
Fixes ship at the same pace as everything else. When your normal path to production is fast, a security patch does not need a special process. A team that releases monthly has to invent an emergency lane for each vulnerability, and emergency lanes skip checks.
Fewer long lived branches. A branch that lives for three weeks drifts from main, misses dependency updates, and merges as a large blob nobody reviews well.
How it can hurt
DORA names three pitfalls that apply directly:
- Heavyweight code review. Several required approvals discourage small changes. People batch work, reviews get large, and defects slip through.
- Asynchronous review delays. Slow reviews raise the chance of merge conflicts.
- Skipping pre-commit tests. If tests do not run before merge, trunk breaks, which erases the benefit.
Add a security pitfall of our own: merging half built features that expose a new endpoint. Unfinished work must be hidden, which is what feature flags are for. A hidden code path still needs to be safe to ship, because it is in the build.
What you need before you try it
- A build and test run that finishes in minutes. DORA notes that slow builds can point to architectural problems.
- Branch protection on main, with required status checks.
- A review habit measured in hours. DORA suggests tracking how long approvals take.
- A flag or switch convention for unfinished features.
- A rollback path you have tested, so a bad merge is a short event.
Measuring it
Track active branch count, how often branches merge, how often you freeze code, and time to review approval. If branch age keeps growing, the practice is not really in place, whatever the policy says.
If your merges are frequent, your dependency changes are too. Safeguard's SBOM and dependency scanning can run on each change so a new vulnerable package is flagged at the pull request. The free scan is at gold.safeguard.sh/scan.
Quick check
Does trunk-based development mean no code review?
No. DORA recommends review, ideally done synchronously when the code is ready, so it does not queue.
Is it safe for regulated teams?
It can be, provided review, required checks and change records remain in place. The practice changes batch size, not whether controls exist.
Sources
Last reviewed: 19 October 2026.
