code-security-scanner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Security Scanner

代码安全扫描器

Scan code repositories for malicious behavior: data theft, backdoors, code injection, supply-chain attacks, and sensitive file access. Optimized for TypeScript/JavaScript/Node.js but applicable to general codebases.

扫描代码仓库中的恶意行为：数据窃取、后门、代码注入、供应链攻击以及敏感文件访问。针对TypeScript/JavaScript/Node.js优化，但也适用于通用代码库。

Security Auditor Mindset

安全审计员思维模式

Before scanning, think like an attacker:

Motivation: What valuable data exists in this project? (API keys, user data, financial info, cloud credentials)
Attack Surface: What are the entry points? (
```
npm install
```
lifecycle, runtime execution, build pipeline, CI/CD)
Stealth: How would an attacker hide malicious code? (obfuscation, delayed execution via
```
setTimeout
```
, legitimate-looking variable names, deeply nested dependencies)
Exfil Path: How would stolen data leave? (HTTP POST, DNS queries, WebSocket, embedded in error logs, encoded in image metadata)

Ask yourself: "If I were a malicious actor with commit access or supply-chain control, where would I hide code and how would I avoid detection?"

扫描前，先从攻击者的角度思考：

动机：该项目中存在哪些有价值的数据？（API密钥、用户数据、财务信息、云凭证）
攻击面：入口点有哪些？（
```
npm install
```
生命周期、运行时执行、构建流水线、CI/CD）
隐蔽方式：攻击者会如何隐藏恶意代码？（混淆、通过
```
setTimeout
```
延迟执行、看似合法的变量名、深度嵌套的依赖项）
泄露路径：被盗数据会如何流出？（HTTP POST、DNS查询、WebSocket、嵌入到错误日志、编码到图片元数据）

自问：“如果我是拥有提交权限或供应链控制权的恶意攻击者，我会在哪里隐藏代码，又该如何避免被检测到？”

Severity Triage Principle

严重程度分级原则

Not all findings are equal. Prioritize by blast radius × stealth:

Priority	Blast Radius	Stealth Level	Example
P0	Full credential theft	High (obfuscated)	Base64-encoded exfil URL + env var harvest
P1	Single secret leaked	Medium	Hardcoded webhook URL with API key
P2	Potential access	Low (visible)	`eval()` with user-controlled input
P3	Informational	None	Unpinned dependency version

并非所有发现的问题都同等重要。需按照影响范围 × 隐蔽程度来划分优先级：

优先级	影响范围	隐蔽级别	示例
P0	完整凭证窃取	高（已混淆）	Base64编码的泄露URL + 环境变量窃取
P1	单个密钥泄露	中	硬编码包含API密钥的Webhook URL
P2	潜在访问权限	低（可见）	使用用户可控输入的 `eval()`
P3	信息性提示	无	未固定版本的依赖项

Core Workflow

核心工作流程

Step 1: Determine Scan Scope

步骤1：确定扫描范围

Identify the project structure before scanning:

Locate

package.json

tsconfig.json

.npmrc

, lockfiles (

package-lock.json

yarn.lock

pnpm-lock.yaml

)

Identify entry points:
```
main
```
,
```
scripts
```
,
```
bin
```
fields in
```
package.json
```
List all
```
preinstall
```
/
```
postinstall
```
/
```
prepare
```
lifecycle scripts
Note any
```
.env
```
,
```
.env.*
```
, or config files containing potential secrets
Check if monorepo — scan all
```
packages/*/package.json
```
if
```
workspaces
```
field exists

For non-npm projects (Deno, Bun, or plain scripts): Skip dependency analysis and focus on code pattern scanning (Phases 1-3, 5).

扫描前先明确项目结构：

定位

package.json

、

tsconfig.json

、

.npmrc

以及锁文件（

package-lock.json

、

yarn.lock

、

pnpm-lock.yaml

）

识别入口点：
```
package.json
```
中的
```
main
```
、
```
scripts
```
、
```
bin
```
字段
列出所有
```
preinstall
```
/
```
postinstall
```
/
```
prepare
```
生命周期脚本
记录任何包含潜在密钥的
```
.env
```
、
```
.env.*
```
或配置文件
检查是否为单体仓库 —— 若存在
```
workspaces
```
字段，则扫描所有
```
packages/*/package.json
```

针对非npm项目（Deno、Bun或纯脚本）：跳过依赖项分析，专注于代码模式扫描（阶段1-3、5）。

