CMB Risk Scan

CMB Risk Scan is a local VS Code extension that scans saved Git-diff lines for security risks.

Prerequisites

• Local VS Code 1.100 or newer
• A trusted local file workspace
• JRE 8 or newer
• A locally downloaded app_risk_scan_sdk JAR

Configuration

Configure these resource-level settings for each workspace folder:

• securityScan.tenantId: tenant ID as a decimal string
• securityScan.env: target environment (DEV, ST, UAT, or PRD)
• securityScan.commitUser: employee ID used for the scan request
• securityScan.repoUrl: optional repository URL override
• securityScan.branch: optional branch override

Configure these machine-level settings:

• securityScan.sdkJarPath: required path to the pre-downloaded scanner SDK JAR
• securityScan.javaPath: optional absolute Java executable path when Java is not available on PATH

For example:

{
  "securityScan.sdkJarPath": "/path/to/app_risk_scan_sdk-1.0.10-jar-with-dependencies.jar"
}

Run Risk Scan: Set Token (securityScan.setToken) to store the scan token in VS Code secret storage. Never put a real token or other secret in workspace settings or source files.

Windows debug page

An installed VSIX can be diagnosed without extension source code. Open the VS Code Command Palette with Ctrl+Shift+P and run Risk Scan: Open Debug Page.

The page reports the detected Java runtime, configured SDK JAR, workspace trust and locality, Git repository and branch, token presence, and Java Bridge state. It also shows redacted logs from the current VS Code session. Token values are never displayed or copied.

Use Recheck environment after changing VS Code settings, Restart Bridge after correcting Java or JAR problems, and Copy diagnostics to collect a safe troubleshooting report. Set Token opens the same secure VS Code input used by the Command Palette. These diagnostic commands remain available even when Java, the SDK JAR, or the Bridge cannot start.

For temporary SDK troubleshooting, set securityScan.revealSdkLogs to true and restart the Bridge. SDK stderr is then shown after Token, password-like assignments, and statements pass through the extension redactor. The output may still contain internal paths or SDK implementation details, so disable this setting after debugging.

Local stub SDK

When the internal scanner SDK is unavailable, build the development-only Stub SDK:

npm run build:stub-sdk

Configure securityScan.sdkJarPath with the absolute path to sdk-stub/target/risk-scan-sdk-stub.jar. The Stub uses the same external-JAR discovery and reflection path as the real SDK. It returns one PASSWORD_SEC risk only when a saved Git-increment line matches password: 123456; all other input returns no risks. The Stub JAR is excluded from the production VSIX.

Run npm run verify:stub-sdk to build both JARs and verify the complete Bridge-to-Stub reflection call.

Validation flow

The validation build scans only after a file is saved. It calculates the new-side lines changed from Git HEAD and sends only that increment for analysis. Only the PASSWORD_SEC rule is enabled; other rules and unsaved editor changes are not scanned.

At startup, the extension validates securityScan.sdkJarPath and loads that local SDK JAR directly. It does not download the scanner SDK, and the SDK is not bundled in the VSIX. This temporary local-file flow trusts the explicitly configured JAR and does not perform an embedded SHA-256 check.

The Java Bridge is persistent: one process serves multiple saved-file scans. SDK log lines are isolated from the prefixed protocol and their content is omitted from extension logs. If Git HEAD cannot provide a reliable increment and there are no saved editor-change lines, scanning is skipped instead of falling back to the whole file.

Development verification

Use JDK 17 and Maven to build the Java 8-compatible Bridge, then run:

npm run check
npm run build:bridge
npm run bundle
npm run test:e2e
npm run package

Real SDK validation must run inside the company network. See docs/real-sdk-validation.md for the sanitized validation matrix.