openhound-github 0.1.0__tar.gz → 0.3.0__tar.gz

{openhound_github-0.1.0 → openhound_github-0.3.0}/.gitignore

@@ -1,6 +1,7 @@
 # Custom
 *.duckdb
 ui_catalog.db
+docs/official-docs/
 site/
 addons/
 collectors/
@@ -13,6 +14,9 @@ dbt_packages
 *.pem
 source
 
+# Codex
+.codex
+
 # Byte-compiled / optimized / DLL files
 __pycache__/
 *.py[codz]

openhound_github-0.3.0/.gitmodules

@@ -0,0 +1,3 @@
+[submodule "docs/og-docs-automation"]
+	path = docs/og-docs-automation
+	url = https://github.com/SpecterOps/og-docs-automation

{openhound_github-0.1.0 → openhound_github-0.3.0}/PKG-INFO

@@ -1,11 +1,11 @@
 Metadata-Version: 2.4
 Name: openhound-github
-Version: 0.1.0
+Version: 0.3.0
 Summary: Github collector for OpenHound
 Author-email: "jdreijer@specterops.io" <jdreijer@specterops.io>, Jared Atkinson <jatkinson@specterops.io>
 License-File: LICENSE.md
 Requires-Python: >=3.13
-Requires-Dist: cryptography>=46.0.6
+Requires-Dist: joserfc>=1.6.5
 Requires-Dist: requests>=2.33.0
 Description-Content-Type: text/markdown
 

openhound_github-0.3.0/descriptions/edges/GH_AddAssignee.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_AddAssignee edge represents a role's ability to assign users to issues and pull requests. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_AddCollaborator.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_AddCollaborator edge represents that a role has the ability to add outside collaborators to organization repositories. This permission is typically restricted to Owners, as it grants repository access to external users who are not members of the organization. Outside collaborators bypass organizational membership controls, making this permission significant for security because it can be used to grant access to untrusted external identities without the visibility that full membership provides.

openhound_github-0.1.0/descriptions/edges/GH_ReopenPullRequest.md → openhound_github-0.3.0/descriptions/edges/GH_AddLabel.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The non-traversable `GH_ReopenPullRequest` edge represents a role's ability to reopen closed pull requests. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.
+The non-traversable GH_AddLabel edge represents a role's ability to add labels to issues and pull requests. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_AddMember.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_AddMember edge indicates that a team role with the Maintainer permission level can add new members to the team. This edge is traversable because the ability to add members grants indirect access -- a maintainer can add any user to the team, and that user then inherits all of the team's repository permissions, effectively expanding the attack surface.

openhound_github-0.3.0/descriptions/edges/GH_AdminTo.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_AdminTo edge represents a role's full administrative access to the repository. Admin is the highest built-in repository role and grants control over all repository settings, including dangerous operations like deleting the repository or modifying its visibility. Admin access bypasses most protections including branch protection rules, unless `enforce_admins` is explicitly enabled on the branch protection rule. This edge is a key permission in the computed branch access model and is a high-value target in attack path analysis.

openhound_github-0.3.0/descriptions/edges/GH_BypassBranchProtection.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_BypassBranchProtection edge represents a role's ability to bypass branch protection rules on the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Bypassing branch protection allows merging pull requests without satisfying required review or status check requirements, effectively circumventing the merge gate. This bypass is suppressed when `enforce_admins` is enabled on the branch protection rule, which forces even admins to comply with the protection policy.

openhound_github-0.3.0/descriptions/edges/GH_BypassPullRequestAllowances.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_BypassPullRequestAllowances edge represents a per-actor allowance that bypasses the pull request review requirement on a branch protection rule. This edge identifies specific users or teams that can merge code without going through the normal PR review process. This is a significant security concern because these actors can push or merge changes directly, circumventing code review controls that protect branch integrity. Note that this bypass is suppressed when `enforce_admins` is enabled on the branch protection rule, meaning even listed actors must follow the PR review requirement.

openhound_github-0.3.0/descriptions/edges/GH_CallsWorkflow.md

@@ -0,0 +1,10 @@
+## General Information
+
+The traversable GH_CallsWorkflow edge links a workflow job to a reusable workflow it invokes via the `uses:` key at the job level. This edge captures the reusable workflow call graph, enabling analysts to trace inherited permissions and secret access through called workflows.
+
+### Local vs. remote reusable workflows
+
+- **Local** (`./. github/workflows/_ci.yml`): the destination is matched by `name` against workflows in the same repository.
+- **Remote** (`org/repo/.github/workflows/file.yml@ref`): the destination is matched by the full reference string. If the called workflow has not been collected, the edge destination will not resolve.
+
+The `reusable_ref` property on the edge always contains the raw `uses:` value from the workflow file.

