> ## Documentation Index
> Fetch the complete documentation index at: https://bloodhound.specterops.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GH_UsesVariable

> [Workflow] Step references a variable by name — GH_WorkflowStep → GH_RepoVariable / GH_OrgVariable (name match)

<img noZoom src="https://mintcdn.com/specterops/tTIczgde9H07oLXf/assets/enterprise-AND-community-edition-pill-tag.svg?fit=max&auto=format&n=tTIczgde9H07oLXf&q=85&s=ad49a576589f4d2a8081df77d07fdf56" alt="Applies to BloodHound Enterprise and CE" width="482" height="45" data-path="assets/enterprise-AND-community-edition-pill-tag.svg" />

## Edge Schema

* Source: [GH\_WorkflowStep](/opengraph/extensions/github/nodes/gh_workflowstep)
* Destination: [GH\_RepoVariable](/opengraph/extensions/github/nodes/gh_repovariable), [GH\_OrgVariable](/opengraph/extensions/github/nodes/gh_orgvariable)
* Traversable: ❌

## General Information

The non-traversable GH\_UsesVariable edge links a workflow step to the variable it references via a `${{ vars.NAME }}` expression. This edge maps variable consumption within workflows. Unlike secrets, variable values are readable via the API, making them lower sensitivity, but they can still influence workflow behavior.

### Matching strategy

Edges use `match_by: property` with two matchers to disambiguate between variables with the same name across repositories:

* **[GH\_RepoVariable](/opengraph/extensions/github/nodes/gh_repovariable)** is matched by `name` + `repository_id`.
* **[GH\_OrgVariable](/opengraph/extensions/github/nodes/gh_orgvariable)** is matched by `name` + `environmentid`.

This means one `${{ vars.MY_VAR }}` expression can produce up to two GH\_UsesVariable edges.

### Context property

The edge carries a `context` property indicating where the reference was found:

* `with` — inside a `with:` input block of a `uses:` action step
* `env` — inside the step's `env:` block
* `run` — inline within a `run:` shell script