octoscan - Octoscan is a static vulnerability scanner for Git

项目说明

<di="center">
:octocat:
</div>
<h1 align="center">
octoscan
</h1>

<p align="center">
Octoscan is a static scanner for GitHub action workflows.
</p>

<di="center">
<img src="img/dependabot.png"/>
</div>

<br />

Table of Contents

Table of Contents

Installation

Usage

- download remote workflows
- analyze
- GitHub action

Rules

- dangerous-checkout
- dangerous-action
- dangerous-write
- expression-injection
- runner-label
- repo-jacking
- unsecure-commands
- bot-check
- known-
- dangerous-artefact
- credentials
- shellcheck
- local-action
- oidc-action

Credits

Resources

Installation

Or with docker:

Usage

download remote workflows

Octoscan can be run against a local git repository or you can download all the workflows with the dl action:

analyze

If you don't know what to run just run this:

It will reduce false positives and give the most interesting results.

If you ha the workflows with the dl command you might ha workflows since by default octoscan will download all the workflows of all the branches. To delete duplicated workflows and speed up the analysis you can use the fdupes command before running the analysis:

GitHub action

This tool can also be used directly as a GitHub action to scan your repository on push/pull_request events. For more information please check this repository.

<di="center">
<img src="
</div>

Rules

The complete list of rules can be found with this command:

dangerous-checkout

Triggers like workflow_run or pull_request_target run in a pri context, as they have read access to secrets and potentially ha access on the targeted repository. Performing an explicit checkout on the untrusted code will result in the attacker code being downloaded in such context.

!excalidraw

#### examples

FreeRDP

Excalidraw

AutoGPT

Cypress

Apache Doris

Angular

dangerous-action

This rules warn the user if a dangerous action is used. It's mainly focused on untrusted artifacts.

It is common practice to use artifacts to pass data between different workflows. We often encounter this with the workflow_run trigger where the triggering workflow will prepare some data that will then be sent to the triggered workflow. Given the untrusted nature of this artifact data, it is crucial to treat it with caution and recognize it as a potential threat. The arises from the fact that external entities, such as malicious actors, can influence the content of the artifact data.

!ant-design

#### examples

ant-design

Swagger-editor

Firebase

Firebase

Rust

dangerous-write

GitHub will create default en that can be used inside every step in a workflow. The GITHUB_ENV and GITHUB_OUTPUT are particularly interesting. It is possible to define en in a step and to use this in another one. This can be done by writing it to the associated . If a user can control the content of the that is being set it can lead to arbitrary code execution.

!swagger

#### examples

Swagger-editor

dgraph-io/badger

Firebase

microsoft/ions

expression-injection

Each workflow trigger comes with an associated GitHub context, offering comprehensi about the event that initiated it. This includes details about the user who triggered the event, the branch name, and other relevant contextual information. Certain components of this event data, such as the base repository name, or pull request number, cannot be manipulated or exploited for injection by the user who initiated the event (e.g., in the case of a pull request). This ensures a level of control and security over the information provided by the GitHub context during workflow execution.

However, some elements can be controlled by an attacker and should be sanitized before being used. Here is the list of such elements:

github.event.issue.title

github.event.issue.body

github.event.pull_request.title

github.event.pull_request.body

github.event.comment.body

github.event.review.body

github.event.pages.*.page_name

github.event.commits.*.message

github.event.head_commit.message

github.event.head_commit.author.email

github.event.head_commit.author.name

github.event.commits.*.author.email

github.event.commits.*.author.name

github.event.pull_request.head.ref

github.event.pull_request.head.label

github.event.pull_request.head.repo.default_branch

github.head_ref

env.*

steps.*.outputs.*

needs.*.outputs.*

!autogpt

#### examples

AutoGPT

microsoft/generati

runner-label

GitHub offers the possibility to host your own runners and customize the en used to run jobs in workflows. These runners are called self-hosted.

There exists two types of self-hosted runners, ephemeral and non-ephemeral ones. By default, the runners are non-ephemeral, meaning the en used by the runner is not cleaned after a job completes. If attackers manages to execute code on a non-ephemeral runner, they could backdoor it by adding a process in the background and steal sensiti. These kinds of runners are thus really sensitive.

!excalidraw

Non-ephemeral runners can be identified by looking at run logs. A tool called gato can be used to automate this process.

#### examples

Haskell

lovell/Sharp

WasmEdge

Scroll

Akash Network

actions/runner-images

tensorflow

pytorch

repo-jacking

The repo jacking was presented at DEFCON 31 by Asi Greenholts. This occurs when a GitHub action is referencing an action on a non-existing GitHub organization or user.

!AcalaNetwork

Note that this rule needs internet to check whether the attack is possible or not. All other checks are performed offline.

#### examples

Azure/bicep-registry-modules

HangfireIO/Hangfire

unsecure-commands

Actions possess the capability to interact with the runner machine, enabling them to set en , define output for use by other actions, incorporate debug messages into output logs, and perform other tasks. However, before 2020, it was possible to control en by writing data to STDOUT like this:

The implemented workflow commands were inherently insecure due to the common practice of logging to STDOUT. This opened a for potential attacks, allowing malicious payloads to be easily injected and trigger the set-env command. The ability to modify en introduced multiple paths for remote code execution, with a particularly obvious payload being the one demonstrated earlier. This was initially reported by a security researcher from Project Zero.

Although the set-env command is deprecated and unusable by default, if a de sets the ACTIONS_ALLOW_UNSECURE_COMMANDS en in a workflow, the set-env command becomes a and can be used:

!alibaba

#### examples

alibaba/nacos

bot-check

It's possible to bypass the following check:

The idea of the attack is to trigger Dependabot on a forked repository in such a way that a PR on the forked repository is made by Dependabot, then a PR from the Dependabot branch is opened on the repository and finally Dependabot is triggered again to launch the workflow.

!dependabot

You can find all the exploitation details here:

#### examples

spring-projects/spring-security

spring-projects/spring-session

trpc/trpc

known-

Search for known actions based on osv.dev.

dangerous-artefact

Check for workflow that upload artefacts containing sensiti like .git/config. This rule is based on this article.

credentials

Checks for credentials in services: configuration. This rules comes from actionlint.

!test

shellcheck

Run shellcheck on all the bash tasks. This rules comes from actionlint.

local-action

Raise an alert if a local GitHub action is used. For now the tool can't parse local action files so an alert is raised as they can also contain .

oidc-action

Detect OIDC actions. Workflows using OIDC actions can be a good target to access some cloud pro. There is no associated with this rule but taking a closer look at this action can be interesting if there is a that is not found by this tool.

💡 This is now a debug rule, you need to add --debug-rules to search for this one.

Credits

This tool could not have been de without actionlint. Many thanks to .

Resources

GitHub Actions exploitation: introduction

GitHub Actions exploitation: untrusted input

GitHub Actions exploitation: repo jacking and en manipulation

GitHub Actions exploitation: self hosted runners

GitHub Actions exploitation: Dependabot

项目信息

开发语言：Go

Star 数：273

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Octoscan is a static vulnerability scanner for GitHub action workflows.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。