Automating Security Review Routing on GitHub Pull Requests

Security review routing decides which pull requests need a security reviewer, sends them to the accountable owner, and blocks merge until that review happens. On GitHub, security review automation combines CODEOWNERS, required code owner review, and labels applied by path or scanner result. An automation layer then maps each finding to the person who owns it.

What Is Security Review Routing on Pull Requests?

Security review routing is the policy and automation that turns a pull request’s risk signals into the right reviewer and the right merge condition.

The volume problem is real. The Stack Overflow 2025 Developer Survey found that 84% of respondents use or plan to use AI tools, up from 76% the year before. GitHub’s Octoverse 2025 report counts 43.2 million pull requests merged per month on average, up 23% year over year.

In the Veracode 2025 GenAI Code Security Report, a controlled benchmark of 100+ LLMs, AI-generated code introduced risky security flaws in 45% of tests. That is benchmark output, not production code. Separately, DORA’s 2025 research describes AI as an “amplifier” of a team’s existing strengths and weaknesses.

If code volume grows on that curve, security review automation has to scale with it. The goal is a force multiplier for the security team you already have, with each reviewer’s time spent on the PRs that change risk.

Labels are where most teams start. Every repository starts with GitHub’s default label set, and custom labels let you encode your own categories. Standardizing those labels across teams and repositories needs a documented strategy and automation behind it.

