Required status checks: skipped results and strict mode

On GitHub, a required status check passes when it reports success, skipped or neutral. That means a security job that never ran because of a path filter can still satisfy the rule. Strict mode adds a different guarantee: the branch must be up to date with the base.

What counts as passing

GitHub's protected branches documentation says checks or commit statuses must report successful, skipped or neutral before merging. The word that surprises people is skipped.

If your workflow only triggers for certain paths, then a pull request that touches other files will not run it, and the required check is not blocking. For a dependency scan, a path filter that ignores lockfiles is a hole you should look for.

Ways to avoid the gap

• Run security checks on every pull request without path filters. The cost is some minutes of compute.
• If you must filter, add a small always running job that reports the result and make that the required one.
• Review which checks are required, not only which exist. Names can drift when a workflow is renamed.

Strict versus loose

The documentation describes two modes. Strict requires the branch to be up to date with the base before merging. Loose does not.

Strict means a check that passed against an older base is re run against the current one. That catches the case where two pull requests each pass alone and break together.

The price is rebases. In busy repos, strict mode can make everyone queue. A merge queue is one way some teams reduce that cost.

Pinning the source

You can also restrict acceptance of a check to a specific GitHub App as the status source. This stops another workflow from posting a status with the same name and turning it green. Consider it for checks that carry compliance weight.

What to require, in order

1. Build and unit tests.
2. Dependency and vulnerability scan.
3. Secret scan.
4. Static analysis, once its noise is tuned.

Add checks only when someone owns the failures. A required check nobody trusts gets bypassed.

Admin exemptions

By default admins can bypass. If your story to an auditor is "every change passed these checks", then bypass use should be rare and visible. See dismiss stale approvals for the matching approval rule.

Safeguard policies and gates can evaluate a pull request on dependency findings and report a result you can require. A free scan of your dependencies is available at gold.safeguard.sh/scan.

A quick audit you can do today

List your required checks in the branch settings. For each one, open the workflow file and read its trigger. Does it have path filters? Does it run on pull requests from forks? Does it have a condition that can skip the job entirely?

Then open three recent merged pull requests and look at the check list. If a security job shows as skipped on a pull request that changed dependency files, you have found a gap. Fixing it usually means removing a filter or adding a small summary job.

Quick check

Sources

• GitHub Docs: about protected branches

Last reviewed: 19 October 2026.