Q&A · Security
Every dev tool wants access to our GitHub org. How do we decide which ones to trust?
Every vendor in your stack asks for the same thing on day one. Here is how we would decide who gets it.
Nythrex team · 10/29/2026
The question
Asked by an engineering manager · the way we usually hear it
“Our security lead now blocks new GitHub integrations by default. I understand why, but we genuinely need a few of them. Is there a sane checklist that isn’t just ‘say no to everything’?”
Short answer
Judge every tool by three things: what it reads, what it keeps, and what an attacker gets if the vendor is breached. Prefer read-only access, the narrowest scope, no code contents unless the job truly needs them, and tokens you can revoke in one place. A tool that never receives your code cannot leak it.
Two incidents worth remembering
April 2022. GitHub found that an attacker was using stolen OAuth user tokens issued to two integrators, Heroku and Travis CI, to list organisations and download private repositories from dozens of organisations, including npm. GitHub believed the attacker was searching the downloaded code for secrets to reach other infrastructure. The tokens were not stolen from GitHub; they were stolen from the integrations.
March 2025. Attackers retargeted version tags of the popular GitHub Action tj-actions/changed-files to a malicious commit that printed CI secrets into workflow logs. More than 23,000 repositories used the action. The issue was tracked as CVE-2025-30066 and fixed in v46.0.1. Teams that had pinned the action to a commit SHA were not exposed to the retargeted tags.
Five questions for any integration
| Ask | Good answer | Red flag |
|---|---|---|
| What does it need to read? | Read-only, scoped to the repositories it serves | Write or admin access “just in case” |
| Does it receive code, diffs or prompts? | Only if its job requires them | A metrics tool that copies whole repositories |
| Where is data stored, and how? | Named region, encryption, named subprocessors | “In the cloud” |
| How are tokens stored and revoked? | Encrypted, revocable from one place | No clear answer |
| What happens when someone leaves? | Their access ends with their membership | Personal tokens keep working |
What we’d do this quarter
- 1
Inventory what already has access
List the OAuth apps and GitHub Apps installed on the organisation, and who authorised them. Most teams find something nobody uses. - 2
Prefer narrow, revocable access
Choose integrations that ask for read-only access to specific repositories over broad user tokens. - 3
Pin third-party Actions
Reference Actions by commit SHA, not by a tag that can be moved — the lesson of tj-actions. - 4
Ask for the data flow in writing
What the tool receives, what it stores, where, and for how long. A vendor that can’t answer in a page has not thought about it. - 5
Review and revoke
Once a quarter, remove what is unused. The safest integration is the one you no longer have.
Where Nythrex helps — and where it doesn’t
How it is built
Nythrex has read-only access to each source and receives commit and pull request metadata — SHA, author, time, branches, size of change — not code contents, diffs, files or prompts. OAuth tokens are stored encrypted with keys in Azure Key Vault, data is stored in Azure Poland Central (EU), and removing a member revokes their AI tool tokens.What it doesn’t claim
Nythrex doesn’t claim SOC 2 or ISO 27001 certification. Its security page lists the measures that actually run in the product, and you can ask for a security call.
Sources
Frequently asked questions
How do I decide whether to grant a tool access to our GitHub organisation?
Check what it needs to read, whether it receives code, diffs or prompts, where and how it stores data, how its tokens are stored and revoked, and what happens when a member leaves. Prefer read-only access scoped to specific repositories.
What happened in the tj-actions/changed-files incident?
In March 2025 attackers retargeted version tags of the tj-actions/changed-files GitHub Action to a malicious commit that printed CI secrets into workflow logs. More than 23,000 repositories used the action; it was tracked as CVE-2025-30066 and fixed in v46.0.1.
Does Nythrex read our source code?
No. Nythrex has read-only access and receives commit and pull request metadata such as SHA, author, time, branches and size of change. It does not receive code contents, diffs, files or prompts.
Read next
- Nythrex security: metadata only, read-only, encryptedHow Nythrex protects data: read-only access to sources, no code or prompts stored, tokens encrypted with keys in Azure Key Vault, isolated workspaces.Read
- Nythrex GDPR and compliance: EU hosting and subprocessorsGDPR roles, data stored in Azure Poland Central (EU), subprocessors, retention periods, deletion and data subject rights at Nythrex.Read
- Nythrex integrations: GitHub, Jira, Azure, Claude Code, CodexWhich sources Nythrex connects, exactly what it reads from each and with which permissions. One read-only authorization per source.Read
Stop guessing.
Start seeing.
No card and no subscription: paid plans have not launched yet.