Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Actions: Extractor for external actions and workflows does not take into account the ref

Open
#21,834 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github-actions
Domain
devtools, security

Research direction

Start with the .github/actions/external/ convention and the CodeQL QL library behavior described for CompositeActionImpl.getResolvedPath(). Trace how uses: values such as actions/checkout@v5 and @v6 are matched, then define how refs or resolved SHAs should be represented. Done means different refs of the same external action or workflow are ingested and analyzed deterministically.

Written by the indexing model from the issue text.

Description

question

I'm trying to add external workflows to the repo before calling CodeQL. This would allow me to recurse into composite actions and callable workflows not defined in the same repo.

This would help detect cache poisoning attacks and unsafe checkouts from composite actions and callable workflows defined in different repos that the one being scanned. As well as other unsafe constructs inside these workflows and actions our organization might rely on.

The attack on tanstack, is an example of how the actual actions/cache call was "hidden" in a composite action:

https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

on:
  pull_request_target:
    paths: ['packages/**', 'benchmarks/**']

jobs:
  benchmark-pr:
    steps:
      - uses: actions/checkout@v6.0.2
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge # fork's merged code

      - uses: TanStack/config/.github/setup@main # transitively calls actions/cache@v5 

Currently, when storing external composite actions and callable workflows in .github/actions/external/ the actions are ingested and scanned along with the repos own workflows and thus more issues can be detected.

But the folder structure doesn't take into account the ref of the action, so I can only put a single implementation in, before scanning.

Why this is inherent to the CodeQL extractor's design

Looking at the CodeQL QL library conventions:

CompositeActionImpl.getResolvedPath() strips .github/actions/external/ → result is actions/checkout

The uses: string is actions/checkout@v5 — the QL library matches by path prefix, not by exact uses: string

So the CodeQL extractor itself doesn't support multiple versions of the same action at different refs. The directory convention has no slot for the version/ref.

Impact

When multiple workflows in the same repo use different versions of the same action, such as: actions/checkout@v5 and actions/checkout@v6, it's only possible to place one of these versions in the expected external folder.

This results in:

  • Incorrect analysis results: CodeQL may analyze v6's action.yml when the workflow actually uses v5, or vice versa. If the actions differ in their internal uses: or run: steps between versions, this could produce false positives or false negatives.
  • Non-deterministic: The result depends on the order dependencies are processed.
    Possible mitigations

Proposed solution:

Ensure the ref is somehow part of (or supported in) the directory structure:

.github/actions/external/actions/checkout/{ref}/path/action.yaml

Given that refs themselves can contain / and other unsupported characters, and that they may actually point to a different sha between runs, it might be even better to resolve the ref to a sha and when stored under that path:

.github/actions/external/actions/checkout/{sha}/path/action.yaml

That would result in the most predictable scans.

This may require a sha->ref lookup in order to resolve to the right composite action.

Dominant language
CodeQL
Stars
10.1k
Forks
2.1k
Avg merge
2d 16h
Merged PRs (30d)
143

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/codeql

All issues in github/codeql

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.