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
• A local app_risk_scan_sdk JAR
• JRE 8 or newer, or access to a configured S3-compatible managed JDK/JRE ZIP

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 local scanner SDK JAR
• securityScan.javaPath: optional absolute Java executable path when Java is not available on PATH
• securityScan.managedJavaS3Endpoint, managedJavaS3Bucket, managedJavaS3ObjectKey: S3-compatible JDK/JRE ZIP location
• securityScan.managedJavaS3Version, managedJavaS3Sha256: Java Runtime cache version and expected ZIP SHA-256
• securityScan.managedJavaS3ArchiveRoot, managedJavaS3ExecutablePath: location of java.exe inside the extracted ZIP
• securityScan.managedJavaS3AccessKeyId, managedJavaS3SecretAccessKey: temporary debugging credentials; do not use long-lived production credentials
• securityScan.preferManagedJava: force the managed Runtime during testing even when Java exists on PATH

For example:

{
  "securityScan.sdkJarPath": "C:\\tools\\app_risk_scan_sdk.jar",
  "securityScan.preferManagedJava": true,
  "securityScan.managedJavaS3Endpoint": "http://storage.example.internal:9020",
  "securityScan.managedJavaS3Bucket": "runtime-artifacts",
  "securityScan.managedJavaS3ObjectKey": "java/jdk8-windows-x64.zip",
  "securityScan.managedJavaS3Version": "1.8.0",
  "securityScan.managedJavaS3Sha256": "1079e1fcd8e33869fe4cbe4d3e914497f5b2c4ba19d4b2c27ff09401ad5a0846",
  "securityScan.managedJavaS3ArchiveRoot": "jdk1.8.0_202",
  "securityScan.managedJavaS3ExecutablePath": "bin/java.exe",
  "securityScan.managedJavaS3AccessKeyId": "temporary-ak",
  "securityScan.managedJavaS3SecretAccessKey": "temporary-sk"
}

The archive root must match the top-level directory inside the JDK/JRE ZIP. If the ZIP contains bin/java.exe directly, leave managedJavaS3ArchiveRoot empty. AK and SK are excluded from logs but remain a temporary integration mechanism that should move to the planned metadata and credential service.

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 resolves Java from javaPath, the managed Runtime cache, or the system PATH. When Java S3 settings are configured and a managed Runtime is required, it downloads the ZIP with a path-style S3 request, verifies SHA-256, extracts it safely, validates java.exe, and caches it in VS Code global storage. The scanner SDK remains external and is loaded from securityScan.sdkJarPath.

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.