GitHub
Use brin in GitHub Actions to check contributor trust and scan pull requests for security threats
Integrate brin into your GitHub CI pipeline with Actions workflows that automatically check contributor trust and scan pull requests for security signals.
##Contributor checks
Add a workflow that queries the brin contributor API for every PR author. It labels PRs as contributor:verified or contributor:flagged and posts a detailed comment when review is recommended.
###What it does
When a pull request is opened, reopened, or updated, the workflow:
- Queries the brin contributor API for the PR author's trust score
- Applies a label —
contributor:verified(safe) orcontributor:flagged(needs review) - Posts a comment with threat signals, dimension breakdown, and a link to the full profile when flagged
- Cleans up the comment automatically when a previously-flagged contributor is re-evaluated as safe
###Workflow
Create .github/workflows/contributor-check.yml in your repository:
###How it works
The workflow uses pull_request_target so it has write access to add labels and comments, even on PRs from forks. It runs in two steps:
- Query the brin API — calls the contributor endpoint with
details=true&mode=fullto get the full trust profile for the PR author. If the API is unreachable, it falls back to an empty JSON object and exits gracefully. - Label and comment — ensures
contributor:verifiedandcontributor:flaggedlabels exist, applies the appropriate one, and posts a detailed comment on flagged PRs with threat signals and a dimension breakdown. The comment uses an HTML marker to find and update itself on subsequent runs.
The concurrency setting ensures only one check runs per PR at a time. If a new commit is pushed while a check is in progress, the running check is cancelled and replaced.
###Blocking merges on flagged contributors
Add a branch protection rule that requires the "Scan PR author" status check to pass. The workflow always succeeds (it labels rather than fails), so to enforce a merge block you can add a step that exits with a non-zero code when the verdict is not safe:
##PR security scan
Add a workflow that scans the entire pull request in a single API call through the brin PR API. This analyzes the PR author's identity, the aggregate diff, PR metadata, and runs LLM-powered threat detection — all in one request.
###What it does
When a pull request is opened or updated, the workflow:
- Calls the brin PR endpoint with the repository and PR number
- Waits for the full 3-tier scan to complete (author identity, diff analysis, LLM review)
- Posts a comment when the PR is flagged as
suspiciousordangerous - Fails the check if the score is below 30 or the verdict is
dangerous
###Workflow
Create .github/workflows/pr-scan.yml in your repository:
###How it works
The workflow calls the brin PR endpoint (/pr/owner/repo/number) with mode=full, which runs a complete 3-tier analysis:
- Tier 1 — Author identity: account age, contribution history, org memberships, prior commits to the target repo
- Tier 2 — Behavior and content: PR review status, diff analysis across all changed files, secret detection, agent config tampering, CI workflow changes, PR description injection patterns
- Tier 3 — LLM-powered analysis: reads the full diff, PR description, and author profile to detect sophisticated threats (triggered conditionally based on risk signals)
The mode=full parameter makes the API wait for all tiers to complete before responding. The workflow only needs a single API call — no checkout, no commit iteration.
If the PR is flagged:
- A sticky comment is posted with the score, verdict, and threat details
- The comment updates itself on subsequent runs instead of creating duplicates
- The check fails if the score is below 30 or the verdict is
dangerous - The comment is automatically removed when the PR becomes clean
###Combining with contributor checks
You can run both workflows in the same repository. They operate independently — contributor checks evaluate the PR author's profile, while PR scanning evaluates the actual code changes and PR metadata. Together they provide defense in depth: even a trusted contributor's compromised account would be caught if the PR contains malicious patterns.
On this page