Add a labeler workflow with a config file that maps path patterns to labels, such as auth/** to a security-review label. Then use those labels to request reviewers or trigger extra checks. Labels route attention. They do not replace required reviews or branch protection.
What auto-labeling is for
Security reviewers cannot read every pull request, and developers cannot always tell which changes need a second pair of eyes. A path based label closes that gap cheaply. A change to authentication code, a Dockerfile, a CI workflow or a dependency manifest gets a label automatically, and the label drives what happens next.
GitHub's open source labeler action reads a file at .github/labeler.yml. The key is the label name, and the value lists match rules. Its README describes changed-files matching with options such as any-glob-to-any-file, plus base-branch and head-branch regular expression matching.
A starter config
security-review:
- changed-files:
- any-glob-to-any-file:
- 'src/auth/**'
- 'src/crypto/**'
ci-change:
- changed-files:
- any-glob-to-any-file: '.github/workflows/**'
dependencies:
- changed-files:
- any-glob-to-any-file:
- 'package.json'
- 'package-lock.json'
- 'requirements*.txt'
- 'go.mod'
The README notes that paths starting with a dot, such as .github, are matched by default in version 5 and later. It also describes a sync-labels option that removes a label when the matching files are no longer in the pull request, which keeps labels honest after a force push.
What to do with the labels
| Label | Useful action |
|---|---|
| security-review | Require an approval from the security group through your code owners file |
| ci-change | Require a second reviewer, because workflow edits can change what runs with secrets |
| dependencies | Run the dependency scan and show the result in the pull request |
A code owners file is usually the stronger control for required review, since it is enforced by branch protection. Labels then add visibility and let other automation react, for example by skipping a heavy scan when only documentation changed. Our post on one intake queue with labels and owners shows the same idea for tickets.
The trigger choice matters
Many labeler tutorials use the pull_request_target trigger so the workflow can write labels on pull requests from forks. The labeler README warns about quirks: that trigger runs from the base branch, so a pull request that introduces the labeler itself will not be labeled, and an outdated config on the base branch can fail a run. Separately, GitHub's hardening guidance says pull_request_target combined with checking out untrusted pull request code exposes the repository to compromise. A labeler only reads file names, so it does not need to check out the code. Keep it that way. We cover the risk in using pull_request_target safely.
Guardrails
- Grant the workflow only
contents: readandpull-requests: write. - Do not add a checkout step to a privileged labeler workflow.
- Review label config changes like code, because widening a pattern can silently remove review.
Safeguard can enforce policy gates on pull requests in CI, which complements path labels with actual blocking rules. Try the free scan at gold.safeguard.sh/scan.
Quick check
Can a label block a merge?
Not by itself. Use required reviews, code owners and required status checks for enforcement.
Does the labeler read file contents?
No. It matches changed file paths and branch names only.
Sources
Last reviewed: 19 October 2026.