Step 2: Load Detection Rules

步骤2：加载检测规则

Load the reference file(s) matching the scan type:

User Request	MUST Load	Do NOT Load
"full security audit"	ALL 5 references	(none)
"check for credential leaks / data exfiltration"	`references/data-exfiltration.md`	dependency-risks, filesystem-risks
"check for backdoors"	`references/backdoor-detection.md`	dependency-risks, filesystem-risks
"scan for malicious code / eval"	`references/malicious-code-patterns.md`	dependency-risks, filesystem-risks
"audit npm dependencies"	`references/dependency-risks.md`	data-exfiltration, backdoor-detection
"check for sensitive file access"	`references/filesystem-risks.md`	data-exfiltration, backdoor-detection

IMPORTANT: For targeted scans, load ONLY the relevant reference. Do NOT load all 5 references for a focused request — this wastes context and dilutes attention.

加载与扫描类型匹配的参考文件：

用户请求	必须加载	禁止加载
"全面安全审计"	全部5个参考文件	无
"检查凭证泄露/数据泄露"	`references/data-exfiltration.md`	dependency-risks、filesystem-risks
"检查后门"	`references/backdoor-detection.md`	dependency-risks、filesystem-risks
"扫描恶意代码/eval"	`references/malicious-code-patterns.md`	dependency-risks、filesystem-risks
"审计npm依赖项"	`references/dependency-risks.md`	data-exfiltration、backdoor-detection
"检查敏感文件访问"	`references/filesystem-risks.md`	data-exfiltration、backdoor-detection

重要提示：针对定向扫描，仅加载相关参考文件。不要为聚焦型请求加载全部5个参考文件 —— 这会浪费上下文并分散注意力。

Step 3: Execute Scan

步骤3：执行扫描

Scan in severity order — Critical (🔴) first, then Medium (🟡):

按严重程度顺序扫描 —— 先关键（🔴），再中等（🟡）：

🔴 Phase 1: Data Exfiltration Detection

🔴 阶段1：数据泄露检测

MANDATORY: Read

references/data-exfiltration.md

for grep patterns.

Search for patterns that send sensitive data to external servers.

Key signals:

HTTP requests containing
```
process.env
```
, API keys, or tokens in the body/headers
Hardcoded URLs receiving environment variable data
Base64-encoded destination URLs
DNS-based exfiltration patterns

必须：阅读

references/data-exfiltration.md

获取grep模式。

搜索将敏感数据发送到外部服务器的模式。

关键信号：

HTTP请求的请求体/头中包含
```
process.env
```
、API密钥或令牌
接收环境变量数据的硬编码URL
Base64编码的目标URL
基于DNS的泄露模式

🔴 Phase 2: Backdoor Detection

🔴 阶段2：后门检测

MANDATORY: Read

references/backdoor-detection.md

for grep patterns.

Search for hidden network listeners and remote access.

Key signals:

```
net.createServer
```
/
```
http.createServer
```
on unusual ports
```
child_process
```
spawning shells with network arguments
Hidden Express/Koa/Fastify routes not documented in API specs
WebSocket connections to hardcoded external hosts

必须：阅读

references/backdoor-detection.md

获取grep模式。

搜索隐藏的网络监听器和远程访问入口。

关键信号：

在非常规端口上使用
```
net.createServer
```
/
```
http.createServer
```
```
child_process
```
生成带有网络参数的shell
未在API文档中记录的隐藏Express/Koa/Fastify路由
连接到硬编码外部主机的WebSocket

🔴 Phase 3: Malicious Code Injection

🔴 阶段3：恶意代码注入检测

MANDATORY: Read

references/malicious-code-patterns.md

for grep patterns.

Search for dynamic code execution and obfuscation.

Key signals:

eval()

new Function()

vm.runInNewContext()

Strings assembled character-by-character then executed
```
Buffer.from(..., 'base64')
```
followed by
```
eval
```
or
```
exec
```
```
postinstall
```
/
```
preinstall
```
scripts running network requests or shell commands

必须：阅读

references/malicious-code-patterns.md

获取grep模式。

搜索动态代码执行和混淆代码。

关键信号：

eval()

、

new Function()

、

vm.runInNewContext()

逐字符拼接后执行的字符串
```
Buffer.from(..., 'base64')
```
后跟
```
eval
```
或
```
exec
```
执行网络请求或shell命令的
```
postinstall
```
/
```
preinstall
```
脚本

🟡 Phase 4: Dependency Chain Risks

