并发审计器 - 代码并发安全检测工具 | 异步竞争、死锁、资源争用审计

ln-628-concurrency-auditor by levnikolaevich/claude-code-skills

170 周安装量

262 GitHub Stars

安装命令

npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-628-concurrency-auditor

🇨🇳中文介绍

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

并发审计器 (L3 Worker)

专门用于审计并发、异步模式和跨进程资源访问的工作器。

目的与范围

ln-620 协调器管道中的工作器
审计并发（类别 11：高优先级）
7 项检查：异步竞争、线程安全、TOCTOU、死锁、阻塞 I/O、资源争用、跨进程竞争
双层检测：grep 查找候选，代理根据上下文推理
计算合规分数 (X/10)

输入（来自协调器）

必读： 加载 shared/references/audit_worker_core_contract.md。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

1. 异步/事件循环竞争 (CWE-362)

内容： 在单线程异步代码中，跨 await/yield 边界导致共享状态损坏。

第 1 层 — Grep 模式：

语言	模式	Grep
JS/TS	跨 await 的读-改-写	`\w+\s[+\-/]?=\s.await` (例如，`result += await something`)
JS/TS	检查-然后-初始化竞争	`if\s\(!?\w+\)` 后跟同一代码块中的 `\w+\s=\s*await`
Python	跨 await 的读-改-写	`\w+\s[+\-/]?=\s*await` 在 `async def` 内部
Python	异步中的共享模块级状态	模块级 `\w+\s*=` + 在 `async def` 内部修改
All	无锁的共享缓存	`.set(

第 2 层 — 关键问题：

变量是共享的（模块/全局作用域）还是局部的？
两个异步任务能否在此 await 点交错执行？
是否有锁/互斥锁/信号量保护此访问？

严重性： 严重（支付/认证） | 高（面向用户） | 中（后台）

安全模式排除： 局部变量、const 声明、单次使用的 await（不可能交错）。

工作量： 中

2. 线程/Goroutine 安全 (CWE-366)

内容： 多个线程/goroutine 在没有同步的情况下访问共享可变状态。

第 1 层 — Grep 模式：

语言	模式	Grep
Go	无互斥锁的 Map 访问	结构体中 `map\[.\].=` 且没有 `sync.Mutex` 或 `sync.RWMutex`
Go	被 goroutine 捕获的变量	`go func` + 修改来自外部作用域的变量
Python	在线程中修改全局变量	同一文件中 `global\s+\w+` 在函数内 + `threading.Thread`
Java	线程间共享的 HashMap	同一类中 `HashMap` + `Thread
Rust	多线程上下文中的 Rc	同一文件中 `Rc<RefCell` + `thread::spawn
Node.js	Worker Threads 共享状态	`workerData

第 2 层 — 关键问题：

这个结构体/对象是否真的在线程间共享？（单线程代码 → 误报）
互斥锁/锁是否在嵌入的结构体或导入的模块中？（grep 可能漏掉）
go func 是按值捕获（安全）还是按引用捕获（不安全）？

严重性： 严重（支付/认证） | 高（可能导致数据损坏） | 中（内部）

安全模式排除： Go map 在 goroutine 启动前的 init() 或 main() 中。Rust Arc<Mutex<T>>（已安全）。Java Collections.synchronizedMap()。

工作量： 中

3. TOCTOU — 检查时间与使用时间 (CWE-367)

内容： 检查资源状态，然后使用，但状态可能在检查和使用之间发生变化。

第 1 层 — Grep 模式：

