Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/morwn/github-threat-detector/llms.txt

Use this file to discover all available pages before exploring further.

Social engineering attacks against open-source repositories don’t always leave the obvious fingerprints of malicious code injection. They often start subtly: a new contributor whose very first action is to modify a CI workflow file, a maintainer account that quietly adds a new collaborator with write access, or a private repository made public — potentially exposing secrets embedded in commit history or configuration files. The three rules in this category are designed to surface these quieter indicators before they escalate into full-compromise events.

​
new-actor-ci-change

Severity: high
Required data: Events only

​
What it detects

A contributor whose very first recorded event in the repository is a PushEvent or PullRequestEvent that touches a file under .github/workflows/, and where that workflow-touching event occurs within 1 hour of their first recorded event overall. This is the hallmark of an account created or invited specifically to inject malicious workflow steps.

​
How detection works

The analyzer computes each actor’s first-seen timestamp per repository, then joins against push and pull request events that mention /.github/workflows/ in their payload. Any event where the timestamp is within 3600 seconds of the actor’s first_seen time is a finding. 
WITH first_events AS (
    SELECT actor_login, repo_name, MIN(created_at) AS first_seen
    FROM github_events
    GROUP BY actor_login, repo_name
),
workflow_events AS (
    SELECT id, repo_name, actor_login, created_at, payload
    FROM github_events
    WHERE event_type IN ('PushEvent', 'PullRequestEvent')
      AND payload::text ILIKE '%/.github/workflows/%'
)
SELECT we.*
FROM workflow_events we
JOIN first_events fe
  ON we.actor_login = fe.actor_login
 AND we.repo_name = fe.repo_name
 AND abs(extract(epoch from (we.created_at - fe.first_seen))) < 3600

​
Finding description

First-time contributor <actor_login> touched workflow files within 1h of first activity

​
Evidence fields

FieldDescription
created_atTimestamp of the workflow-touching event
A new contributor whose first action is to edit a workflow file is a high-confidence social engineering indicator. Legitimate first-time contributors almost never start with CI changes — this pattern is consistent with an attacker who has been granted collaborator access specifically to insert a malicious workflow step.Remediation: Require code owner review for all changes to .github/workflows/. Add a CODEOWNERS entry like:
.github/workflows/ @your-org/security-team
This ensures no workflow change can be merged without an explicit approval from a trusted reviewer, regardless of the contributor’s permissions.

​
member-added-suspicious

Severity: medium
Required data: Events only

​
What it detects

A MemberEvent with action: added, indicating that a new collaborator has been added to the repository. This rule emits a finding for every such event, providing an audit trail of collaborator additions that can be reviewed for unauthorized access grants.

​
How detection works

The analyzer queries directly for member-addition events with no additional filtering beyond the event type and action. All collaborator additions are surfaced, regardless of who performed the addition. 
SELECT id, repo_name, actor_login, created_at, payload
FROM github_events
WHERE event_type = 'MemberEvent'
  AND payload->>'action' = 'added'

​
Finding description

Actor <actor_login> added <member_login> as collaborator

​
Evidence fields

FieldDescription
added_memberLogin of the newly added collaborator
added_member_idGitHub user ID of the added collaborator
created_atTimestamp of the addition
Collaborator additions are a normal part of project growth, so this rule intentionally generates medium-severity findings rather than critical ones. Review the added_member field against your expected contributor list during your regular security audits.For organizations with strict access controls, consider configuring GitHub’s built-in audit log alerts for member.added events, which can send notifications via webhook to your security team in real time.

​
repo-made-public

Severity: high
Required data: Events only

​
What it detects

A PublicEvent within the past 2 years, indicating that the repository was changed from private to public. GitHub emits this event exactly once when a repository’s visibility is changed to public. This is a significant security event because all commit history, branches, issues, and configuration files immediately become accessible to the internet — including any secrets that may have been committed before the repository was intended to be public.

​
How detection works

The analyzer queries for PublicEvent occurrences within a 2-year lookback window. 
SELECT id, repo_name, actor_login, created_at
FROM github_events
WHERE event_type = 'PublicEvent'
  AND created_at >= now() - INTERVAL '2 years'

​
Finding description

Repository <repo_name> was made public by <actor_login>

​
Evidence fields

FieldDescription
created_atTimestamp when the repository was made public
When a private repository is made public, its entire commit history is immediately exposed — not just the current state. Secrets committed in any past commit (even ones that were later deleted from HEAD via a commit that removes the file) remain readable through git log and GitHub’s commit browsing UI.Remediation: Immediately run a secret scanning tool such as truffleHog or gitleaks against the full commit history. Rotate any credentials found, regardless of when they were committed. Use GitHub’s secret scanning push protection to prevent future accidental secret commits.

Build docs developers (and LLMs) love

Get started for freeTalk to us