feat: Linux ARM64 and Linux AMD64 binaries are now statically linked

[j-luong]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

snyk-linux and snyk-linux-arm64 binaries are now statically linked instead of dynamically linked.

This PR promotes the statically linked binaries for Linux amd64/arm64 that were previously available on the experimental distribution channel.

Where should the reviewer start?

See related linuxstatic epic

How should this be manually tested?

Validating the binary is statically linked

• Download the snyk-linux and snyk-linux-arm64 binaries from the feat/linuxstatic-e2e branch
• Rename them snyk-linuxstatic and snyk-linuxstatic-arm64 respectively
• Download the latest snyk-linux and snyk-linux-arm64 binaries from downloads.snyk.io
• Make the binaries executable via chmod +x
• Move the binaries into a folder snyk
• docker pull ubuntu:18.04 to get a Linux image with an unsupported glibc library
• Run your docker image and mount the binaries: docker run --rm -it -v ./snyk/.:/mnt/. -w /mnt ubuntu:18.04 bash
• For each binary in the container, run snyk-[OS]-[ARCH] -v

Additional testing

• mount the CLI project into the docker container
• Run the acceptance testing: TEST_SNYK_COMMAND=./snyk-linuxstatic npx jest test/jest/acceptance

Expected output:

What's the product update that needs to be communicated to CLI users?

Linux binaries are now statically linked

Risk assessment - Medium?

To reduce risk, a slow rollout has been ongoing, and currently ~30-35% of Linux users are already using the statically linked binaries. This PR rolls it out to 100% of users.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[j-luong]

PR Reviewer Guide 🔍

🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Possible path mismatch 🟡 [minor]
The Makefile now forces V1_BINARY_SUBFOLDER to experimental/ whenever STATIC_NODE_BINARY is true. If this PR intends to promote static binaries to the primary distribution channel (as stated in the description), hardcoding them to the 'experimental/' subfolder in the build logic may result in artifacts being placed in the wrong directory during the final packaging phase, potentially conflicting with the StaticFiles list in upload-artifacts.sh which expects them at the root of the release folder.

ifeq ($(STATIC_NODE_BINARY), true)
	V1_BINARY_SUBFOLDER = experimental/
endif

📚 Repository Context Analyzed

This review considered 5 relevant code sections from 4 files (average relevance: 0.78)

• release-scripts/upload-artifacts.sh (lines 1-195)
• release-scripts/docker-desktop-release.sh (lines 1-31)
• docker-desktop/build.sh (lines 1-57)
• CONTRIBUTING.md (2 segments, lines 218-387)

V1_BINARY_SUBFOLDER only controls the location of the TS CLI binary to embed not the upload destination in upload-artifacts.sh

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Broken Artifact Path 🟠 [major] The logic introduced to set V1_BINARY_SUBFOLDER = experimental/ when STATIC_NODE_BINARY is true will cause the main Linux binaries (which are being promoted to static in this PR) to be placed in the experimental sub-directory. This contradicts the PR's goal of promoting these to the main distribution. Downstream jobs like acceptance-tests linux amd64 expect the binary at the root (./binary-releases/snyk-linux), and the upload-artifacts.sh script (see cross-file context) will fail to include the new static binaries in the primary release bundle as it also looks in the root directory. ifeq ($(STATIC_NODE_BINARY), true) V1_BINARY_SUBFOLDER = experimental/ endif Makefile Syntax Error 🟠 [major] Line 98 appears to use a leading tab for the variable assignment V1_BINARY_SUBFOLDER = experimental/. In a Makefile, a leading tab at the start of a line is reserved for recipe commands. Since this assignment is located at the top level and not part of a target rule, it will likely cause a 'commands commence before first target' error, preventing the build from running. V1_BINARY_SUBFOLDER = experimental/

📚 Repository Context Analyzed This review considered 5 relevant code sections from 4 files (average relevance: 0.79) release-scripts/upload-artifacts.sh (lines 1-195) release-scripts/docker-desktop-release.sh (lines 1-31) docker-desktop/build.sh (lines 1-57) CONTRIBUTING.md (2 segments, lines 218-387)