FOR APPSEC TEAMS USING GITHUB SECURITY

Get through a crowded GitHub Security queue faster.

Pyre is a Chrome extension that works inside the GitHub Security page. It adds a review label and a short reason beside each visible finding, and puts similarly named findings together so your team has a consistent place to start.

No new dashboard. Nothing is hidden by default. Vulnerability details stay in your browser.

GitHub Security
GHSA-xxxxRemote code execution in lodashCritical
GHSA-yyyyPrototype pollution in minimistHigh
GHSA-zzzzReDoS in expressMedium
GHSA-aaaaInformation disclosure in axiosMedium
GHSA-bbbbPath traversal in tarLow
GHSA-ccccXSS in markedHigh

+ 128 more findings

GitHub Security with Pyre
Review First

Remote code execution in lodash

GitHub severity: CriticalPublished advisory
Check Context

Prototype pollution in minimist

GitHub severity: HighTitle contains "prototype"
Routine Review

ReDoS in express

GitHub severity: Medium
Routine Review

Information disclosure in axios

GitHub severity: Medium
Review Later

Path traversal in tar

GitHub severity: LowMatches one of your rules
Check Context

XSS in marked

GitHub severity: High

Illustration: the same GitHub Security queue before and after Pyre adds review labels and reasons.

The queue is visible. The order of review is not.

GitHub gives your team the findings, severity, and advisory details. But when a repository has dozens of High and Critical items, reviewers still have to decide where to begin.

Different reviewers start in different places

Without an agreed first-pass convention, each person scans and sorts the queue differently.

Similar findings are reviewed one by one

Findings with related-looking titles can be spread across the page, making the initial review more repetitive.

Sorting happens before investigation

AppSec time is spent reading titles and severity labels before anyone can decide what to open first.

Pyre changes the working view, not the underlying findings.

Open github.com/{owner}/{repo}/security as usual. Pyre adds a review label beside each visible finding, the page details and team rule behind that label, a suggested review action, and a side panel for findings with similar titles. After reviewing the proposed labels, you can temporarily hide Review Later findings from your working view. GitHub’s findings, severity labels, and source data remain unchanged.

143

example findings

12

similar-title groups

4

review labels

0

hidden by default

Security - 143 advisories
GHSA-xxxxRemote code execution in lodashCritical
GHSA-yyyyPrototype pollution in minimistHigh
GHSA-zzzzReDoS in expressMedium
GHSA-aaaaInformation disclosure in axiosMedium
GHSA-bbbbPath traversal in tarLow
GHSA-ccccXSS in markedHigh
GHSA-ddddOpen redirect in passportMedium
GHSA-eeeeDenial of service in wsLow

+ 135 more advisories...

Security - with Pyre labelsPyre active
Review FirstCritical

Remote code execution in lodash

GitHub severity: Critical · Published advisory

Check ContextHigh

Prototype pollution in minimist

GitHub severity: High · Title contains "prototype"

Routine ReviewMedium

ReDoS in express

GitHub severity: Medium

Routine ReviewMedium

Information disclosure in axios

GitHub severity: Medium

Review LaterLow

Path traversal in tar

GitHub severity: Low · Matches one of your rules

Check ContextHigh

XSS in marked

GitHub severity: High

Routine ReviewMedium

Open redirect in passport

GitHub severity: Medium

Review LaterLow

Denial of service in ws

GitHub severity: Low

Every finding remains visible when the page first loads

Example queue: every finding remains visible by default, with similarly named findings shown together in the side panel.

Pyre helps with the first review. It does not determine actual risk.

Pyre uses

What is visible on the GitHub Security page, the rules your team sets, and any label changes you make in Pyre.

Pyre does not know

Whether a dependency is reachable, exploitable, running in production, owned by a specific team, or important to the business. It does not pull dependency graphs or cross-repository context through the GitHub API.

Pyre gives the team a consistent first-pass review order. Your engineers still decide what affects the environment and what should be remediated.

GitHub stays in control.

