5. 安全性与生产环境适用性

5.1 安全架构总览

5.1.1 安全设计原则

RTK 遵循以下安全设计原则：

1. 最小权限：单二进制，零依赖，无网络能力
2. 透明执行：所有命令重写对用户可见
3. 退出码保留：不掩盖底层命令的失败状态
4. 本地存储：所有数据存储在本地，无远程传输
5. 防御性编程：使用 anyhow 进行错误传播，避免 unwrap() panic

5.1.2 安全边界

┌────────────────────────────────────────────────────────────────────────┐
│                         RTK 安全边界                                   │
└────────────────────────────────────────────────────────────────────────┘

用户输入 → RTK 解析 → 命令执行 → 输出过滤 → 用户/LLM
              ↓           ↓           ↓
          参数验证    退出码检查    Tee 存储
              ↓           ↓           ↓
          注入防护    错误传播    本地文件

安全边界：
├─ 无网络边界（无远程调用）
├─ 无权限提升（以用户权限运行）
├─ 无持久化（除 tracking.db 和 Tee 文件）
└─ 无隐蔽执行（所有命令在终端可见）

5.2 自动化安全检查

5.2.1 CI/CD 安全流程

每个 PR 触发 security-check.yml 工作流：

# .github/workflows/security-check.yml

name: Security Check

on: [pull_request]

jobs:
  security-audit:
    runs-on: ubuntu-latest
    steps:
      # 1. 依赖审计（检测已知 CVE）
      - name: cargo audit
        run: cargo audit

      # 2. 关键文件告警（检测高风险文件修改）
      - name: Critical Files Alert
        run: |
          if git diff --name-only HEAD^ | grep -E "src/(runner|tracking|rewrite_cmd).rs"; then
            echo "::warning::Critical file modified. Requires 2 reviewer approval."
          fi

      # 3. 危险模式扫描（正则检测）
      - name: Dangerous Pattern Scan
        run: |
          bash scripts/detect-dangerous-patterns.sh <pr_diff>

      # 4. Clippy 安全 lint
      - name: Clippy Security Lints
        run: cargo clippy -- -D warnings -W clippy::security

5.2.2 危险模式检测

detect-dangerous-patterns.sh 检测以下模式：

检测结果处理：

• 发现危险模式 → GitHub Actions Summary 告警
• 发现关键文件修改 → 需要 2 名维护者审批
• 发现 CVE 依赖 → 阻止合并

5.3 关键文件审查

5.3.1 Tier 1 关键文件（需要 2 名维护者审批）

1. src/runner.rs（Shell 命令执行引擎）

风险：主要注入向量，用户输入可能传递到 Shell

安全代码示例：

// ✅ 安全：直接执行，无 Shell 插值
let output = Command::new("grep")
    .arg(&pattern)  // 参数作为独立参数传递
    .arg(&file_path)
    .output()?;

// ❌ 危险：Shell 插值可能导致注入
let cmd = format!("grep '{}' {}", pattern, file_path);
let output = Command::new("sh")
    .arg("-c")
    .arg(&cmd)
    .output()?;

审查要点：

• 是否使用 Command::new("sh")
• 用户输入是否直接传递给 Shell
• 是否有参数验证/白名单过滤

2. src/tracking.rs（SQLite 数据库操作）

风险：隐私/遥测担忧，可能记录敏感命令

数据收集范围：

// tracking.rs 记录的字段
INSERT INTO commands (
    timestamp,       -- 时间戳
    original_cmd,    -- 原始命令（可能包含敏感参数）
    rtk_cmd,         -- RTK 命令
    input_tokens,    -- 输入 token 数
    output_tokens,   -- 输出 token 数
    saved_tokens,    -- 节省 token 数
    savings_pct,     -- 节省百分比
    exec_time_ms     -- 执行时间
)

敏感信息风险：

# 用户可能执行包含敏感信息的命令
$ git commit -m "Fix bug in production DB password: abc123"
$ aws s3 cp secret.txt s3://bucket/  # 访问 S3 敏感文件
$ curl -H "Authorization: Bearer token123" https://api.internal/

# tracking.db 会记录完整命令

缓解措施：

• 90 天自动清理（HISTORY_DAYS 常量）
• 本地存储（~/.local/share/rtk/history.db）
• 用户可随时删除数据库

审查要点：

• 是否记录命令参数（是，按设计）
• 是否有数据外传（否，无网络依赖）
• 是否有清理机制（是，90 天）

3. hooks/rtk-rewrite.sh（Hook 脚本）

风险：在 Claude Code 上下文中执行，拦截所有命令

脚本内容（简化版）：

#!/bin/bash
# rtk-rewrite.sh

# 读取 Claude Code 的命令输入
cmd=$(cat)

# 检测是否是已知命令
case "$cmd" in
    git\ *) echo "rtk $cmd" ;;
    gh\ *)  echo "rtk $cmd" ;;
    cargo\ test*) echo "rtk cargo test" ;;
    # ... 30+ 命令重写规则
    *) echo "$cmd" ;;  # 未知命令原样返回