🟡 阶段4：依赖链风险分析

MANDATORY: Read

references/dependency-risks.md

for analysis patterns.

Analyze dependencies for supply-chain attack indicators.

Key signals:

Typosquatting package names (e.g.,
```
lodahs
```
instead of
```
lodash
```
)
Packages with
```
postinstall
```
hooks that download/execute remote code
Unpinned versions (
```
*
```
,
```
latest
```
) or very recent publications

Fallbacks for different package managers:

Tool	Primary Command	Fallback
npm	`npm audit --json`	Parse `package-lock.json` manually
yarn	`yarn audit --json`	Parse `yarn.lock` manually
pnpm	`pnpm audit --json`	Parse `pnpm-lock.yaml` manually
None	—	Read `package.json` dependencies and grep `node_modules/*/package.json` for `postinstall`

必须：阅读

references/dependency-risks.md

获取分析模式。

分析依赖项是否存在供应链攻击迹象。

关键信号：

仿冒包名（例如
```
lodahs
```
而非
```
lodash
```
）
包含下载/执行远程代码的
```
postinstall
```
钩子的包
未固定的版本（
```
*
```
、
```
latest
```
）或非常新发布的包

不同包管理器的备选方案：

工具	主要命令	备选方案
npm	`npm audit --json`	手动解析 `package-lock.json`
yarn	`yarn audit --json`	手动解析 `yarn.lock`
pnpm	`pnpm audit --json`	手动解析 `pnpm-lock.yaml`
无	—	读取 `package.json` 依赖项并grep `node_modules/*/package.json` 中的 `postinstall`

🟡 Phase 5: Sensitive File Access

🟡 阶段5：敏感文件访问检测

MANDATORY: Read

references/filesystem-risks.md

for grep patterns.

Search for code reading sensitive local files.

Key signals:

Reading
```
~/.ssh/
```
,
```
~/.aws/
```
,
```
~/.gnupg/
```
Accessing browser profile directories or cookie stores
Reading
```
.env
```
files outside the project root
OS keychain or credential manager access

必须：阅读

references/filesystem-risks.md

获取grep模式。

搜索读取本地敏感文件的代码。

关键信号：

读取
```
~/.ssh/
```
、
```
~/.aws/
```
、
```
~/.gnupg/
```
访问浏览器配置文件目录或Cookie存储
读取项目根目录外的
```
.env
```
文件
访问OS钥匙串或凭证管理器

Step 4: Generate Security Report

步骤4：生成安全报告

Produce a structured report:

markdown

undefined

生成结构化报告：

markdown

undefined

Security Scan Report — [Project Name]

安全扫描报告 — [项目名称]

Summary

摘要

Scan Date: [date]
Files Scanned: [count]
Critical Findings: [count]
Medium Findings: [count]

扫描日期：[日期]
扫描文件数：[数量]
关键发现：[数量]
中等发现：[数量]

🔴 Critical Findings

🔴 关键发现

[Finding Title]

[发现标题]

Category: [Data Exfiltration | Backdoor | Malicious Code]
File:
```
path/to/file.ts:line
```
Code: [offending code snippet]
Risk: [what could happen]
Recommendation: [how to fix]

类别：[数据泄露 | 后门 | 恶意代码]
文件：
```
path/to/file.ts:line
```
代码：[问题代码片段]
风险：[可能造成的影响]
建议：[修复方案]

🟡 Medium Findings

🟡 中等发现

[Finding Title]

[发现标题]

Category: [Dependency Risk | Filesystem Risk]
File:
```
path/to/file.ts:line
```
Risk: [description]
Recommendation: [action]

类别：[依赖风险 | 文件系统风险]
文件：
```
path/to/file.ts:line
```
风险：[描述]
建议：[操作方案]

✅ Passed Checks

✅ 通过检查项

[List categories that passed with no findings]

undefined

[列出未发现问题的类别]

undefined

Anti-Patterns (Common False Positives)

反模式（常见误报）

NEVER flag these without checking context first. Doing so floods the report with noise and erodes trust.

