A “security audit” workflow can be the attack: how to review GitHub Actions
A repository receives a change called “Add security audit workflow”. It looks like maintenance, comes from a familiar account and promises to make the project safer. The question to ask is what the new automation will actually do when it runs.
GitHub Actions is a system for running automated jobs linked to a repository, such as tests or releases. A workflow is the file that describes when those jobs start and which steps they run. Because a job can receive code, credentials and permissions, reviewing a workflow is also reviewing an access decision.
Why this matters in October 2026
In research published on 9 October, Socket described an October GhostAction campaign in which compromised maintainer accounts added a workflow named security-audit.yml. Socket reported that the workflow collected credentials from Actions secrets and searched repository content and history for more. Its investigation did not establish how the maintainer credentials were first obtained.
That is a reported case, not evidence that your repository is affected. The useful lesson for an everyday review is that a reassuring filename and a familiar author do not establish what code does. The exercise below is an original way to structure that review, informed by the report and GitHub’s secure-use guidance.
Understand the four things a job receives
Before looking for a particular suspicious command, ask which event starts the job, what code it executes, what data or credentials it can access, and where it can send results. Together these describe the job’s reach.
A job that checks formatting normally needs a different scope from one that publishes a release. Even a read-only repository token does not make a job harmless if you separately pass it a powerful publishing credential. Record those permissions separately rather than treating “the token is restricted” as the end of the review.
Five questions for a workflow change
1. What event starts it?
Purpose: Understand when the proposed behaviour becomes possible.
Read the trigger and any branch or path restrictions. Does the job run on a push, a pull request, a schedule or a manual request? Ask the author to explain how that trigger supports the intended task. Consider who can cause the event and whether the job operates on trusted or untrusted inputs.
Illustrative review question: “This is described as a release check. Why does it need to run for every branch?” There may be a legitimate answer. Make the scope explicit before deciding whether it is appropriate.
2. Which code will actually run?
Purpose: Review the executable behaviour behind the label.
Look at scripts and referenced actions, not just the workflow’s title. If a step downloads and runs something else, include that dependency in the review. Ask which revision has been assessed and how updates to it are handled.
GitHub recommends pinning actions to a full-length commit SHA and auditing their source. A SHA identifies a specific revision; it does not prove that revision is safe. Keep a maintenance plan so reviewed dependencies can still receive necessary fixes. Avoid copying a revision identifier from an unrelated example and assuming it is appropriate for your project.
3. Which permissions and secrets are necessary?
Purpose: Compare granted access with the job’s actual purpose.
List the repository-token permissions, separately supplied secrets and any cloud access the job can obtain. For each, write the operation that needs it. GitHub recommends minimum token permissions and least-privilege credentials. “Other workflows use this secret” is not a reason to give it to a new job.
In a review, ask for the sensitive value’s purpose and scope, not for someone to paste it into a comment. Use your organisation’s approved methods for managing credentials. Keep genuinely necessary release permissions confined to the relevant work.
4. Where does information go?
Purpose: Make external communication understandable.
Ask which services receive logs, reports, artifacts or network requests. An artifact is an output saved by the workflow, such as a test report. Decide what it may contain and who should be able to retrieve it. A security tool may need an external service, but the team should know which service and why.
If an unfamiliar destination appears, verify it through the tool’s documentation and the responsible owner. Do not visit suspicious infrastructure or run the proposed workflow just to see what it does. Request a safe review route from the team responsible for the repository.
5. Who approves and maintains it?
Purpose: Give the access decision a named owner.
Agree who can explain the change, who reviews sensitive workflow modifications and who responds to an unexpected run. Confirm how those expectations are enforced in your actual repository settings, including any exceptions. A review convention written in a team document may not stop a direct change by an account with broad access.
Revisit the workflow when its purpose changes. A small formatting job can accumulate publishing, deployment and notification steps over time. The old approval does not explain the new permissions.
Worked example: the report that does not need a release key
Illustrative example: a fictional team proposes a documentation-link check. Its intended result is a report of broken links in changed documentation. The proposed job also receives a package-publishing credential because it was copied from a release workflow.
The reviewer records the mismatch: publishing a package is outside the stated purpose. The author removes that credential, explains the report destination and provides a small test change containing one deliberately broken link. The expected result is a useful report without a package release or unrelated external upload.
This is a proposed review exercise, not a complete security test. It makes one assumption visible and gives the team a specific change to discuss. A security reviewer may identify other risks in the scripts, inputs or runner environment.
Keep a short review note
Record the purpose, trigger, reviewed code revision, permissions and secrets, external destinations, owner and expected evidence from a safe test. Include unresolved questions and the person who can answer them. Use the note to explain the decision without recording secret values.
If an unexpected workflow has already run, involve the repository owner and security responders. Preserve the change and run records through the approved incident process before cleanup. Responders can assess which credentials and systems may be involved and decide on containment and rotation. Deleting the workflow alone does not establish that any resulting access has ended.
For your next review, choose one automation change and ask the author to connect every permission to a named step. If the explanation is incomplete, that is a useful question to resolve before running it.
Sources and review
Researched and reviewed 19 October 2026. Recent reporting: Socket’s GhostAction investigation, 9 October. Technical reference: GitHub secure-use guidance. The review note, questions and documentation example are original editorial exercises. No affected-system assessment has been carried out for any reader.
You May Also Like
Harnessing the Power of the MoSCoW Method: An In-Depth Guide with Practical Examples
Effective Product Backlog Creation: A Step-by-Step Guide for Agile Teams
