Github Actions

R3zk0n · September 16, 2025

Contents

    Github Actions

    Github Actions allow developers to automate tasks like building, testing, and deploying code whenever specific events occur, such as pushing commits, opening pull requests, or publishing releases. Workflows are defined as YAML files stored in the repo, and run inside isolated virtual environments called runners.

    Runners

    Runners are the execution environments that power GitHub Actions workflows. When a workflow is triggered, a runner picks up the job and runs each step in order on a clean virtual machine or container. GitHub provides hosted runners for common operating systems like Linux, Windows, and macOS, which are automatically created and destroyed for each run. Github has their own runners aswell as the ability for users to use self-hosted runners which allows the users to gain more control, and use custom hardware.

    Workflows

    Github uses workflows to define and execute Github Actions. these workflow generally sit in the .github/workflows directory and are defined as in a strict YAML format such as the one defined below.

    name: Blog
    
    on:
      pull_request:
        types: [opened, edited, synchronize]
    
    jobs:
      validate-pr-title:
        name: Blog
        runs-on: ubuntu-latest
        steps: 
          - name: Show workflow context
            run: |
              echo "Repository: ${{ github.repository }}"
              echo "Actor: ${{ github.actor }}"
              echo "Event: ${{ github.event_name }}"
              echo "Token available: ${{ secrets.GITHUB_TOKEN != '' }}"
              echo "Ref: ${{ github.ref }}"
    

    The format consisents of the general structure being on: pull_request: types: [opened, edited, synchronize] which means this workflow is executed and runs when a pull request is opened, edited or synchronize.

    Action Security

    Workflows can handle a wide range of tasks, from tagging pull requests to enforce consistent formatting and processes, to more sensitive operations such as building artifacts and deploying release code to various environments. Because of this, workflows often manage sensitive data like credentials and access tokens.

    There are generally two main threat scenarios involving workflows:

    • An attacker with read access to the repository (for example, anyone viewing a public repository)
    • An attacker with write access to the repository (for example, an insider with organizational write permissions)

    While there are plenty of resources covering the first scenario, guidance on the latter is limited, even though it poses a significant risk as a potential insider threat.

    GitHub Actions workflows are structured into jobs, and each job is made up of one or more steps. Each job runs in its own isolated virtual machine (runner), while steps are individual tasks within that job that execute sequentially in the same environment.

    For example, in workflow file above, the job is named validate-pr-title, and one of its steps is show workflow context.

    When a step is executed the job

    Trigger Table:

    Trigger name How to trigger Restrictions
    discussion Start a new discussion There is an organization setting to disallow readers from starting new discussions, but readers are allowed by default
    discussion_comment Comment on a discussion  
    fork Fork a repository For private repositories, permission to fork repositories must have been granted at the organization level. This is disabled by default. Anyone can fork a public repository.
    issue_comment Comment on an issue or a pull request  
    issues Create an issue  
    pull_request Create a pull request If the pull request is from a fork, permissions may be needed for actions to run. NB! Readers can create a pull request without forking as long as there are at least two differing branches already present.
    pull_request_review Review a pull request  
    pull_request_review_comment Make a comment as part of a pull request review  
    pull_request_target Create a pull request Somewhat the same as pull_request but difference in various reasons..
    watch Star a repository  

    Structure

    Twitter, Facebook