语言	检查	使用	Grep
Python	`os.path.exists()`	`open()`	`os\.path\.exists\(` 靠近同一变量的 `open\(`
Python	`os.access()`	`os.open()`	`os\.access\(` 靠近 `os.open(
Node.js	`fs.existsSync()`	`fs.readFileSync()`	`existsSync\(` 靠近 `readFileSync(
Node.js	`fs.accessSync()`	`fs.openSync()`	`accessSync\(` 靠近 `openSync\(`
Go	`os.Stat()`	`os.Open()`	`os\.Stat\(` 靠近 `os.Open(
Java	`.exists()`	`new FileInputStream`	`\.exists\(\)` 靠近 `new File

第 2 层 — 关键问题：

检查是用于控制流（易受攻击）还是仅用于日志记录（安全）？
检查-然后-使用序列周围是否有锁/重试机制？
文件是否在应用程序控制的临时目录中（风险较低）？
攻击者是否可以替换文件（符号链接攻击）？

严重性： 严重（安全敏感：权限、认证令牌、配置） | 高（面向用户的文件操作） | 中（内部/后台）

安全模式排除： 检查在带有重试的 try/catch 内部。仅用于日志记录/指标。检查 + 使用包装在文件锁中。

工作量： 小-中（用直接使用 + 错误处理替换检查-然后-使用）

4. 死锁可能性 (CWE-833)

内容： 锁获取顺序不一致，或在阻塞操作期间持有锁。

第 1 层 — Grep 模式：

语言	模式	Grep
Python	嵌套锁	`with\s+\w+_lock:` (多行：两个不同的锁嵌套)
Python	循环中的锁	`for.*:` 且循环体内有 `\.acquire\(\)`
Python	锁 + 外部调用	`\.acquire\(\)` 后跟 `await
Go	缺少 defer unlock	`\.Lock\(\)` 下一行没有 `defer.*\.Unlock\(\)`
Go	嵌套锁	同一函数中两次 `\.Lock\(\)` 调用，中间没有 `\.Unlock\(\)`
Java	嵌套 synchronized	`synchronized\s*\(` (多行：嵌套块使用不同的监视器)
JS	异步互斥锁嵌套	`await\s+\w+\.acquire\(\)` (同一函数中两个不同的互斥锁)

第 2 层 — 关键问题：

这些是同一个锁（可重入 = 正常）还是不同的锁（死锁风险）？
锁的顺序在所有调用点是否一致？
锁内部的外部调用是否有超时设置？

严重性： 严重（支付/认证） | 高（应用冻结风险）

安全模式排除： 可重入锁（同一锁获取两次）。具有显式超时的锁（asyncio.wait_for, tryLock）。

工作量： 大（锁顺序重新设计）

5. 异步上下文中的阻塞 I/O (CWE-400)

内容： 在异步函数或事件循环处理程序中进行同步阻塞调用。

第 1 层 — Grep 模式：

语言	阻塞调用	Grep	替代方案
Python	`async def` 中的 `time.sleep`	`async def` 内部的 `time\.sleep`	`await asyncio.sleep`
Python	`async def` 中的 `requests.*`	`async def` 内部的 `requests.(get	post
Python	`async def` 中的 `open()`	`async def` 内部的 `open\(`	`aiofiles.open`
Node.js	异步中的 `fs.readFileSync`	`fs.readFileSync	fs.writeFileSync
Node.js	异步中的 `execSync`	异步处理程序中的 `execSync	spawnSync`
Node.js	异步中的同步加密	`crypto.pbkdf2Sync	crypto.scryptSync`

第 2 层 — 关键问题：

这是在热路径（API 处理程序）还是冷路径（启动脚本）中？
阻塞持续时间是否显著（>100ms）？
是否有正当理由（例如，启动时同步读取小配置）？

严重性： 高（阻塞事件循环/异步上下文） | 中（轻微阻塞 <100ms）

安全模式排除： 阻塞调用在 if __name__ == "__main__" 中（启动）。初始化时配置加载中的 readFileSync。小输入的同步加密。

工作量： 小-中（替换为异步替代方案）

6. 资源争用 (CWE-362)

内容： 多个并发访问者竞争同一资源而没有协调。

第 1 层 — Grep 模式：

模式	风险	Grep
无同步的共享内存	数据损坏	`SharedArrayBuffer
无协调的 IPC	消息顺序	并发循环中的 `process.send
并发文件追加	交错写入	并行任务对同一路径的多个 `appendFile

第 2 层 — 关键问题：

多个写入者是否实际并发？（顺序 = 安全）
是否有操作系统级别的原子性保证？（例如，小写操作的 O_APPEND）
顺序对正确性是否重要？

严重性： 高（数据损坏） | 中（顺序问题）

安全模式排除： 单写入者模式。操作系统保证的原子操作（小管道写入、O_APPEND）。具有顺序保证的消息队列。

工作量： 中

7. 跨进程与不可见副作用 (CWE-362, CWE-421)

内容： 多个进程或进程+操作系统访问同一独占资源，包括对共享操作系统资源具有非明显副作用的操作。

第 1 层 — Grep 入口点：

模式	风险	Grep
剪贴板双重访问	同一流程中的 OSC 52 + 原生剪贴板	同一文件中 `osc52
子进程 + 共享文件	父进程和子进程写入同一文件	`spawn
操作系统独占资源	Win32 剪贴板、串口、命名管道	`OpenClipboard
终端转义序列	stdout 触发终端操作系统访问	`\x1b\]
外部剪贴板工具	通过生成进程的剪贴板	`pbcopy

第 2 层 — 此项检查比其他任何检查都更依赖推理：

构建资源清单：

资源	独占？	访问者 1	访问者 2	存在同步？

追踪时间线：

t=0ms operation_A() -> 访问 resource_X t=?ms side_effect -> 外部进程访问 resource_X t=?ms operation_B() -> 再次访问 resource_X -> 冲突？
关键问题：

 * 另一个进程（终端、操作系统、子进程）能否同时访问此资源？

 * 此操作是否对共享操作系统资源具有不可见的副作用？
 * 如果外部进程比预期慢/快会发生什么？
 * 如果用户快速触发此操作两次会发生什么？

严重性： 严重（两个访问者访问独占操作系统资源而无同步） | 高（子进程 + 共享文件无锁） | 高（通过推理检测到不可见副作用）

安全模式排除： 单访问者。存在重试/退避模式。操作通过显式延迟/await 排序。

工作量： 中-大（可能需要移除冗余访问路径）

必读： 加载 shared/references/audit_worker_core_contract.md 和 shared/references/audit_scoring.md。

必读： 加载 shared/references/audit_worker_core_contract.md 和 shared/templates/audit_worker_report_template.md。

将报告写入 {output_dir}/628-concurrency.md，其中 category: "Concurrency" 和检查项：async_races, thread_safety, toctou, deadlock_potential, blocking_io, resource_contention, cross_process_races。

返回摘要给协调器：

Report written: docs/project/.audit/ln-620/{YYYY-MM-DD}/628-concurrency.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

必读： 加载 shared/references/audit_worker_core_contract.md。

不要自动修复： 仅报告 — 并发修复需要仔细的人工审查
双层检测： 始终在第 1 层 grep 后应用第 2 层推理。切勿在没有上下文分析的情况下报告原始 grep 匹配项
语言感知检测： 根据检查使用特定于语言的模式
统一的严重升级： 支付/认证/金融代码中的任何发现 = 严重
工作量现实性： 小 = <1小时，中 = 1-4小时，大 = >4小时
排除项： 跳过测试文件，跳过单线程 CLI 工具，跳过生成的代码

必读： 加载 shared/references/audit_worker_core_contract.md。

已解析 contextStore（语言、并发模型、output_dir）
所有 7 项检查均已完成双层检测：
- 异步竞争、线程安全、TOCTOU、死锁可能性、阻塞 I/O、资源争用、跨进程竞争
第 2 层推理已应用于每个候选（已确认 / 误报 / 需要上下文）
已收集发现，包括严重性、位置、工作量、建议
已根据 shared/references/audit_scoring.md 计算分数
报告已写入 {output_dir}/628-concurrency.md（原子性单次写入调用）
摘要已返回给协调器

双层检测方法： shared/references/two_layer_detection.md
审计输出模式： shared/references/audit_output_schema.md

版本： 4.0.0 最后更新： 2026-03-04

🇺🇸English

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

Concurrency Auditor (L3 Worker)

Specialized worker auditing concurrency, async patterns, and cross-process resource access.

Purpose & Scope

Worker in ln-620 coordinator pipeline
Audit concurrency (Category 11: High Priority)
7 checks: async races, thread safety, TOCTOU, deadlocks, blocking I/O, resource contention, cross-process races
Two-layer detection: grep finds candidates, agent reasons about context
Calculate compliance score (X/10)

Inputs (from Coordinator)

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Receives contextStore with: tech_stack, best_practices, codebase_root, output_dir.

Workflow

MANDATORY READ: Load shared/references/two_layer_detection.md for detection methodology.

Parse context — extract tech_stack, language, output_dir from contextStore
Per check (1-7):
- Layer 1: Grep/Glob scan to find candidates
- Layer 2: Read 20-50 lines around each candidate. Apply check-specific critical questions. Classify: confirmed / false positive / needs-context
Collect confirmed findings with severity, location, effort, recommendation
Calculate score per shared/references/audit_scoring.md
Write Report — build in memory, write to {output_dir}/628-concurrency.md (atomic single Write)
Return Summary to coordinator

Audit Rules

Unified severity escalation: For ALL checks — if finding affects payment/auth/financial code → escalate to CRITICAL regardless of other factors.

1. Async/Event-Loop Races (CWE-362)

What: Shared state corrupted across await/yield boundaries in single-threaded async code.

Layer 1 — Grep patterns:

Language	Pattern	Grep
JS/TS	Read-modify-write across await	`\w+\s[+\-/]?=\s.await` (e.g., `result += await something`)
JS/TS	Check-then-initialize race	`if\s\(!?\w+\)` followed by `\w+\s=\s*await` in same block
Python	Read-modify-write across await	`\w+\s[+\-/]?=\s*await` inside `async def`
Python

Layer 2 — Critical questions:

Is the variable shared (module/global scope) or local?
Can two async tasks interleave at this await point?
Is there a lock/mutex/semaphore guarding the access?

Severity: CRITICAL (payment/auth) | HIGH (user-facing) | MEDIUM (background)

Safe pattern exclusions: Local variables, const declarations, single-use await (no interleaving possible).

Effort: M

2. Thread/Goroutine Safety (CWE-366)

What: Shared mutable state accessed from multiple threads/goroutines without synchronization.

Layer 1 — Grep patterns:

Language	Pattern	Grep
Go	Map access without mutex	`map\[.\].=` in struct without `sync.Mutex` or `sync.RWMutex`
Go	Variable captured by goroutine	`go func` + variable from outer scope modified
Python	Global modified in threads	`global\s+\w+` in function + `threading.Thread` in same file
Java	HashMap shared between threads

Layer 2 — Critical questions:

Is this struct/object actually shared between threads? (single-threaded code → FP)
Is mutex/lock in embedded struct or imported module? (grep may miss it)
Is go func capturing by value (safe) or by reference (unsafe)?

Severity: CRITICAL (payment/auth) | HIGH (data corruption possible) | MEDIUM (internal)

Safe pattern exclusions: Go map in init() or main() before goroutines start. Rust Arc<Mutex<T>> (already safe). Java Collections.synchronizedMap().

Effort: M

3. TOCTOU — Time-of-Check Time-of-Use (CWE-367)

What: Resource state checked, then used, but state can change between check and use.

Layer 1 — Grep patterns:

Language	Check	Use	Grep
Python	`os.path.exists()`	`open()`	`os\.path\.exists\(` near `open\(` on same variable
Python	`os.access()`	`os.open()`	`os\.access\(` near `os.open(

Layer 2 — Critical questions:

Is the check used for control flow (vulnerable) or just logging (safe)?
Is there a lock/retry around the check-then-use sequence?
Is the file in a temp directory controlled by the application (lower risk)?
Could an attacker substitute the file (symlink attack)?

Severity: CRITICAL (security-sensitive: permissions, auth tokens, configs) | HIGH (user-facing file ops) | MEDIUM (internal/background)

Safe pattern exclusions: Check inside try/catch with retry. Check for logging/metrics only. Check + use wrapped in file lock.

Effort: S-M (replace check-then-use with direct use + error handling)

4. Deadlock Potential (CWE-833)

What: Lock acquisition in inconsistent order, or lock held during blocking operation.

Layer 1 — Grep patterns:

Language	Pattern	Grep
Python	Nested locks	`with\s+\w+_lock:` (multiline: two different locks nested)
Python	Lock in loop	`for.*:` with `\.acquire\(\)` inside loop body
Python	Lock + external call	`\.acquire\(\)` followed by `await
Go	Missing defer unlock	`\.Lock\(\)` without `defer.*\.Unlock\(\)` on next line

Layer 2 — Critical questions:

Are these the same lock (reentrant = OK) or different locks (deadlock risk)?
Is the lock ordering consistent across all call sites?
Does the external call inside lock have a timeout?

Severity: CRITICAL (payment/auth) | HIGH (app freeze risk)

Safe pattern exclusions: Reentrant locks (same lock acquired twice). Locks with explicit timeout (asyncio.wait_for, tryLock).

Effort: L (lock ordering redesign)

5. Blocking I/O in Async Context (CWE-400)

What: Synchronous blocking calls inside async functions or event loop handlers.

Layer 1 — Grep patterns:

Language	Blocking Call	Grep	Replacement
Python	`time.sleep` in async def	`time\.sleep` inside `async def`	`await asyncio.sleep`
Python	`requests.*` in async def	`requests.(get	post
Python	`open()` in async def	inside

Layer 2 — Critical questions:

Is this in a hot path (API handler) or cold path (startup script)?
Is the blocking duration significant (>100ms)?
Is there a legitimate reason (e.g., sync read of small config at startup)?

Severity: HIGH (blocks event loop/async context) | MEDIUM (minor blocking <100ms)

Safe pattern exclusions: Blocking call in if __name__ == "__main__" (startup). readFileSync in config loading at init time. Sync crypto for small inputs.

Effort: S-M (replace with async alternative)

6. Resource Contention (CWE-362)

What: Multiple concurrent accessors compete for same resource without coordination.

Layer 1 — Grep patterns:

Pattern	Risk	Grep
Shared memory without sync	Data corruption	`SharedArrayBuffer
IPC without coordination	Message ordering	`process.send
Concurrent file append	Interleaved writes	Multiple `appendFile

Layer 2 — Critical questions:

Are multiple writers actually concurrent? (Sequential = safe)
Is there OS-level atomicity guarantee? (e.g., O_APPEND for small writes)
Is ordering important for correctness?

Severity: HIGH (data corruption) | MEDIUM (ordering issues)

Safe pattern exclusions: Single writer pattern. OS-guaranteed atomic operations (small pipe writes, O_APPEND). Message queues with ordering guarantees.

Effort: M

7. Cross-Process & Invisible Side Effects (CWE-362, CWE-421)

What: Multiple processes or process+OS accessing same exclusive resource, including operations with non-obvious side effects on shared OS resources.

Layer 1 — Grep entry points:

Pattern	Risk	Grep
Clipboard dual access	OSC 52 + native clipboard in same flow	`osc52
Subprocess + shared file	Parent and child write same file	`spawn
OS exclusive resource	Win32 clipboard, serial port, named pipe	`OpenClipboard
Terminal escape sequences	stdout triggers terminal OS access	`\x1b\]
External clipboard tools	Clipboard via spawned process	`pbcopy

Layer 2 — This check relies on reasoning more than any other:

Build Resource Inventory:

Resource	Exclusive?	Accessor 1	Accessor 2	Sync present?

Trace Timeline:

t=0ms  operation_A() -> resource_X accessed
t=?ms  side_effect   -> resource_X accessed by external process
t=?ms  operation_B() -> resource_X accessed again -> CONFLICT?

Critical Questions:
- Can another process (terminal, OS, child) access this resource simultaneously?
- Does this operation have invisible side effects on shared OS resources?
- What happens if the external process is slower/faster than expected?
- What happens if user triggers this action twice rapidly?

Severity: CRITICAL (two accessors to exclusive OS resource without sync) | HIGH (subprocess + shared file without lock) | HIGH (invisible side effect detected via reasoning)

Safe pattern exclusions: Single accessor. Retry/backoff pattern present. Operations sequenced with explicit delay/await.

Effort: M-L (may require removing redundant access path)

Scoring Algorithm

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/references/audit_scoring.md.

Output Format

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/templates/audit_worker_report_template.md.

Write report to {output_dir}/628-concurrency.md with category: "Concurrency" and checks: async_races, thread_safety, toctou, deadlock_potential, blocking_io, resource_contention, cross_process_races.

Return summary to coordinator:

Report written: docs/project/.audit/ln-620/{YYYY-MM-DD}/628-concurrency.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

Critical Rules

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Do not auto-fix: Report only — concurrency fixes require careful human review
Two-layer detection: Always apply Layer 2 reasoning after Layer 1 grep. Never report raw grep matches without context analysis
Language-aware detection: Use language-specific patterns per check
Unified CRITICAL escalation: Any finding in payment/auth/financial code = CRITICAL
Effort realism: S = <1h, M = 1-4h, L = >4h
Exclusions: Skip test files, skip single-threaded CLI tools, skip generated code

Definition of Done

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

contextStore parsed (language, concurrency model, output_dir)
All 7 checks completed with two-layer detection:
- async races, thread safety, TOCTOU, deadlock potential, blocking I/O, resource contention, cross-process races
Layer 2 reasoning applied to each candidate (confirmed / FP / needs-context)
Findings collected with severity, location, effort, recommendation
Score calculated per shared/references/audit_scoring.md
Report written to {output_dir}/628-concurrency.md (atomic single Write call)
Summary returned to coordinator

Reference Files

Two-layer detection methodology: shared/references/two_layer_detection.md
Audit output schema: shared/references/audit_output_schema.md

Version: 4.0.0 Last Updated: 2026-03-04

Weekly Installs

170

Repository

levnikolaevich/…e-skills

GitHub Stars

262

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

claude-code156

cursor152

opencode152

codex151

gemini-cli151

github-copilot144

OpenClaw 安全 Linux 云部署指南：私有优先、SSH隧道、Podman容器化

33,700 周安装

并发审计器 - 代码并发安全检测工具 | 异步竞争、死锁、资源争用审计

🇨🇳中文介绍

并发审计器 (L3 Worker)

目的与范围

输入（来自协调器）

相关 Skills

工作流程

审计规则

1. 异步/事件循环竞争 (CWE-362)

2. 线程/Goroutine 安全 (CWE-366)

3. TOCTOU — 检查时间与使用时间 (CWE-367)

4. 死锁可能性 (CWE-833)

5. 异步上下文中的阻塞 I/O (CWE-400)

6. 资源争用 (CWE-362)

7. 跨进程与不可见副作用 (CWE-362, CWE-421)

评分算法

输出格式

关键规则

完成定义

参考文件

🇺🇸English

Concurrency Auditor (L3 Worker)

Purpose & Scope

Inputs (from Coordinator)

Workflow

Audit Rules

1. Async/Event-Loop Races (CWE-362)

2. Thread/Goroutine Safety (CWE-366)

3. TOCTOU — Time-of-Check Time-of-Use (CWE-367)

4. Deadlock Potential (CWE-833)

5. Blocking I/O in Async Context (CWE-400)

6. Resource Contention (CWE-362)

7. Cross-Process & Invisible Side Effects (CWE-362, CWE-421)

Scoring Algorithm

Output Format

Critical Rules

Definition of Done

Reference Files

最新 Skills