esac

风险点：

• Hook 脚本可被篡改，重写到恶意命令
• 无完整性校验（无签名验证）
• 依赖 PATH 中的 rtk 二进制

缓解措施：

• 脚本只读权限（chmod 444）
• 定期验证脚本 hash
• 使用绝对路径调用 rtk

审查要点：

• 是否有命令注入
• 是否有权限提升
• 是否有隐蔽执行

5.3.2 Tier 2 关键文件

1. src/pnpm_cmd.rs（包名验证）

风险：恶意包名可能导致注入

安全代码示例：

// ✅ 安全：严格的包名验证
let package_pattern = Regex::new(r"^[a-z0-9][-a-z0-9._]*$").unwrap();
if !package_pattern.is_match(&package_name) {
    anyhow::bail!("Invalid package name: {}", package_name);
}

// ❌ 危险：无验证直接传递
let output = Command::new("pnpm")
    .arg("list")
    .arg(&package_name)  // 可能包含特殊字符
    .output()?;

2. src/container.rs（Docker 操作）

风险：容器操作可能导致权限提升

审查要点：

• 是否执行特权容器命令
• 是否挂载敏感目录
• 是否以 root 身份运行

5.3.3 Tier 3 关键文件

1. Cargo.toml（依赖清单）

风险：供应链攻击（恶意依赖）

审查标准：

• 下载量 > 10,000（或强理由）
• 维护者有验证的 GitHub 档案
• 许可证：MIT 或 Apache-2.0
• 6 个月内有更新
• 无 typosquatting（如 serid vs serde）

当前依赖（零依赖声称）：

[dependencies]
# 实际上 RTK 有少量依赖
anyhow = "1.0"        # 错误处理
clap = { version = "4.0", features = ["derive"] }  # CLI 解析
serde = "1.0"         # 序列化
serde_json = "1.0"    # JSON 解析
regex = "1.0"         # 正则表达式
rusqlite = "0.29"     # SQLite 绑定
colored = "2.0"       # 终端着色
chrono = "0.4"        # 时间处理

注意：README 声称”zero dependencies”指运行时零外部二进制依赖，Rust crates 除外。

5.4 输入验证机制

5.4.1 参数验证

RTK 对所有用户输入进行验证：

// 文件路径验证（防止目录遍历）
use std::path::Path;

pub fn validate_path(path: &str) -> Result<()> {
    let canonical = Path::new(path).canonicalize()?;
    let base = std::env::current_dir()?;
    
    if !canonical.starts_with(&base) {
        anyhow::bail!("Path traversal detected: {}", path);
    }
    Ok(())
}

// 包名验证（防止注入）
pub fn validate_package_name(name: &str) -> Result<()> {
    let pattern = Regex::new(r"^[a-z0-9][-a-z0-9._]*$")?;
    if !pattern.is_match(name) {
        anyhow::bail!("Invalid package name: {}", name);
    }
    Ok(())
}

// 命令标志白名单
pub fn validate_git_flag(flag: &str) -> Result<()> {
    let allowed = ["--oneline", "--graph", "--all", "-n", "--stat"];
    if !allowed.contains(&flag) && !flag.starts_with("--pretty=") {
        anyhow::bail!("Disallowed git flag: {}", flag);
    }
    Ok(())
}

5.4.2 未验证的风险点

根据代码审查，以下场景存在未验证的输入：

1. grep 模式（grep_cmd.rs）

// ❌ 未验证：正则模式直接传递
pub fn run_grep(pattern: &str, path: &str) -> Result<()> {
    let output = Command::new("grep")
        .arg(pattern)  // 无验证
        .arg(path)
        .output()?;
    // ...
}

风险：恶意正则可能导致 ReDoS（正则表达式拒绝服务）

缓解：grep 本身处理正则，RTK 仅传递参数

2. curl 参数（curl_cmd.rs）

// ❌ 未验证：headers 直接传递
pub fn run_curl(args: &[String]) -> Result<()> {
    let output = Command::new("curl")
        .args(args)  // 所有参数直接传递
        .output()?;
    // ...
}

风险：可能注入敏感 headers 或数据

缓解：curl 命令本身已包含这些参数，RTK 仅过滤输出

5.5 数据隐私保护

5.5.1 数据收集清单

RTK 收集以下数据：

5.5.2 数据泄露风险

场景 1：tracking.db 泄露

-- tracking.db 内容示例
SELECT * FROM commands WHERE original_cmd LIKE "%password%";

-- 可能泄露：
-- git commit -m "Update password to abc123"
-- aws secretsmanager get-secret-value --secret-id prod/db/password

影响：敏感命令参数泄露

缓解：

• 数据库文件权限：600（仅用户可读）
• 90 天自动清理
• 用户可手动删除

场景 2：Tee 文件泄露

