Log inSign up

How to check pull requests merged to main branch?

Tags: Application security DevSecOps Risk assessment
TL;DR

Track merged PRs and code review behavior

To check pull requests merged to the main branch, start by filtering your GitHub repo’s PR history by branch and status. Use the GitHub UI or API to find PRs where base: main and is: merged. Then review author and reviewer activity to ensure GitHub review pull request practices are consistently followed.

With Sola, you can create an app or use our AI assistant to track merged PRs across all your repos. You’ll get full visibility into who is merging code, which reviews were skipped, and where potential risks might be introduced.
Build with Sola

Sola apps that could help you

Visit the App Gallery
Visit the App Gallery

How to monitor merged PRs and review behavior

1. Filter merged pull requests by branch

In the GitHub interface, go to Pull Requests, then switch to Closed, and filter by is:pr is:closed base:main is:merged and look for merged PRs.

Use GraphQL with states: MERGED and baseRefName to get merged PRs, and fetch fields like author, mergedBy, reviews, and reviewDecision. Filtering by reviewer or approval requires custom logic after retrieval (or using the GitHub REST Search API). With Sola’s AI assistant for GitHub security posture, these data points are automatically collected, analyzed, and visualized, saving you the time of building custom queries.

2. Review gaps in code review practices

Key issues to look out for PRs with no reviews at all (you can search with review:none to find merged PRs that had no reviews at all). If branch protection rules require reviews, GitHub will block such merges, but without them, these cases can slip through.

These behaviors can indicate that review policies are being skipped or ignored. Sola flags these cases so you can investigate patterns and enforce proper separation of duties.

3. Detect security gaps in merged code

Some merged PRs can indicate deeper security issues. Be on the lookout for:

  • PRs where security checks (SAST, DAST, secret scanning) were skipped or failed – GitHub lets you skip workflows (e.g. [skip ci]), but if those checks are marked required in branch protection, the PR can’t be merged until they run. Skipped or missing checks are only a risk if they aren’t enforced as required.
  • Changes to sensitive files, such as access control configurations or credentials – use a CODEOWNERS file with branch protection (“Require review from Code Owners”) to enforce that these files can’t be merged without review from the right people.
  • Missing security labels or bypassed workflows – labels don’t bypass checks by default; that only happens if your repo’s own CI/CD pipeline is set up that way. Similarly, workflow bypasses usually mean admin overrides or misconfigured protections, which you should audit.

Sola highlights these issues so you can quickly focus on high-risk pull requests and address process breakdowns.

Why this matters for GitHub security

Merged PRs show you how your team really operates. If code is landing in your main branch without adequate review or security checks, you’re leaving the door open for silent vulnerabilities. Monitoring this activity is critical to securing your SDLC.

Use AI to monitor GitHub pull request activity

Sola helps you automate pull request auditing at scale. Create your own monitoring app, or use the AI assistant to analyze review quality, contributor behavior, and security gaps across all GitHub repositories.

Answer more security questions