Security Scanning

Qoder CLI CN has built-in security scanning that helps surface high-risk security issues during code generation and code changes. It works well as a continuous checking layer in everyday development, helping you catch dangerous function calls, injection risks, sensitive-information leaks, and cross-file data-flow issues early. Security scanning is not a complete substitute for a security team audit. It focuses primarily on code generated in the current task and incremental code changes, helping you find actionable issues before committing.

Entry point

Type in the interactive TUI:

/security-settings

This command opens the security scan settings panel, where you can view and toggle the different levels of scanning. Security scanning is enabled by default. The settings are written to the user-level configuration and control the switches for each scanning layer. L1 Static Check is free; L2 Lightweight Scan and L3 Deep Scan may consume Credits — refer to in-product notices and your account's current billing rules.

Scan levels

Qoder CLI CN splits security scanning into three levels. You can enable or disable each independently as needed.

L1 Static Check

L1 targets code generated in the current task. It quickly checks common issues through high-risk pattern matching, such as dangerous function calls, obvious sensitive-information leak patterns, and other risks that tend to appear in generated code. L1 Static Check is a free baseline check; we recommend keeping it on by default to quickly catch high-risk code patterns in the current task.

L2 Lightweight Scan

L2 targets incremental code changes. It goes further into code semantics to identify more complex risks, such as SQL injection, remote command execution, and sensitive data leaks. If you want deeper security feedback during everyday coding, we recommend enabling L2.

L3 Deep Scan

L3 performs deep analysis of incremental code changes. It traces complete data flows across files and functions, attempting to uncover hidden vulnerabilities that are hard to expose from a single-file view. L3 is best enabled before committing, before review, or after changes to security-sensitive modules, for a more comprehensive analysis.

Configuring scan levels

After opening /security-settings, use the arrow keys to move between scan levels and press Enter or Space to toggle. Press q or Esc to exit the panel. Each item in the panel shows its current state:

on means the level is enabled.
off means the level is disabled.
default means the default value is in use.
saved means the item has been written to the user-level configuration.

The settings panel writes only to the user-level configuration and does not modify project-level configuration.

Using the settings file

You can also configure security scanning in the user-level settings.json, under securityScan:

{
  "securityScan": {
    "l1StaticCheck": true,
    "l2LightweightScan": true,
    "l3DeepScan": true
  }
}

All three settings default to true. To turn a level off, set the corresponding field to false:

{
  "securityScan": {
    "l1StaticCheck": true,
    "l2LightweightScan": false,
    "l3DeepScan": false
  }
}

How automatic scanning works

With security scanning enabled, Qoder CLI CN loads the built-in security capabilities per your configuration and decides which checks to activate. When L1 is on, Qoder CLI CN triggers the static check capability after relevant tool calls. With L1 off, this automatic checking is not loaded. As long as at least one of L1, L2, or L3 is on, Qoder CLI CN keeps the unified security scanning capability. If L1, L2, and L3 are all off, security-scanning capabilities are not loaded.

Manual security scanning

Beyond the automatic scan settings, Qoder CLI CN also provides a manual security scan Skill:

/security-scan

Typing /security-scan directly pops up a mode picker with three scanning options:

L3 deep scan: deep cross-file, cross-function analysis of incremental code changes.
L2 lightweight scan: semantic-level risk identification for incremental code changes.
Project/file scan: run a cloud scan over the whole repository or a given path.

You can also state your intent right after the command to skip the picker:

/security-scan Run a full scan over the whole repository
/security-scan Run a security scan on the src/auth directory

Scans focus on genuinely exploitable risks, such as:

Identity issues like authentication bypass, token forgery, and session fixation.
Data-tampering issues like SQL injection, command injection, path traversal, and deserialization risks.
Information leaks like hardcoded secrets, sensitive information written to logs, and error messages exposing internal details.
Privilege escalation issues like missing authorization checks, unauthorized access, and role bypass.

Note: L2 lightweight and L3 deep scans are governed by the corresponding switches in /security-settings; once off, they cannot be triggered manually. The project/file scan is not affected by these two switches. Manual scans prioritize newly added or modified code (except the project/file scan), and try to exclude purely theoretical risks and issues already offset by existing protections.

When to use it

Security scanning fits well in these scenarios:

After Qoder CLI CN generates or modifies security-sensitive code, such as authentication, payments, data export, file upload, or command execution.
Before committing code, when you want a quick check on whether the current changes introduce high-risk issues.
Before review, when you want a heads-up on real-vulnerability-oriented security risks first.
When using automated modes, to keep a layer of continuous security checking.

Caveats

Security scanning focuses mainly on the current task and incremental changes. It is not a full security audit of the entire repository, nor does it guarantee finding all vulnerabilities. Scan results depend on the current code context, accessible files, and the enabled scan levels. For business-critical code, combine it with manual security review, testing, dependency scanning, and your organization's security processes. If security scanning does not work as expected, check the following first:

Whether the corresponding scan level is on in /security-settings.
Whether certain securityScan fields are explicitly turned off in the user-level settings.json.
If changed via the settings file, confirm the JSON is valid and saved to the user-level configuration.
Whether the current task actually produced new or modified code available for scanning.

Permissions: learn about tool-call approvals, permission modes, and allow/deny rules.
Hooks: learn how Qoder CLI CN executes automated logic around tool calls and the session lifecycle.
Skills: learn how to extend Qoder CLI CN's specialized capabilities with Skills.

​Entry point

​Scan levels

​L1 Static Check

​L2 Lightweight Scan

​L3 Deep Scan

​Configuring scan levels

​Using the settings file

​How automatic scanning works

​Manual security scanning

​When to use it

​Caveats

​Related