For security, that means a security/* taxonomy every repository shares:

• security/needs-review marks a PR that requires security approval before merge.
• security/auth marks changes to authentication, authorization, or session handling.
• security/iac marks Terraform and other infrastructure-as-code changes.
• security/dependency marks changes to dependency manifests or lockfiles.
• security/approved records that the security reviewer signed off.

Which Pull Requests Need a Security Review?

The pull requests that change your risk posture need a security review, and most PRs do not.

Standards bodies leave the threshold to you. SSDF practice PW.7 in NIST SP 800-218, the Secure Software Development Framework, calls for reviewing and/or analyzing code to find vulnerabilities. The organization defines when human review applies and when code analysis is enough.

The OWASP Secure Code Review Cheat Sheet gives the diff-based version of that policy. For diff-based reviews, it tells reviewers to “Identify modified files and affected components” and to prioritize high-risk modifications. Elsewhere, the cheat sheet flags authentication, authorization, cryptography, and input handling as areas that deserve focused review.

That policy is the core of security review automation on GitHub. File paths are deterministic, so path-based routing should be deterministic too. Adapt this starting routing table to your repositories:

The last row matters more than it looks. A workflow file can change what runs with your repository’s secrets, so treat CI changes as security changes.

How Do CODEOWNERS and Branch Rules Route Security Reviews?

CODEOWNERS requests the reviewer, and branch protection or rulesets turn that review into a merge condition.

According to GitHub Docs on code owners, owners are automatically requested when someone opens a pull request that modifies code they own. Draft PRs do not trigger the request, so routing starts when the author marks the PR ready. A minimal .github/CODEOWNERS file for security paths looks like this:

/src/auth/            @your-org/appsec
/src/crypto/          @your-org/appsec
/infra/terraform/     @your-org/appsec @your-org/platform
/.github/workflows/   @your-org/appsec

A request is still only a request. The same code owners documentation explains that with “Require review from Code Owners” enabled, merge waits until a code owner approves. Approval from any one listed owner is enough.

You turn on that required review through GitHub’s protected branches settings.

Look again at the Terraform line above. Because two teams own that path, a platform approval alone satisfies the code owner requirement. List the security team alone on sensitive paths, or add a second control.

That second control is a ruleset. GitHub’s available rules for rulesets include required approvals (0 to 10) and the option to require specific teams as reviewers. GitHub also supports code scanning merge protection, which blocks merge when a required tool finds alerts at a severity you define.

As the rulesets and merge protection docs above note, availability depends on your repository type and GitHub plan, and code scanning must be enabled. For the baseline, our guide to enforcing SaaS security on GitHub recommends at least one approval on protected branches. The payoff is policy you can prove, because every gate lives in repository or organization settings that auditors can inspect.

How Do You Apply Security Labels to Pull Requests Automatically?

Create the security label set once, then let path rules and scanner results apply it so people do not have to.

Start at the organization level. GitHub organization owners can set organization default labels, which put your security/* taxonomy on every new repository created in the organization. For existing repositories, the GitHub CLI gh label create command adds a label from the terminal:

gh label create "security/needs-review" --color B60205 --description "Requires security approval before merge"

To add a label to a PR on GitHub, the GitHub CLI gh pr edit manual documents the --add-label flag. It works on one PR at a time:

gh pr edit 42 --add-label "security/needs-review,security/auth"

From a script or another tool, the GitHub REST API for labels applies labels to PRs through the issues endpoints. The add endpoint appends labels, while the set endpoint replaces all existing labels:

curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/issues/42/labels \
  -d '{"labels":["security/needs-review"]}'

For path-based labeling, the actions/labeler GitHub Action labels new pull requests based on changed file paths or branch names. It applies labels only and does not request reviewers. Pair it with CODEOWNERS, rulesets, or an automation layer that reads the label and assigns the reviewer.

Is pull_request_target Safe for Labeling Workflows?

Yes, pull_request_target is safe for labeling and triage, as long as the workflow never checks out or runs code from the PR head.

GitHub Docs on securely using pull_request_target explain the tradeoff. Jobs on this trigger receive the base repository’s GITHUB_TOKEN and its secrets, which is why labeling fork PRs works. Risk appears when a workflow checks out the fork’s code and executes it with that access.

Path-detection actions have already been a target. The CISA alert on tj-actions/changed-files describes the compromise of an Action built to detect changed files in a PR (CVE-2025-30066). The GitHub Advisory Database entry says it impacted over 23,000 repositories after attackers repointed version tags to a malicious commit.

Because tags can move, we recommend pinning every third-party action to a full commit SHA. Grant the job only the permissions labeling needs:

name: security-labels
on: pull_request_target
permissions:
  contents: read
  pull-requests: write
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@<full-commit-sha>

This is harness thinking applied to CI. Routing automation is part of your attack surface, so bound it with least privilege rather than trusting it by default.

Where Native GitHub Security Review Automation Stops

Native GitHub controls handle path-based routing well, but they stop at the edge of the repository.

A manual approach works for one repository and a small team. With multiple teams, multiple repositories, or fast growth, you need security review automation to keep labeling and routing uniform. Even then, four gaps remain:

• Findings from several scanners arrive with conflicting severities and no shared priority.
• Ownership of shared infrastructure often never makes it into a CODEOWNERS file.
• PRs labeled security/needs-review can sit unreviewed with nobody chasing them.
• No native record connects the original finding, the review, and the verified fix.

The familiar loop looks like this: figure out which findings matter, work out who owns the affected asset, open tickets, and then chase.

Our post on security automation in the SDLC shows the alternative. A Terraform PR triggers a scan and can be blocked from merging until issues are resolved.

The cost of waiting shows up in the data. The Edgescan 2026 Vulnerability Statistics Report puts average remediation time for high and critical application and API vulnerabilities at 54.81 days. At enterprises with 1,000+ employees, 37% of vulnerabilities found in a 12-month period remain unresolved.

The Verizon 2026 Data Breach Investigations Report found vulnerability exploitation was the top initial access vector, at 31% of breaches. That is up from 20% in the Verizon 2025 report, which tied part of the earlier growth to zero-day exploits against edge devices and VPNs. The lesson about unresolved findings holds either way.

How Blink Automates Security Review Routing

Blink extends security review automation beyond the PR to the full finding-to-fix loop, and humans keep approval on every PR.

Blink’s Agentic AppSec narrows scanner output before anyone is paged. It deduplicates findings across SAST, DAST, SCA, and secret scanners, then uses call-graph reachability analysis to confirm whether a vulnerability actually executes. Its Routing Agent maps each real finding to the owning service and the owning developer.

That developer gets the finding with full context in Slack or Teams. Agentic AppSec can then draft the pull request: a version bump, code change, or config fix. Case management tracks each finding from intake through verified closure, with validation through developer review, security sign-off, and a pipeline policy check.

Blink’s Workflow Studio handles the deterministic side. Workflows apply labels, request reviewers, gate pipelines, rescan, and close cases. They run across 30,000+ integrations with granular RBAC, secret management, and complete audit trails.

On GitHub specifically, the Blink GitHub integration supports 44 out-of-the-box actions. A practical starting point is the library automation that can add labels to pull requests and send the results to Slack.

Control comes from the platform, not from a prompt. Agents act inside a harness of scoped tools, isolated execution, resource limits, and circuit breakers on critical actions. You define what runs alone and what waits for a human, and irreversible actions gate on approval by default.

FAQ

What Does Security Review Mean in a Pull Request Workflow?

Security review is a check of a PR’s changes for vulnerabilities and compliance with your security requirements before merge. NIST SSDF PW.7 lets each organization decide when that means human review and when automated analysis is enough. In practice, a security reviewer approves PRs that touch high-risk areas such as auth, crypto, IaC, or CI workflows.

Do CODEOWNERS Block Merges on Their Own?

No, CODEOWNERS only requests reviews. Merge is blocked when you enable “Require review from Code Owners” through branch protection or a ruleset. Any one listed owner can satisfy that requirement, so put the security team alone on sensitive paths or require the team through a ruleset.

Can GitHub Actions Request a Security Reviewer Based on Labels?

The actions/labeler Action applies labels by path or branch name, but it does not request reviewers. To act on a label, add a workflow step or an automation layer that reads it and assigns the right reviewer. Keep that workflow least-privilege, and never run PR head code under pull_request_target.

Should Every Pull Request Get a Security Review?

No, security review automation should route by risk instead. The OWASP Secure Code Review Cheat Sheet advises identifying modified files and prioritizing high-risk changes. Send those PRs to security and let standard code review, plus required scanner checks, cover the rest.

Conclusion

Security review automation works when it routes by risk, enforces in the platform, and keeps humans on approval. Labels, CODEOWNERS, rulesets, and code scanning merge protection give you the deterministic base on GitHub.

The remaining work is connecting findings to owners and closing the loop with an audit trail. That is where Blink fits, with agents reasoning only where judgment changes the outcome and workflows executing the rest. For the broader operating model, read our explainer on what SOC automation is.

See Blink’s AI SOC in action