feat: support Snyk Code Local Engine on the native code-client-go path

[fsargent]

Description

Enables the native (code-client-go) Snyk Code path for Snyk Code Local Engine (SCLE) orgs, and makes OAuth2 auth work against the local engine — the functional-parity prerequisite for removing the TypeScript @snyk/code-client dependency from the CLI (COIN-2539, CLI-589).

SCLE was disabled on the native path via a && !scleEnabled guard. Three things were missing to support it; this PR addresses all three:

1. URL mapping — SnykCodeApi() now returns localCodeEngine.url from the cached SAST settings when SCLE is enabled, instead of the naive api→deeproxy string replacement that ignored it (new localCodeEngineURL() helper).
2. Auth — register the local engine URL in AUTHENTICATION_ADDITIONAL_URLS. GAF's networking middleware (middleware/auth_header.go) only attaches credentials to the configured API host, its deeproxy subdomain, or URLs in that allowlist; a customer-hosted SCLE URL matches none, so without this the engine is called unauthenticated. Registering it applies the standard auth flow (incl. OAuth2 bearer + refresh) to SCLE requests.
3. API surface (per @peter.schafer's review) — SCLE implements the old deeproxy API, not the new test service that UploadAndAnalyze → RunTest uses. SCLE scans are now routed through the legacy scanner (UploadAndAnalyzeLegacy → RunLegacyTest, the deeproxy implementation the IDE team moved into this repo), draining its status channel for progress.

Plus: drop the && !scleEnabled guard, and centralize the internal_sast_settings / internal_snyk_scle_enabled config keys in code_workflow (aliased from pkg/code).

Decisions (from review)

• --report on SCLE is not supported (reporting goes through the test service). It now errors early with a clear message instead of silently using the test-service path. Covered by Test_defaultAnalyzeFunction_reportNotSupportedWithSCLE.
• shardKey is passed empty — deeproxy uses it only for cache sharding, so it is optional for a CLI scan (the IDE supplies one for editor caching). Documented at the call site.

Tests

Test_SnykCodeApi, Test_registerLocalEngineAuthURL, updated useNativeImplementation + Test_Code_entrypoint. The SCLE→legacy-scanner selection is not unit-covered (the scanner isn't injectable into defaultAnalyzeFunction) — it needs the live/e2e run below.

Still required before broad enablement: an end-to-end run against the scle-prod-cluster org (Code Integrations owns it) with {OAuth2, token} — the unit tests cover URL/auth/routing logic, not a real local-engine handshake.

Checklist

• Tests added and all succeed
• Linted
• README.md updated, if user-facing — n/a (internal routing change, no public API change)

🚨After having merged, please update the snyk-ls and CLI go.mod to pull in latest client.

Refs: COIN-2539, CLI-589

[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.

[fsargent]

• feat: support Snyk Code Local Engine on the native code-client-go path #158 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[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.

[fsargent]

@PeterSchafer — you're right, that was the missing piece. Confirmed in the code: defaultAnalyzeFunction was calling UploadAndAnalyze → RunTest (the new test-service API), which SCLE doesn't implement.

Pushed a commit that routes SCLE scans through the legacy/deeproxy scanner the IDE team moved in (UploadAndAnalyzeLegacy → RunLegacyTest), in addition to the URL + auth mapping. So all three pieces are now in place: SCLE URL → localCodeEngine.url, auth via AUTHENTICATION_ADDITIONAL_URLS, and the deeproxy API surface.

Two things I'd value your read on (also in the description):

1. --report on SCLE — RunLegacyTest has no test-service reporting, and the remoteCode branch still returns early via AnalyzeRemote before the SCLE check. Should snyk code test --report work on SCLE, or should we error?
   I think we just error, right?
2. shardKey — passing empty for now (deeproxy cache sharding only); the IDE supplies one. OK for the CLI?

[fsargent]

Addressed review:

• API surface: SCLE now routes through UploadAndAnalyzeLegacy → RunLegacyTest (deeproxy), not the test service.
• --report on SCLE: now errors early ("--report is not supported with Snyk Code Local Engine") rather than silently hitting the test-service path. Added a unit test.
• shardKey: passing empty — deeproxy uses it only for cache sharding, optional for a CLI scan. Documented at the call site.

Automated-review findings:

• Data loss in ResultMetaData (major) — this is a false positive: UploadAndAnalyzeLegacy returns no ResultMetaData (web UI URL / project / snapshot id are test-service concepts that don't exist for an SCLE file test), and TranslateMetadataToLocalFindingModel is fully nil-guarded. There's no metadata to lose.
• Inconsistent signature (minor) — fixed: analyzeWithLegacyEngine now returns the 4-tuple matching OptionalAnalysisFunctions, with an explicit nil ResultMetaData + comment explaining why.

Still pending: live run against scle-prod-cluster to confirm the end-to-end handshake.

[danskmt]

LGTM - left some comments

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Runtime Panic 🔴 [critical] The function analyzeWithLegacyEngine explicitly returns nil for *scan.ResultMetaData. However, the caller EntryPointNative (visible in context) passes this metadata directly to local_models.TranslateMetadataToLocalFindingModel(resultMetaData, ...). Since that function attempts to read fields from the metadata to populate the local model, passing nil will cause a runtime panic during every SCLE scan. return result, bundleHash, nil, err Configuration Inconsistency 🟡 [minor] The SnykCodeApi function returns an empty string if tryGetLocalCodeEngineURL fails while SCLE is enabled. This results in the codeclient being initialized with an empty base URL, which will lead to malformed requests (e.g., requests to path /bundle instead of https://engine/bundle). While defaultAnalyzeFunction adds a check, other potential callers of SnykCodeApi or direct library users of codeClientConfig are not protected by that check. return ""

📚 Repository Context Analyzed This review considered 23 relevant code sections from 13 files (average relevance: 0.97) README.md (lines 1-152) internal/analysis/analysis.go (2 segments, lines 1-236) scan.go (2 segments, lines 1-244) CONTRIBUTING.md (lines 1-204) internal/analysis/mocks/analysis.go (lines 1-88) config/config.go (lines 1-28) internal/deepcode/mocks/client.go (lines 1-84) ... and 6 more file(s)

🤖 Repository instructions applied (from AGENTS.md)

[minsiyang]

Should we use an explicit Error Catalog error to avoid a generic CLI failure like Peter suggested?

[graphite-app]

Merge activity

• Jun 24, 12:02 PM UTC: fsargent added this pull request to the Graphite merge queue.
• Jun 24, 12:04 PM UTC: Merged by the Graphite merge queue.