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

Inizia con la convenzione .github/actions/external/ e il comportamento della libreria CodeQL QL descritto per CompositeActionImpl.getResolvedPath(). Traccia il modo in cui vengono confrontati valori uses: come actions/checkout@v5 e @v6, quindi definisci come devono essere rappresentati i ref o gli SHA risolti. Il lavoro è completato quando ref diversi della stessa action o dello stesso workflow esterno vengono acquisiti e analizzati in modo deterministico.

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.