openhound_github-0.3.0/descriptions/edges/GH_CanAccess.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CanAccess edge indicates that a personal access token or app installation has been granted access to specific repositories. This edge represents the scope of access granted to a token or app rather than a direct attack path, providing visibility into which repositories are reachable through non-human credentials. It is non-traversable because token and app access does not transitively extend to other principals.

openhound_github-0.3.0/descriptions/edges/GH_CanAssumeIdentity.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_CanAssumeIdentity edge is a hybrid edge connecting GitHub OIDC token sources to cloud identity targets configured for GitHub Actions federation. This edge represents a verified path from GitHub Actions to cloud resource access. It is traversable because an attacker who can execute workflows in the source repository, branch, or environment can obtain an OIDC token that the cloud provider will accept, granting access to the associated cloud identity and its permissions. This edge is critical for identifying cross-cloud lateral movement paths from GitHub into Azure and AWS.

{openhound_github-0.1.0 → openhound_github-0.3.0}/descriptions/edges/GH_CanCreateBranch.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanCreateBranch` edge is a computed edge indicating that a role or actor can create new branches in a repository. Created by `Compute-GitHoundBranchAccess` with no additional API calls, the computation evaluates whether a wildcard (`*`) BPR with push restrictions and `blocks_creations` exists. If no such BPR exists, any write-capable role can create branches. If one exists, admin or `push_protected_branch` permission is required, or the actor must be listed in pushAllowances. Per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant branch creation access beyond what the role provides. Each edge includes a `reason` property and a `query_composition` Cypher query showing the underlying graph evidence.
+The traversable GH_CanCreateBranch edge is a computed edge indicating that a role or actor can create new branches in a repository. The computation evaluates whether a wildcard (`*`) BPR with push restrictions and `blocks_creations` exists. If no such BPR exists, any write-capable role can create branches. If one exists, admin or `push_protected_branch` permission is required, or the actor must be listed in pushAllowances. Per-actor edges from GH_User or GH_Team are only emitted when BPR allowances grant branch creation access beyond what the role provides. Each edge includes a `reason` property and a `query_composition` Cypher query showing the underlying graph evidence.
 
 ## Scenarios
 
@@ -28,7 +28,7 @@ graph LR
 
 ### `push_protected_branch` — Push-protected role bypasses wildcard BPR
 
-A wildcard BPR blocks creations. The `GH_PushProtectedBranch` permission bypasses the push gate regardless of `enforce_admins`.
+A wildcard BPR blocks creations. The GH_PushProtectedBranch permission bypasses the push gate regardless of `enforce_admins`.
 
 ```mermaid
 graph LR
@@ -41,7 +41,7 @@ graph LR
 
 ### `push_allowance` — Per-actor push restriction bypass
 
