Should I upgrade to Snyk CLI Linux now?
Teams running Snyk in CI need change awareness on the July 16, 2025 glibc floor increase so Linux runners do not fail after CLI upgrades.
Blockers
- requires_version: package/snyk-cli-1-1298-0 → package/glibc-2-28
- requires_version: package/snyk-cli-1-1298-0 → package/glibc-2-31
- breaking_change_in: package/snyk-cli-1-1298-0 → vendor/snyk
- Lock-in via package/snyk-cli-1-1297-1
- breaking_change_in: package/snyk-cli-1-1297-3 → vendor/snyk
Who this is for
- low-ops
- enterprise
- compliance
Candidates
Upgrade Linux runners so the installed CLI can move to v1.1298.0 and later
As of 2026-03-29, this is the cleanest long-term path because the glibc requirement change has already occurred. Snyk's July 2025 announcement and the v1.1298.0 release notes state that Linux x64 now requires glibc 2.28 or higher, and Linux arm64 now requires glibc 2.31 or higher. The change only affects Linux; macOS and Windows were explicitly called out as unaffected by this glibc update. There is no separate pricing change tied to this decision in the official notices.
When to choose
Use this when you control the base OS for GitHub Actions, GitLab, Jenkins, or other Linux runners and want to stay current on Snyk CLI releases without special pinning. It is the decisive option when you want the least ongoing operational drift and fewer surprise failures on future CLI upgrades.
Tradeoffs
Best long-term maintainability and security posture, but it may require coordinated runner image or distro upgrades across CI fleets.
Cautions
Treat this as a libc and base-image migration, not just a CLI bump. Snyk noted likely failure signatures mentioning missing symbols such as "GLIBC_2.27" or "GLIBC_2.31".
Temporarily pin the CLI below v1.1298.0 while planning the runner upgrade
As of 2026-03-29, this is a short-term containment option for pipelines that cannot yet meet the new glibc floor. Snyk's July 2025 update explicitly recommended pinning to v1.1297.1 as the last version before the new glibc requirements took effect. Separately, Snyk announced v1.1297.3 on June 25, 2025 to address CVE-2025-6624 in debug logging, so teams should not freeze on an old pre-1.1298 build without checking the security implications. There is no pricing difference in the official sources; the tradeoff is operational and security-related.
When to choose
Use this when runner OS changes are blocked by change-control, base image ownership, or enterprise platform timing. The decisive factor is whether you need an immediate no-downtime workaround more than you need to stay on the current CLI train.
Tradeoffs
Fastest workaround and usually the lowest-change path, but it creates version drift and can leave you juggling pre-floor releases versus later security hotfixes.
Cautions
Do not treat a pre-v1.1298 pin as a steady state. Snyk's own temporary pin guidance named v1.1297.1, while a later pre-floor hotfix v1.1297.3 was released for a security issue, so teams should check the release stream before standardizing a long-lived pin.
Run Snyk from a custom container image with a compatible libc baseline
As of 2026-03-29, this is the best path when host runners are hard to upgrade but your CI system can execute containerized jobs. Snyk documents user-defined custom images for CLI and states that custom images can extend environment support to any environment supported by the Snyk CLI, provided the image uses a supported environment, includes the CLI, and is publicly accessible where required by the integration. This lets teams control libc and language runtime together instead of depending on the host runner's glibc. No official pricing change is attached to this option in the cited docs.
When to choose
Use this when CI runner images are centrally managed or old, but you can switch the Snyk execution step into a custom Docker image. The decisive factor is whether containerizing the scan step is easier than upgrading the underlying Linux fleet.
Tradeoffs
Good isolation and reproducibility, but it adds image maintenance, registry workflow, and integration-specific setup.
Cautions
Do not rely on the old Snyk CLI Images on Docker Hub for this strategy. Snyk announced those images were removed from Docker Hub on August 12, 2024 and directs users to build their own custom images instead.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Snyk CLI Linux now?"