# Tee 文件包含完整输出
$ cat ~/.local/share/rtk/tee/1707753600_aws_s3_cp.log

# 可能包含：
# - S3 对象内容
# - API 响应（含敏感数据）
# - 错误堆栈（含内部实现）

影响：完整未过滤输出泄露

缓解：

• 文件权限：600
• 轮转机制（max 20 文件）
• mode = “failures”（仅失败时保存）

5.5.3 数据外传防护

防护机制：

// Cargo.toml 中无网络依赖
[dependencies]
# 无 reqwest, hyper, curl 等 HTTP 客户端
# 无 std::net::TcpStream 使用

// 编译时保证：
// - 无法建立网络连接
// - 无法发送数据到远程服务器

验证方法：

# 检查是否有网络相关代码
$ cargo audit  # 检测 CVE
$ cargo deny    # 许可证合规
$ grep -r "reqwest\|std::net" src/  # 应无结果

5.6 生产环境适用性评估

5.6.1 适用场景

5.6.2 生产环境部署清单

如确需在生产环境使用，遵循以下清单：

• 安全审查：由安全团队审查代码和配置
• 禁用 Hook：使用手动 rtk 前缀，而非自动重写
• 配置排除列表：排除敏感命令（curl, ssh, vault 等）
• 启用 Tee：mode = “always”，保留完整审计日志
• 定期清理：设置 cron 任务清理 tracking.db 和 Tee 文件
• 权限控制：限制 rtk 二进制权限（chmod 755）
• 监控告警：监控异常命令模式
• 备份策略：定期备份 tracking.db 用于审计
• 培训计划：培训团队成员了解 RTK 的局限性和风险

5.6.3 推荐配置（生产环境）

# ~/.config/rtk/config.toml

[general]
default_filter_level = "minimal"
enable_tracking = false  # 生产环境禁用追踪

[hooks]
# 排除所有敏感命令
exclude_commands = [
    "curl", "wget", "scp", "ssh", "sftp",
    "vault", "kubectl", "docker",
    "aws", "gcloud", "az",
    "mysql", "psql", "mongo",
    "git push", "git merge",  # 危险 Git 操作
]

[tee]
enabled = true
mode = "always"  # 生产环境始终保留完整输出
max_files = 50   # 增加轮转限制

[tracking]
database_path = "/var/log/rtk/history.db"  # 集中存储
retention_days = 365  # 延长保留时间用于审计

5.7 安全事件响应

5.7.1 漏洞报告流程

根据 SECURITY.md：

1. 报告渠道：

   • 邮件：security@rtk-ai.dev
   • GitHub Private Vulnerability Reporting

2. 响应时间：

   • 确认：48 小时内
   • 评估：7 天内
   • 修复：30 天内
   • 公开披露：90 天（或更早）

3. 披露策略：

   • 负责任的披露（Responsible Disclosure）
   • 修复前不公开细节
   • 关键漏洞可加急处理

5.7.2 已知安全事件

根据公开记录，RTK 无已知 CVE 或安全事件。

历史安全咨询：

• #2026-001：环境变量过滤不足（已缓解，部分修复）
  • 报告者：匿名
  • 状态：部分缓解（依赖用户配置）
  • 修复：添加 -f 前缀过滤标志

5.8 结论与建议

5.8.1 安全性评估

整体安全评分：✅ 高

5.8.2 生产环境建议

推荐使用场景：

• ✅ 个人开发环境
• ✅ 团队内部项目
• ✅ 开源项目开发

谨慎使用场景：

• ⚠️ 企业内网开发（需安全审查）
• ⚠️ 金融/医疗系统（需禁用 Hook + Tee 审计）

不推荐使用场景：

• ❌ 生产环境运维
• ❌ 安全审计
• ❌ 合规敏感环境

5.8.3 风险缓解措施

1. 配置排除列表：排除敏感命令的 Hook 重写
2. 启用 Tee 审计：mode = “always” 或 “failures”
3. 定期清理：tracking.db 和 Tee 文件
4. 安全审查：生产环境部署前由安全团队审查
5. 监控告警：异常命令模式检测
6. 培训计划：团队成员了解 RTK 的局限性和风险

5.8.4 最终评价

RTK 是一个安全的开发效率工具，适合在开发和测试环境中使用。其安全架构设计合理，无已知漏洞，自动化检查完善。但在生产环境使用时，需谨慎评估风险，采取额外的缓解措施。

核心优势：

• ✅ 无网络能力，无法外传数据
• ✅ 本地存储，数据可控
• ✅ 透明执行，所有命令可见
• ✅ 退出码保留，CI/CD 可靠

核心风险：

• ⚠️ tracking.db 可能记录敏感命令参数
• ⚠️ Tee 文件包含完整未过滤输出
• ⚠️ Hook 可能被篡改
• ⚠️ 过度过滤可能遗漏关键信息

建议：在开发和测试环境放心使用，在生产环境谨慎评估后使用。