Pyre changes only the working view in your browser.

  • Pyre does not change, dismiss, close, or assign findings in GitHub.
  • Nothing is hidden when the page first loads.
  • Before hiding Review Later findings, Pyre shows you exactly what would disappear from the working view.
  • High and Critical GitHub findings are never hidden.
  • You can show everything again at any time, change the label on any finding, or turn Pyre off for the page.
  • Grouping similar titles never removes findings from GitHub’s list.
  • If Pyre cannot confirm that it has checked the full page, it hides nothing.

What the current pilot supports

The GitHub repository Security overview at /{owner}/{repo}/security.

Dependabot, code-scanning, and secret-scanning subpages may show limited labels. Pyre never hides findings on those pages.

The current pilot does not cover GitHub Issues, pull requests, Jira, Snyk, SonarQube, or findings across multiple tools.

Vulnerability details stay in your browser.

Pyre reads the visible GitHub Security page locally. It contacts api.usepyre.com only to sign users in and check access to the pilot using the work email, pilot code, and session token. Vulnerability titles and advisory details are not sent to model providers.

Pyre is delivered through an unlisted Chrome Web Store listing. Your team can review and approve it through its normal browser-extension process.

How Pyre works

01

Open GitHub Security as usual

Pyre appears on the repository Security overview your team already uses. There is no separate queue or dashboard.

02

Pyre reads what GitHub has loaded

Pyre uses the visible title, severity, GHSA ID, published-advisory markers, and the rules your team has approved.

03

Each finding gets a review label

Review First. Check Context. Routine Review. Review Later. The same four labels appear across the queue.

04

Review the reason and change it when needed

Open the reason to see which page details and team rules led to the label. Reviewers can change a label or restore the full queue at any time.

Example finding

GHSA-xxxxCriticalReview First

Remote code execution in lodash

Why this label

  • · GitHub severity: Critical
  • · Published advisory
  • · Title contains "remote code execution"

Suggested review action

Open this before the other findings currently shown on the page.

Four labels for a consistent first pass.

Give reviewers the same starting categories without moving the work out of GitHub.

Review First

Open this before the other findings currently shown on the page, based on GitHub severity and your team’s rules.

Check Context

Worth a closer look. Your team still decides whether the finding affects your environment.

Routine Review

Leave it in the queue for normal review. No current rule moves it ahead of the rest.

Review Later

Handle it later or with similar findings. It remains visible unless you choose to hide it.

See whether Pyre improves your team’s first pass.

Run Pyre for two weeks on selected repositories with up to five reviewers. We will compare the existing review process with the Pyre-assisted view and examine where the labels helped, failed, or were changed.

Pilot details

Duration
2 weeks
Price
$500 USD
Users
Up to 5
Scope
One GitHub organization, selected repositories
Workflow
GitHub Security overview
Delivery
Unlisted Chrome Web Store extension
Support
Founder-led onboarding and end-of-pilot review
Access
Approved work email + founder-issued pilot code

What your team does

  • Approve the extension through your normal browser or security process
  • Choose up to five users and the repositories included in the pilot
  • Review the starting rules before hiding any Review Later findings
  • Complete a short baseline timing exercise before using Pyre
  • Join an end-of-pilot review

How the pilot is evaluated

We look at how long the initial review takes, whether the labels match reviewer judgment, which labels people change, whether the hide rules remove anything the team wants to keep visible, and whether reviewers continue using the overlay.

Request a Two-Week Pilot

We will first confirm that your GitHub Security workflow fits the current pilot. Browser or security approval may be required.

Security FAQ

What permissions does the extension request?
Local storage, access to GitHub pages, and access to api.usepyre.com for sign-in and licence checks.
Does Pyre read source code or GitHub tokens?
No. Pyre reads only the visible DOM of the GitHub Security overview page you have open.
Can we restrict or revoke access?
Yes. Customers can allowlist Pyre through Chrome enterprise policy, and access can be revoked for individual users.
What email can pilot users sign in with?
An approved work email and a pilot code issued by the founder. Personal email addresses are not accepted.
SOC 2?
Pyre does not currently claim SOC 2 compliance.

Read the full security and permissions details

Make the first pass through GitHub Security more manageable.

Pyre adds review labels, short reasons, and similar-title groups to the GitHub Security page your team already uses.