Make a check default on when it is accurate, fast, and covers a risk that applies to nearly every repository. Make it opt in when it is noisy, slow, or only relevant to some stacks. Start new checks in report only mode, then promote them once the signal is proven.
The trade off
Default on gives you coverage without asking each team. The cost is that a poor check lands on everyone at once. Opt in gives you willing users and better feedback. The cost is gaps: the teams that most need a check are often the ones that never turn it on.
Neither is right everywhere. The decision turns on four properties of the check.
Four questions
- Is it accurate? If most findings are dismissed, it is not ready for default on.
- Is it fast? A check that adds many minutes to every pull request needs a good reason. See how fast should a pull request dependency scan be.
- Does it apply to almost every repository? Dependency scanning does. A check for a specific framework does not.
- Is the action obvious? If developers need training to respond, onboard them first.
A simple decision table
| Check | Accurate | Fast | Broad | Suggested default |
|---|---|---|---|---|
| Dependency inventory | Yes | Yes | Yes | On |
| Known vulnerable dependency, new in this change | Mostly | Yes | Yes | On, blocking for new high risk only |
| Framework specific code rule | Varies | Varies | No | Opt in until tuned |
| Full code scan with many rules | Varies | Slow | Yes | On in report only, trimmed rule set |
| Experimental rule | Unknown | Unknown | Unknown | Opt in |
Treat the table as a starting point and adjust to your own measurements.
Use a ladder rather than a switch
A staged approach avoids the binary choice.
- Opt in pilot with two volunteer teams. Collect dismissal reasons.
- Default on, report only. Show findings, never block.
- Default on, block new high risk. Existing findings go to owners.
- Tighten. Add rules or lower the threshold only if the data supports it.
Each step needs a named owner and a review date.
Keep an escape hatch
Every default on check should allow a dated exception. A team that cannot opt out of a broken check will find another way, such as disabling the whole pipeline step. Our post on a flag that disables a control explains why unmanaged switches defeat the point, so keep exceptions visible and time limited.
Do not forget new repositories
Defaults should apply to repositories created tomorrow, not only to today's. Use organization level settings or templates so a new repository starts with the baseline checks.
What to tell developers
Say what is on by default and why, what it blocks, and how to ask for an exception. Surprises create opposition. Clear, early explanations create cooperation.
Safeguard's policies and gates let a team choose where a check runs and whether it blocks, and the free scan at gold.safeguard.sh/scan shows what a baseline would flag in an existing repository.
Quick check
Is opt in ever enough?
For experimental or narrow checks, yes. For baseline controls that auditors or customers expect, opt in leaves gaps.
What if developers push back on a default?
Look at their evidence. If the check is noisy, tune it. If the objection is about effort, make the fix cheaper.
Last reviewed: 19 October 2026.