-User or Team listed in the wildcard BPR's `pushAllowances` can create branches. This is a per-actor delta edge — only emitted when the actor's role doesn't already grant `GH_CanCreateBranch`.
+User or Team listed in the wildcard BPR's `pushAllowances` can create branches. This is a per-actor delta edge — only emitted when the actor's role doesn't already grant GH_CanCreateBranch.
 
 ```mermaid
 graph LR

openhound_github-0.3.0/descriptions/edges/GH_CanEditProtection.md

@@ -0,0 +1,31 @@
+## General Information
+
+The traversable GH_CanEditProtection edge is a computed edge indicating that a role can modify or remove branch protection rules in a repository. This edge is emitted when the role has GH_EditRepoProtections or GH_AdminTo permissions and the repository contains at least one protected branch. Repo-targeted edges model the repo-wide security impact for attack path traversal; branch-targeted edges are also emitted as supporting evidence for each protected branch governed by those rules.
+
+## Scenarios
+
+### `admin` — Admin can edit protections
+
+The admin role has GH_AdminTo which implicitly grants the ability to modify or remove any branch protection rule.
+
+```mermaid
+graph LR
+    role("GH_RepoRole admin") -->|GH_AdminTo| repo("GH_Repository")
+    repo -->|GH_HasBranch| branch("GH_Branch main")
+    bpr("GH_BranchProtectionRule") -->|GH_ProtectedBy| branch
+    role ==>|GH_CanEditProtection| repo
+    role ==>|GH_CanEditProtection| branch
+```
+
+### `edit_repo_protections` — Explicit edit permission
+
+A custom or standard role with the GH_EditRepoProtections permission can modify or remove branch protection rules.
+
+```mermaid
+graph LR
+    role("GH_RepoRole custom") -->|GH_EditRepoProtections| repo("GH_Repository")
+    repo -->|GH_HasBranch| branch("GH_Branch main")
+    bpr("GH_BranchProtectionRule") -->|GH_ProtectedBy| branch
+    role ==>|GH_CanEditProtection| repo
+    role ==>|GH_CanEditProtection| branch
+```

openhound_github-0.3.0/descriptions/edges/GH_CanPwnRequest.md

@@ -0,0 +1,59 @@
+## General Information
+
+The traversable GH_CanPwnRequest edge indicates that a repository role can exploit a pwn-requestable workflow to execute arbitrary code with the base branch's secrets, GITHUB_TOKEN permissions, and OIDC identity. This is a computed edge that combines workflow analysis with repository access and fork policy evaluation.
+
+### Pwn Request Conditions
+
+A workflow is considered pwn-requestable (`is_pwn_requestable = true`) when **all** of the following are true:
+
+1. **`pull_request_target` trigger**: The workflow is triggered by `pull_request_target`, which runs in the context of the base branch (not the fork) and has access to the base branch's secrets and permissions.
+2. **Attacker-controlled checkout**: A step uses `actions/checkout` with a `ref` parameter pointing to the pull request head, meaning attacker-supplied code from the fork replaces the trusted repository contents. Detected ref patterns:
+   - `${{ github.event.pull_request.head.sha }}`
+   - `${{ github.event.pull_request.head.ref }}`
+   - `${{ github.head_ref }}`
+
+### Edge Drawing Conditions
+
+An edge is drawn from a GH_RepoRole to the repository (and its branches) when:
+
+1. **Read access**: The role has a GH_ReadRepoContents edge to the repository (read access is the minimum required to fork).
+2. **Forkability**: The repository can be forked by the role holder:
+   - **Public repos**: Always forkable by anyone on GitHub.
+   - **Private/internal repos**: Requires both the organization setting `members_can_fork_private_repositories = true` AND the repository setting `allow_forking = true`.
+3. **Pwn-requestable workflow**: The repository has at least one workflow with `is_pwn_requestable = true`.
+
+### Branch Targeting
+
+- If the `pull_request_target` trigger has a `branches:` filter (e.g., `branches: [main]`), edges are drawn only to matching branches and the repository.
+- If unconstrained, edges are drawn to the repository and all of its branches.
+
+### Attack Impact
+
+An attacker who exploits a pwn request gains code execution in the workflow runner with access to:
+
+- **Repository secrets** scoped to the base branch
+- **Organization secrets** accessible by the repository
+- **GITHUB_TOKEN** with the workflow's declared permissions (often `write`)
+- **OIDC tokens** if `id-token: write` is set, enabling cloud identity assumption via GH_CanAssumeIdentity
+- **Environment secrets** if the workflow job targets a deployment environment
+
+### Caveats
+
+- **OIDC traversal requires `id-token: write`**: The attack chain from GH_CanPwnRequest through GH_CanAssumeIdentity to a cloud role is only valid if the pwn-requestable workflow (or job) explicitly declares `id-token: write` in its `permissions:` block. The `id-token` permission defaults to `none` and is never implicitly granted — even when the workflow has no `permissions:` block at all. The `permissions` property on the GH_WorkflowJob node can be inspected to verify this.
+- **GITHUB_TOKEN permissions**: The `permissions:` block controls what the `GITHUB_TOKEN` can do (e.g., push commits, create releases), but has no effect on secret access, OIDC token requests (governed separately by `id-token`), or arbitrary code execution. A workflow with `contents: read` is still fully exploitable via pwn request for secret exfiltration and lateral movement — only write-back to the repository is limited.
+
+```mermaid
+graph LR
+    role("GH_RepoRole repo-read")
+    repo("GH_Repository private-app")
+    branch("GH_Branch main")
+    wf("GH_Workflow vulnerable-ci.yml")
+    secret("GH_RepoSecret DEPLOY_KEY")
+    cloud("AWSRole deploy-prod")
+
+    role -- GH_CanPwnRequest --> repo
+    role -- GH_CanPwnRequest --> branch
+    repo -.- |GH_HasWorkflow| wf
+    repo -.- |GH_Contains| secret
+    branch -- GH_CanAssumeIdentity --> cloud
+```

openhound_github-0.3.0/descriptions/edges/GH_CanReadSecretScanningAlert.md

@@ -0,0 +1,31 @@
+## General Information
+
+The traversable GH_CanReadSecretScanningAlert edge is a computed edge indicating that a role can read a specific secret scanning alert, including the leaked secret value. The computation cross-references GH_ViewSecretScanningAlerts permission edges with GH_Contains structural edges (org-level and repo-level) to determine which alerts each role can access. This edge is traversable because reading an alert reveals the leaked secret — if the secret is a valid GitHub Personal Access Token, the GH_ValidToken edge enables identity compromise of the token's owner.
+
+Each edge includes a `reason` property (`org_role_permission` or `repo_role_permission`) and a `query_composition` Cypher query showing the underlying graph evidence.
+
+## Scenarios
+
+### `org_role_permission` — Org role views alerts via organization
+
+An org role with GH_ViewSecretScanningAlerts to the organization can read all secret scanning alerts across the entire org. The computation follows GH_Contains edges from the organization to each alert.
+
+```mermaid
+graph LR
+    role("GH_OrgRole security_manager") -->|GH_ViewSecretScanningAlerts| org("GH_Organization")
+    org -->|GH_Contains| alert("GH_SecretScanningAlert #42")
+    role ==>|GH_CanReadSecretScanningAlert| alert
+    alert -.->|GH_ValidToken| user("GH_User jdoe")
+```
+
+### `repo_role_permission` — Repo role views alerts via repository
+
+A repo role with GH_ViewSecretScanningAlerts to the repository can read secret scanning alerts in that specific repo. The computation follows GH_Contains edges from the repository to each alert.
+
+```mermaid
+graph LR
+    role("GH_RepoRole admin") -->|GH_ViewSecretScanningAlerts| repo("GH_Repository")
+    repo -->|GH_Contains| alert("GH_SecretScanningAlert #17")
+    role ==>|GH_CanReadSecretScanningAlert| alert
+    alert -.->|GH_ValidToken| user("GH_User jdoe")
+```

{openhound_github-0.1.0 → openhound_github-0.3.0}/descriptions/edges/GH_CanWriteBranch.md

@@ -1,6 +1,6 @@
-# General Information
+## General Information
 
-The traversable `GH_CanWriteBranch` edge is a computed edge indicating that a role or actor can push to a specific branch. Created by `Compute-GitHoundBranchAccess` with no additional API calls, the computation evaluates both the merge gate (PR review requirements) and push gate (push restrictions) of any branch protection rule protecting the branch. Role-level edges are the common case; per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant access beyond what the role provides. Each edge includes a `reason` property (`no_protection`, `admin`, `push_protected_branch`, `bypass_branch_protection`, `push_allowance`, `bypass_pr_allowance`) and a `query_composition` Cypher query showing the underlying graph evidence.
+The traversable GH_CanWriteBranch edge is a computed edge indicating that a role or actor can push to a specific branch. The computation evaluates both the merge gate (PR review requirements) and push gate (push restrictions) of any branch protection rule protecting the branch. Role-level edges are the common case; per-actor edges from GH_User or GH_Team are only emitted when BPR allowances grant access beyond what the role provides. Each edge includes a `reason` property (`no_protection`, `admin`, `push_protected_branch`, `bypass_branch_protection`, `push_allowance`, `bypass_pr_allowance`) and a `query_composition` Cypher query showing the underlying graph evidence.
 
 ## Scenarios
 
@@ -29,7 +29,7 @@ graph LR
 
 ### `push_protected_branch` — Push gate bypass
 
-Push gate blocked by `push_restrictions` (no merge gate block). The `GH_PushProtectedBranch` permission bypasses the push gate regardless of `enforce_admins`.
+Push gate blocked by `push_restrictions` (no merge gate block). The GH_PushProtectedBranch permission bypasses the push gate regardless of `enforce_admins`.
 
 ```mermaid
 graph LR
