反馈类型
误报（PreToolUse 拦截 + 深扫 findings）与漏检对照，附改进建议
环境
- mimosa 1.0.3（官方市场安装），macOS arm64
- 场景：企业办公自动化仓库（Python 胶水脚本：调用企业内部 API 网关、浏览器自动化、批量数据处理），非公网 Web 服务
一、PreToolUse 实时拦截误报（4 例，均为正常业务代码被阻断写入）
1. 弱加密（MD5）→ 误报
被拦代码：hashlib.md5(...) 计算第三方网关的请求签名。该网关（企业学习平台）的签名协议强制规定 MD5（sign = MD5("path"+路径+"timestamp"+毫秒+…+SIGNKEY)），与前端 JS 完全一致。改成 SHA-256 会导致所有请求 401。这类"协议复刻"场景中弱算法是对方接口的硬性要求，不是本方的安全选择。
2. SSRF → 误报
被拦代码：urllib.request 请求写死的常量域名（gateway.<公司域名>.com，白名单唯一主机，全脚本无任何用户可控 URL 输入）。规则将"URL 含变量拼接"特征套在了协议复刻脚本上。
3. 路径穿越 → 误报
被拦代码：open("lms_state.json")——脚本同目录、硬编码文件名，无任何 .. 或外部输入。
4. 不安全随机数 → 误报
被拦代码：random.uniform(8, 12) 生成翻页间隔，用于模拟真人浏览节奏。非安全用途。
二、深扫 findings 误报（9 条 HIGH 中的典型）
- 4 条标在 vendored 依赖上：
pylibs/typing_extensions.py 的 eval（Python 官方 backport 库）、pylibs/pypdf、pylibs/et_xmlfile 的路径穿越——这些是 pip 落地的第三方库源码，用户不会修改，建议默认排除或单独降级为 info。
- 5 条 SSRF 全部为写死的官方 SaaS 域名（如请求
open.feishu.cn 获取 token 的脚本）。
三、漏检对照（更值得关注的真空地带）
同一份被标 SSRF 的脚本（get_user_token.py），第 2 行明文硬编码了飞书 APP_SECRET（此处已脱敏，形如 32 位混合串），静态扫描未检出任何"硬编码凭据"。对该仓库做定向验证：同一凭据硬编码在 120 个文件中，专用的 gitleaks/trufflehog 类工具全部命中，mimosa 命中 0。
对办公自动化类仓库，硬编码凭据（token/secret/密钥）才是真实的第一风险，而当前规则集恰恰没有覆盖这一类。
四、建议
- 为"协议复刻"场景提供豁免通道：例如检测到常量声明的固定域名白名单、或允许项目级
.mimosa/allowlist 配置（当前 finding-ledger 只记账不豁免，172 条历史误报积压导致 git 门禁持续拦截正常提交，只能靠人工绕行）
- vendored 依赖目录（
pylibs/、site-packages、node_modules 模式）默认排除或降级
- 新增硬编码凭据检测规则（熵值+常见凭据格式：
sk-、token-、SECRET=、app_secret 参数等）——这类检测确定性高、误报低，是比现有规则更值的方向
- 随机数规则限定到安全上下文（
secrets 场景），random 用于节奏/测试模拟时放行
五、复现
以上拦截均来自真实会话（2026-09-21~23），案例 1-4 的绕行成本：同一脚本被迫改写两版（chr 拼接算法名、heredoc 直跑），总耗时约 20 分钟纯对抗。深扫报告存于 ~/.mimosa/security-scans/，可按 scan id 复核。
反馈类型
误报（PreToolUse 拦截 + 深扫 findings）与漏检对照，附改进建议
环境
一、PreToolUse 实时拦截误报（4 例，均为正常业务代码被阻断写入）
1. 弱加密（MD5）→ 误报
被拦代码：
hashlib.md5(...)计算第三方网关的请求签名。该网关（企业学习平台）的签名协议强制规定 MD5（sign = MD5("path"+路径+"timestamp"+毫秒+…+SIGNKEY)），与前端 JS 完全一致。改成 SHA-256 会导致所有请求 401。这类"协议复刻"场景中弱算法是对方接口的硬性要求，不是本方的安全选择。2. SSRF → 误报
被拦代码：
urllib.request请求写死的常量域名（gateway.<公司域名>.com，白名单唯一主机，全脚本无任何用户可控 URL 输入）。规则将"URL 含变量拼接"特征套在了协议复刻脚本上。3. 路径穿越 → 误报
被拦代码：
open("lms_state.json")——脚本同目录、硬编码文件名，无任何..或外部输入。4. 不安全随机数 → 误报
被拦代码：
random.uniform(8, 12)生成翻页间隔，用于模拟真人浏览节奏。非安全用途。二、深扫 findings 误报（9 条 HIGH 中的典型）
pylibs/typing_extensions.py的 eval（Python 官方 backport 库）、pylibs/pypdf、pylibs/et_xmlfile的路径穿越——这些是 pip 落地的第三方库源码，用户不会修改，建议默认排除或单独降级为 info。open.feishu.cn获取 token 的脚本）。三、漏检对照（更值得关注的真空地带）
同一份被标 SSRF 的脚本（
get_user_token.py），第 2 行明文硬编码了飞书 APP_SECRET（此处已脱敏，形如 32 位混合串），静态扫描未检出任何"硬编码凭据"。对该仓库做定向验证：同一凭据硬编码在 120 个文件中，专用的 gitleaks/trufflehog 类工具全部命中，mimosa 命中 0。对办公自动化类仓库，硬编码凭据（token/secret/密钥）才是真实的第一风险，而当前规则集恰恰没有覆盖这一类。
四、建议
.mimosa/allowlist配置（当前 finding-ledger 只记账不豁免，172 条历史误报积压导致 git 门禁持续拦截正常提交，只能靠人工绕行）pylibs/、site-packages、node_modules模式）默认排除或降级sk-、token-、SECRET=、app_secret 参数等）——这类检测确定性高、误报低，是比现有规则更值的方向secrets场景），random用于节奏/测试模拟时放行五、复现
以上拦截均来自真实会话（2026-09-21~23），案例 1-4 的绕行成本：同一脚本被迫改写两版（chr 拼接算法名、heredoc 直跑），总耗时约 20 分钟纯对抗。深扫报告存于
~/.mimosa/security-scans/，可按 scan id 复核。