Security vulnerabilities in CI workflow

[ItsMeForLua]

I noticed a few security issues in ci.yml that I feel may be worth concern.

---

Node.js 20 deprecation

n.b., This one is particularly time sensitive.
actions/checkout@v4 and actions/cache@v4 both run on the Node.js 20 runtime, which GitHub is force-migrating to Node.js 24 starting June 16th. After that date these will produce errors and eventually stop working entirely. Both need to be updated to @v5.

---

Actions pinned to mutable version tags (CWE-829, CWE-494)

uses: actions/checkout@v4
uses: actions/cache@v4

Version tags like @v4 are mutable, so, they can be secretly repointed to different commits at any time. Pinning to a full commit SHA should ensure the workflow actually executes exactly the code that was reviewed:

uses: actions/checkout@<SHA>
uses: actions/cache@<SHA>

Downloaded artifacts have no integrity verification CWE-494

Three downloads happen with no checksum verification:

# CCL binary with no SHA check
curl -o ccl.tar.gz ... 'https://github.com/Clozure/ccl/releases/download/v1.12/ccl-1.12-linuxx86.tar.gz'

# Quicklisp also with no SHA check
curl -o quicklisp.lisp 'https://beta.quicklisp.org/quicklisp.lisp'

If either upstream is compromised, arbitrary code runs in the CI environment. Adding a sha256sum -c check after each download should fix this:

echo "expected-sha256  ccl.tar.gz" | sha256sum -c
echo "expected-sha256  quicklisp.lisp" | sha256sum -c

Unpinned git clone of external repos CWE-829

git clone --recurse-submodules --depth 1 ... https://github.com/grpc/grpc
git clone https://github.com/qitab/cl-protobufs

Both clone the current HEAD of the default branch, meaning, the build silently changes whenever those repos receive new commits. Adding --branch <tag> and then checking out a specific commit hash would make these a bit more deterministic, which is also a concern regarding reproducibility of a CI/CD test.

ubuntu-latest is a mutable runner tag CWE-829

runs-on: ubuntu-latest

ubuntu-latest can be redirected by GitHub to a different Ubuntu version. ubuntu-24.04 pins to a known LTS release.

---

I can submit a PR as well if wanted. I need to update some my repos with similar fixes anyway.

[ItsMeForLua]

@Slids Actually, I was looking at the openclaw repo, and they use a static analyzer for github actions called zizmor. I haven't used it before, but it seems worth it perhaps. IF you end up creating more workflows, otherwise it's just more overhead.

Figured I'd mention it since RPC is a frequent attack vector, though, mostly the legacy ones like Microsoft's RPC. From what I know at least, I'm not a security expert.

[Slids]

What is the attack vector your looking at?
The CI is running on GitHubs servers, so yes you could have the CI run do something wonky but
nothing you couldn't do with just making your own repo...
You could have someone else submit a bad change possibly by intercepting the CCL build and getting that to pass but you still need to be correct with SBCL...
I agree with setting exact versions of grpc/cl-protobufs, thats just a good idea.

[ItsMeForLua]

That's a fair point regarding SBCL as a second factor. I should of clarified what the actual risk model is.

Another way to word the following paragraph is that the primary attack vector isn't really someone controlling GitHub's servers; , it's supply chain compromise specifically regarding dependencies.

The concern isn't really GitHub's infrastructure being compromised specifically. It's more-so regarding tag mutability and asset replacement at the source.
The v1.12 release tag on the Clozure repo for example, could theoretically be repointed, or a release asset silently swapped. The sha256 check catches that because the hash stops matching, so you get a loud failure instead of silently running something unexpected. It's a one-liner and the guarantee is hard rather than being left to probability.

You are also r right that SBCL running the same tests is a meaningful mitigation, as a compromised CCL that produces wrong results would likely get caught there (Assuming they also also do verification, but i haven't checked).
However, a compromised binary that exfiltrates secrets or tampers with build artifacts wouldn't necessarily fail ANY tests. Simply because those two threat models are somewhat orthogonal.
In otherwords, he two threat models are independent of each other,so, catching one doesn't necessarily help you catch the other.
For example, SBCL catching wrong test results from a bad CCL build is independent of whether a compromised binary is doing something outside the test suite, like reading environment variables, exfiltrating secrets, modifying artifacts, etc.

Those are two separate failure modes that don't overlap. Passing one check says nothing about the other.
So "SBCL would catch it" is only true for the subset of compromises that manifest as incorrect test output. It says nothing about the subset that are specifically designed not to affect test output.

The mutable action tags (@v4) are a separate surface from the CCL download, as that's specifically about a compromised GitHub account on the actions/ maintainer side repointing a tag, which has actually happened to popular actions in the wild before. SHA pinning closes that regardless of what happens upstream.
The git clone HEAD on grpc and cl-protobufs I think we agree on, as that's just good hygiene for reproducibility, which is independent of security in some regard.
Either way, I am glad the PRs are in. My mention of zizmor was just a heads up since RPC is a higher-value target than most, but I do understand if it's not worth the overhead for just one workflow. I tend to over engineer things.

---

Some examples of relevant supply chain attacks:
https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/

https://www.rapid7.com/blog/post/2021/04/16/codecov-discloses-supply-chain-compromise/