@@ -42,7 +42,7 @@ graph LR
 
 ### `bypass_branch_protection` — Merge gate bypass
 
-Merge gate blocked by PR reviews. The `GH_BypassBranchProtection` permission bypasses the merge gate. Requires `enforce_admins=false`; suppressed when `enforce_admins=true`.
+Merge gate blocked by PR reviews. The GH_BypassBranchProtection permission bypasses the merge gate. Requires `enforce_admins=false`; suppressed when `enforce_admins=true`.
 
 ```mermaid
 graph LR

openhound_github-0.3.0/descriptions/edges/GH_CloseDiscussion.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CloseDiscussion edge represents a role's ability to close discussions, preventing further replies. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_CloseIssue.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CloseIssue edge represents a role's ability to close issues. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ClosePullRequest.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ClosePullRequest edge represents a role's ability to close pull requests. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_Contains.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_Contains edge represents structural containment within the GitHub resource hierarchy. The organization serves as the top-level container for users, teams, repositories, roles, secrets, app installations, and personal access tokens. Repositories contain their own repo-level secrets, and environments contain environment-scoped secrets. This edge is created by the collector to establish the organizational hierarchy of GitHub resources and is not traversable because containment alone does not imply privilege escalation.

openhound_github-0.3.0/descriptions/edges/GH_ConvertIssuesToDiscussions.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ConvertIssuesToDiscussions edge represents a role's ability to convert issues to discussions, moving them from the issue tracker to the discussions forum. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.1.0/descriptions/edges/GH_RemoveLabel.md → openhound_github-0.3.0/descriptions/edges/GH_CreateDiscussionCategory.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The non-traversable `GH_RemoveLabel` edge represents a role's ability to remove labels from issues and pull requests. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.
+The non-traversable GH_CreateDiscussionCategory edge represents a role's ability to create new discussion categories. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_CreateRepository.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CreateRepository edge represents that a role has the ability to create new repositories within the organization. This permission is available to Owners and custom organization roles that have been granted the repository creation permission. Creating repositories can introduce new attack surface to an organization, as each new repository is a potential vector for code execution through GitHub Actions workflows, secret exposure, and supply chain attacks.

openhound_github-0.3.0/descriptions/edges/GH_CreateSoloMergeQueueEntry.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CreateSoloMergeQueueEntry edge represents a role's ability to create solo merge queue entries, effectively bypassing the merge queue by merging independently of other queued changes. This permission is available to Admin roles and custom roles that have been granted this specific permission. Solo merge queue entries skip the batching and ordering guarantees of the merge queue, allowing changes to land without waiting for or being tested alongside other pending merges. This can circumvent the integration testing benefits that merge queues provide.

openhound_github-0.3.0/descriptions/edges/GH_CreateTag.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CreateTag edge represents a role's ability to create tags and releases. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission. Creating tags can trigger CI/CD workflows and publish release artifacts.

openhound_github-0.3.0/descriptions/edges/GH_CreateTeam.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_CreateTeam edge represents that a role has the ability to create teams within the organization. Teams are the primary mechanism for granting groups of users access to repositories, so team creation is a stepping stone to broader access. This edge is created by the collector when enumerating organization role permissions, and its security significance lies in the fact that a newly created team can be granted repository access and then populated with controlled accounts.

openhound_github-0.3.0/descriptions/edges/GH_DeleteAlertsCodeScanning.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeleteAlertsCodeScanning edge represents a role's ability to delete code scanning alerts from the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Deleting code scanning alerts can obscure security vulnerabilities that have been detected in the codebase, which is significant from an audit and compliance perspective. An attacker with this permission could suppress evidence of vulnerabilities they have introduced.

openhound_github-0.3.0/descriptions/edges/GH_DeleteDiscussion.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeleteDiscussion edge represents a role's ability to delete discussions. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_DeleteDiscussionComment.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeleteDiscussionComment edge represents a role's ability to delete discussion comments authored by any user. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_DeleteIssue.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeleteIssue edge represents a role's ability to delete issues permanently. Deleted issues cannot be recovered. This permission is available to Admin roles and custom roles that have been granted this specific permission. Deleting issues can destroy audit trails and remove evidence of security discussions or vulnerability reports.

openhound_github-0.3.0/descriptions/edges/GH_DeleteTag.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeleteTag edge represents a role's ability to delete tags and releases. This permission is available to Admin roles and custom roles that have been granted this specific permission. Deleting tags can break downstream dependency references and remove published artifacts.

openhound_github-0.3.0/descriptions/edges/GH_DependsOn.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DependsOn edge represents a `needs:` dependency between two jobs in the same workflow. This edge captures execution order constraints — the source job will not start until the destination job completes successfully. This edge is non-traversable because it represents sequencing only, not an access or privilege path.

openhound_github-0.3.0/descriptions/edges/GH_DeploysTo.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_DeploysTo edge links a workflow job to the GitHub Environment it targets via the `environment:` key. This edge records which jobs deploy to which environments. Environments can gate deployments with protection rules (required reviewers, wait timers, deployment branch policies) and can expose environment-scoped secrets.

openhound_github-0.3.0/descriptions/edges/GH_EditCategoryOnDiscussion.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditCategoryOnDiscussion edge represents a role's ability to change the category of a discussion, moving it between categories. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_EditDiscussionCategory.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditDiscussionCategory edge represents a role's ability to edit discussion categories to reorganize discussion classification. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_EditDiscussionComment.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditDiscussionComment edge represents a role's ability to edit discussion comments authored by any user. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_EditRepoAnnouncementBanners.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditRepoAnnouncementBanners edge represents a role's ability to edit repository announcement banners displayed to visitors. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_EditRepoCustomPropertiesValues.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditRepoCustomPropertiesValues edge represents a role's ability to edit custom property values on the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Custom properties are organization-defined metadata fields on repositories that can be used for classification, compliance tagging, or policy enforcement via rulesets. Modifying custom property values could alter which organization-level rulesets apply to the repository, potentially bypassing security controls that are scoped by property-based targeting.

openhound_github-0.3.0/descriptions/edges/GH_EditRepoMetadata.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditRepoMetadata edge represents a role's ability to edit repository metadata including description, homepage URL, and visibility settings. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_EditRepoProtections.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_EditRepoProtections edge represents a role's ability to edit or remove branch protection rules on the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Modifying a branch protection rule is an indirect bypass -- removing or weakening protections opens the branch to direct push or unreviewed merges, making this a high-severity permission from a security perspective. Attack paths that include this edge can escalate to full branch write access by first disabling protections.

openhound_github-0.3.0/descriptions/edges/GH_HasBaseRole.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasBaseRole edge represents role inheritance within the GitHub permission hierarchy. Org roles inherit down to all-repo roles (e.g., Owners inherits to all_repo_admin), and custom roles inherit from their base roles (e.g., a custom_role inherits from write). This edge is traversable because it extends permissions through the role hierarchy, meaning a principal with a higher-level role implicitly holds all inherited lower-level roles.

openhound_github-0.3.0/descriptions/edges/GH_HasBranch.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasBranch edge represents the relationship between a repository and its branches. This edge links each collected branch to its parent repository. It is a structural edge that provides the foundation for understanding branch-level protections and access controls. While not traversable itself, it connects repositories to branches where traversable edges like GH_CanWriteBranch and GH_CanEditProtection model the effective access.

openhound_github-0.3.0/descriptions/edges/GH_HasEnvironment.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasEnvironment edge represents the relationship between a repository or branch and its deployment environments. This edge links environments to the repositories that define them and to the branches that are allowed to deploy to them (via deployment branch policies). Environments are security-relevant because they can gate access to secrets and cloud credentials, and their deployment branch policies control which branches can trigger deployments.

openhound_github-0.3.0/descriptions/edges/GH_HasExternalIdentity.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasExternalIdentity edge represents the relationship between a SAML identity provider and the external identities (SSO users) it manages. This edge links each external identity to the SAML provider that authenticated it. External identities are a key component in cross-platform attack path analysis because they bridge the gap between corporate identity providers and GitHub user accounts via the GH_MapsToUser edge. Enumerating external identities reveals which corporate users have linked GitHub accounts and enables mapping from IdP compromise to GitHub access.

openhound_github-0.3.0/descriptions/edges/GH_HasJob.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasJob edge links a workflow to each of its jobs. This edge is the primary structural link for walking from a workflow definition into its execution units. Because jobs can declare environments and permissions, traversing this edge enables analysts to reason about what a workflow can do and where it can deploy.

openhound_github-0.3.0/descriptions/edges/GH_HasMember.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasMember edge represents the relationship between a GitHub enterprise or organization and a user who is a member of that scope. This edge records membership as directory context rather than as an access path: being listed as a member does not by itself describe what the user can do, only that the user belongs to the enterprise or organization. Membership remains security-relevant because it defines the population from which roles, team assignments, and token approvals are drawn, and it helps analysts understand who is inside the trust boundary when reviewing GitHub exposure.

openhound_github-0.3.0/descriptions/edges/GH_HasPersonalAccessToken.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasPersonalAccessToken edge represents the relationship between a user and their fine-grained personal access tokens that have been granted access to the organization. This edge links each approved token back to the user who created it. Fine-grained personal access tokens are security-significant because they provide programmatic access to organization resources with specific scoped permissions. Tracking token ownership is essential for understanding which users have standing API access and for identifying tokens that may need revocation.

openhound_github-0.3.0/descriptions/edges/GH_HasPersonalAccessTokenRequest.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasPersonalAccessTokenRequest edge represents the relationship between a user and their pending personal access token requests awaiting organizational approval. This edge links each pending token request back to the user who submitted it. Pending token requests are security-relevant because they represent access that may soon be granted, and reviewing them helps administrators understand what permissions users are requesting before approval. Organizations that require approval for fine-grained PATs will have these requests queued until an administrator acts on them.

openhound_github-0.3.0/descriptions/edges/GH_HasRole.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasRole edge represents the assignment of a user or team to a specific role within the organization, repository, or team. This is the primary edge for connecting identities to their permissions and serves as the foundation of all access paths in the GitHub permission model. Because role assignment is the starting point for determining what a principal can do, this edge is traversable and critical for attack path analysis.

openhound_github-0.3.0/descriptions/edges/GH_HasSamlIdentityProvider.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasSamlIdentityProvider edge represents the relationship between an organization and its SAML identity provider configuration. This edge links an organization to the SAML SSO provider used for authentication and user provisioning. SAML identity providers are a critical security component because they establish the trust boundary between an external identity provider (such as Entra ID or Okta) and the GitHub organization. Understanding this relationship is essential for mapping cross-platform attack paths where compromise of the identity provider could lead to access within the GitHub organization.

openhound_github-0.3.0/descriptions/edges/GH_HasSecret.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasSecret edge represents the relationship between a repository or environment and the secrets accessible within that context. This edge shows which secrets are available in which scopes. Repositories can have access to both organization-level secrets (scoped to selected repositories) and repository-level secrets, while environments contain their own environment-scoped secrets. This edge is traversable because any principal that can push code to a repository (via GH_CanWriteBranch or GH_CanCreateBranch) can write a workflow that exfiltrates the secret values at runtime, making this a meaningful link in attack path analysis.

openhound_github-0.3.0/descriptions/edges/GH_HasStep.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasStep edge links a job to each of its steps in execution order. This edge enables analysts to enumerate all actions and shell commands executed by a job, including which secrets and variables each step consumes.

openhound_github-0.3.0/descriptions/edges/GH_HasVariable.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_HasVariable edge represents the relationship between a repository and the variables accessible within that context. This edge shows which variables are available in which scopes. Repositories can have access to both organization-level variables (scoped by visibility to all, private, or selected repositories) and repository-level variables defined directly on the repo. This edge is traversable because any principal that can push code to a repository (via GH_CanWriteBranch or GH_CanCreateBranch) can write a workflow that reads variable values at runtime, and variables may contain configuration data useful for lateral movement such as deployment URLs, service names, or environment identifiers.

openhound_github-0.3.0/descriptions/edges/GH_HasWorkflow.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_HasWorkflow edge represents the relationship between a repository and its GitHub Actions workflows. This edge links each discovered workflow definition to its parent repository. Workflows are significant from a security perspective because they can execute arbitrary code with repository permissions, access secrets, and assume cloud identities. This structural edge enables analysts to enumerate which workflows exist in a given repository.

openhound_github-0.3.0/descriptions/edges/GH_InstalledAs.md

@@ -0,0 +1,3 @@
+## General Information
+
+The traversable GH_InstalledAs edge links a GitHub App to its installation within the organization. This edge is traversable because it connects the app definition to its active installation, which determines the specific set of repositories and permissions the app has been granted. Understanding the relationship between an app and its installation is essential for tracing how app-level permissions translate into repository access.

openhound_github-0.3.0/descriptions/edges/GH_InviteMember.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_InviteMember edge represents that a role has the ability to invite new members to the organization. This permission is typically restricted to Owners, as inviting members expands the organization's trust boundary by granting new users access to internal resources. An attacker with this permission could invite a controlled account to gain persistent access to the organization's repositories, teams, and secrets.

openhound_github-0.3.0/descriptions/edges/GH_JumpMergeQueue.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_JumpMergeQueue edge represents a role's ability to jump ahead of other entries in the merge queue. This permission is available to Admin roles and custom roles that have been granted this specific permission. Merge queues enforce an ordered sequence of CI checks and merges; jumping the queue allows a principal to prioritize their changes ahead of others. While less severe than bypassing protections entirely, this permission can be used to accelerate the landing of malicious changes before other queued entries are reviewed or tested.

openhound_github-0.3.0/descriptions/edges/GH_ManageDeployKeys.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageDeployKeys edge represents a role's ability to create, modify, and delete deploy keys for the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Deploy keys provide SSH-based access to the repository, and a deploy key with write access can push commits directly without going through the GitHub web interface or API authentication. Managing deploy keys is security-significant because it enables the creation of persistent, credential-based access that operates outside the normal user authentication flow.

openhound_github-0.3.0/descriptions/edges/GH_ManageDiscussionBadges.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageDiscussionBadges edge represents a role's ability to manage discussion badges used to highlight discussion participants. This permission is available to Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageOrganizationWebhooks.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageOrganizationWebhooks edge represents that a role has the ability to manage organization-level webhooks. This edge is dynamically generated from custom organization role permissions discovered by the collector. Webhooks can be configured to send event data to external endpoints, making this permission significant for security because an attacker could create or modify webhooks to exfiltrate repository data, commit contents, or issue details to an attacker-controlled server, or use them as a persistence mechanism.

openhound_github-0.3.0/descriptions/edges/GH_ManageRepoSecurityProducts.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageRepoSecurityProducts edge represents a role's ability to manage repository-specific security product settings. This permission is available to Admin roles and custom roles that have been granted this specific permission. Unlike the broader GH_ManageSecurityProducts permission, this edge is scoped to repository-level security configuration such as repository-specific scanning settings and alert management. Disabling repository-level security products can create blind spots in vulnerability detection for the specific repository.

openhound_github-0.3.0/descriptions/edges/GH_ManageSecurityProducts.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageSecurityProducts edge represents a role's ability to manage security product settings on the repository. This permission is available to Admin roles and custom roles that have been granted this specific permission. Managing security products allows enabling or disabling features such as secret scanning, code scanning, and Dependabot alerts. An attacker with this permission could disable security features to prevent detection of vulnerabilities or leaked secrets, making this a high-severity permission for security posture management.

openhound_github-0.3.0/descriptions/edges/GH_ManageSettingsMergeTypes.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageSettingsMergeTypes edge represents a role's ability to configure allowed merge types (merge commit, squash, rebase) on the repository. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageSettingsPages.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageSettingsPages edge represents a role's ability to manage GitHub Pages settings including enabling, disabling, and configuring the source. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageSettingsProjects.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageSettingsProjects edge represents a role's ability to manage project board settings on the repository. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageSettingsWiki.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageSettingsWiki edge represents a role's ability to enable or disable the repository wiki. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageTopics.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageTopics edge represents a role's ability to manage repository topics used for discovery and classification. This permission is available to Maintain and Admin roles and custom roles that have been granted this specific permission.

openhound_github-0.3.0/descriptions/edges/GH_ManageWebhooks.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_ManageWebhooks edge represents a role's ability to create, modify, and delete repository-level webhooks. This permission is available to Admin roles and custom roles that have been granted this specific permission. Webhooks can exfiltrate repository events and code changes to external endpoints, making this a security-sensitive permission. An attacker with this permission could configure a webhook to receive push event payloads containing commit diffs, effectively creating a covert channel for data exfiltration.

openhound_github-0.3.0/descriptions/edges/GH_MapsToUser.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_MapsToUser edge maps an external identity (provisioned via SAML or SCIM) to a GitHub user within the organization, or to an external IdP user (such as [AZUser](https://bloodhound.specterops.io/resources/nodes/az-user), [Okta_User](https://bloodhound.specterops.io/opengraph/extensions/okta/nodes/okta_user), or [PingOneUser](https://github.com/andyrobbins/PingOneHound?tab=readme-ov-file#schema)) in hybrid graph scenarios. This edge represents identity correlation rather than an attack path, connecting a user's external IdP account to their GitHub account for visibility into federated identity mappings.

openhound_github-0.3.0/descriptions/edges/GH_MarkAsDuplicate.md

@@ -0,0 +1,3 @@
+## General Information
+
+The non-traversable GH_MarkAsDuplicate edge represents a role's ability to mark issues or pull requests as duplicates. This permission is available to Triage, Write, Maintain, and Admin roles and custom roles that have been granted this specific permission.