Legitimate
eval()
— Template engines (EJS, Handlebars), REPL tools, and test frameworks may use
```
eval
```
. Flag ONLY when it processes external/user input or fetched data.
Build scripts with
child_process
— Common in build tools (webpack plugins, gulp tasks). Only flag when combined with network operations or env var exfiltration.
HTTP requests in test files — Mock servers and test utilities commonly use
```
net.createServer
```
. Deprioritize
```
**/*.test.*
```
,
```
**/*.spec.*
```
, and
```
__tests__/
```
directories.
Env var access in config loaders — Libraries like
```
dotenv
```
,
```
convict
```
,
```
config
```
legitimately read
```
.env
```
files. Flag only when env values are sent to non-project endpoints.
Minified/bundled vendor files —
```
dist/
```
,
```
vendor/
```
,
```
*.min.js
```
,
```
*.bundle.js
```
contain obfuscated code by design. Skip UNLESS recently modified (check
```
git log
```
timestamp) or the project doesn't use a bundler.
Crypto libraries — Legitimate use of
```
crypto
```
,
```
bcrypt
```
,
```
argon2
```
,
```
jose
```
, Base64 encoding for JWT. Flag ONLY when combined with network calls to non-standard endpoints.
Code generators and AST tools — Babel plugins, TypeScript compiler extensions, ESLint custom rules, and Prettier plugins legitimately use
```
eval
```
-like constructs and dynamic
```
require()
```
. Check the package purpose.
CI/CD and dev tooling
postinstall
—
```
husky
```
,
```
patch-package
```
,
```
electron-builder
```
,
```
node-gyp
```
use legitimate
```
postinstall
```
hooks. Prioritize scanning
```
dependencies
```
over
```
devDependencies
```
. Flag devDependencies only if they download from suspicious URLs.
Monorepo workspace scripts — Tools like Turborepo, Lerna, and Nx run
```
child_process.exec
```
across workspace packages. This is expected infrastructure, not a backdoor.
SSH libraries in deployment tools — Packages like
```
node-ssh
```
,
```
ssh2
```
are legitimate in deployment/provisioning tools. Flag only in libraries/packages that shouldn't need remote access.

若无上下文验证，切勿标记这些情况。否则会导致报告充斥无效信息，降低可信度。

合法的
eval()
使用 —— 模板引擎（EJS、Handlebars）、REPL工具和测试框架可能会使用
```
eval()
```
。仅当它处理外部/用户输入或获取的数据时才标记。
带有
child_process
的构建脚本 —— 构建工具（webpack插件、gulp任务）中很常见。仅当结合网络操作或环境变量泄露时才标记。
测试文件中的HTTP请求 —— 模拟服务器和测试工具通常会使用
```
net.createServer
```
。降低
```
**/*.test.*
```
、
```
**/*.spec.*
```
和
```
__tests__/
```
目录的优先级。
配置加载器中的环境变量访问 ——
```
dotenv
```
、
```
convict
```
、
```
config
```
等库会合法读取
```
.env
```
文件。仅当环境变量值被发送到非项目端点时才标记。
压缩/打包的第三方文件 ——
```
dist/
```
、
```
vendor/
```
、
```
*.min.js
```
、
```
*.bundle.js
```
中的代码本质上是混淆的。除非最近被修改（检查
```
git log
```
时间戳）或项目未使用打包工具，否则跳过扫描。
加密库 —— 合法使用
```
crypto
```
、
```
bcrypt
```
、
```
argon2
```
、
```
jose
```
以及用于JWT的Base64编码。仅当结合对非标准端点的网络调用时才标记。
代码生成器和AST工具 —— Babel插件、TypeScript编译器扩展、ESLint自定义规则和Prettier插件会合法使用类似
```
eval
```
的结构和动态
```
require()
```
。需检查包的用途。
CI/CD和开发工具的
postinstall
——
```
husky
```
、
```
patch-package
```
、
```
electron-builder
```
、
```
node-gyp
```
会使用合法的
```
postinstall
```
钩子。优先扫描
```
dependencies
```
而非
```
devDependencies
```
。仅当从可疑URL下载时才标记devDependencies。
单体仓库工作区脚本 —— Turborepo、Lerna和Nx等工具会跨工作区包执行
```
child_process.exec
```
。这是预期的基础设施行为，而非后门。
部署工具中的SSH库 ——
```
node-ssh
```
、
```
ssh2
```
等包在部署/配置工具中是合法的。仅在不需要远程访问的库/包中才标记。

The Context Rule

上下文规则

Before escalating any finding to 🔴 Critical, verify: "Does this code run in production, AND does it touch sensitive data, AND does it communicate externally?" All three must be true for a genuine critical finding.

在将任何发现升级为🔴关键级别前，请验证：“此代码是否在生产环境运行，是否接触敏感数据，是否与外部通信？” 三个条件全部满足才是真正的关键发现。