Skill

update-ci-image

skill:redis/go-redis#update-ci-image

Use when adding, updating, or removing a `redislabs/client-libs-test` image tag used by the test stack — covers every place a Redis version → image-tag mapping lives so local `make test` and GitHub CI stay in sync.

SkillsMP

Verdict

Suspicious

Risky behavior the analysis could not rule out.

Analyzed Oct 27, 2026, 22:44 UTC at eda1d05

findings

high

highest severity

threat classes

622

files scanned

223/223

checks satisfied

package advisories

Why this verdict

suspicious: finding skill:.claude/skills/update-ci-image:.github/workflows/test-redis-enterprise.yml:16:EXEC

Security findings 1

Code execution

highContextual risklow confidence

The test-redis-enterprise CI workflow checks out the RedisLabs/redis-ee-docker repository at an unpinned default-branch ref and executes that repository's ./build.sh in the job, a clone-and-execute chain whose executed code is not pinned by this workflow (currently gated off by jobs.build.if: false, with only placeholder RE_USERNAME/RE_PASS values in scope).

.github/workflows/test-redis-enterprise.yml:16-19

jobs.build.steps[1].with.repository: RedisLabs/redis-ee-docker

vector:code

Counter-argument considered

The claim is accurate: the job checks out RedisLabs/redis-ee-docker with no ref pin and runs ./build.sh from that checkout, a connected clone-and-execute chain in a GitHub CI file whose version→tag matrix falls within the skill's declared GitHub-CI mapping scope. The if:false gating is explicitly temporary ('should be enabled when we have a current and stable RE build') and the placeholder credentials were already disclosed in the claim itself, so nothing in the evidence neutralizes the dormant unpinned-execution pattern; severity remains low.

Coverage gaps 1

Parts of the artifact the static analysis could not fully examine.

context:manifest_unparseable yaml: YAML aliases are not permitted

docker-compose.yml