iamdeborah-Q/ai-appsec-pipeline

# ai-appsec-pipeline AI 驱动的 AppSec pipeline：具备基于 LLM 的分诊（Claude）的 Semgrep SAST、EPSS 优先的漏洞报告、强化的 Golden Docker 镜像，以及用于 CI/CD 和 AI 编程代理的安全门。 # ai-appsec-pipeline 一个 AI 驱动的应用安全 pipeline：具备基于 LLM 分诊的 Semgrep SAST (Claude)，一个强化的“golden”Docker 基础镜像，以及 CI/CD 和 AI 辅助开发中安全门的基础。 本项目展示了现代 AppSec 中的两个理念： 1. **AI 驱动的分诊** — 模式匹配扫描器负责寻找_嫌疑对象_；而 LLM 则通过推理判断其_可利用性_，以减少误报噪声。 2. **从一开始就安全** — 提供一个预先强化的 golden 镜像供团队在其基础上 `FROM` 构建， 从而使安全成为默认选项，而不是事后补救。 ## 构建内容 ### 1. LLM 漏洞分诊 (`scanner/triage.py`) 在目标上运行 Semgrep，然后针对每个发现，将其周围的代码发送给 Claude，由其决定攻击者控制的输入是否真的能够到达 危险操作（真阳性）或不能（假阳性），并提出修复建议。 最终会生成一份排好优先级的 Markdown 报告。 在开发过程中构建并调试的功能： - **去重** — 合并命中相同文件和行的多条规则。 - **行号锚定** — 代码上下文包含真实行号并 标记出被标记的行，以便模型报告正确的位置。 - **常量检测** — 将隐藏在极长数据常量中的发现 标记为演示数据，从而防止一类假阳性。 - **污点源信号** — 标记用户输入 (`params[...]`) 到达被标记行的发现，用于确定优先级（绝不会默默丢弃）。 在 DSVW (Damn Small Vulnerable Web) 上的结果：**9/9 个发现被正确分诊** — 8 个真阳性（SQL 注入、命令注入、不安全的反序列化、 SSRF、代码执行）和 1 个被正确识别的假阳性。值得注意的是，在 登录查询中，分诊发现了一个部分缓解的 bug：用户名被净化处理了， 但密码却是直接拼接的 — 这是一个纯模式匹配会遗漏的细节。 示例报告位于 `examples/sample-report.md` 中。 ### 2. Golden 镜像 (`golden-image/Dockerfile`) 一个强化的 Python 3.12 基础镜像： - 固定且精简的基础镜像 (`python:3.12-slim-bookworm`)，以确保可重复性并 减小攻击面。 - 已应用 OS 安全补丁；移除了攻击者工具（如 wget）。 - 以 **非 root** 用户身份运行（CIS Docker Benchmark）。 - 安全的环境默认设置；升级了 pip 以修补已知的 pip CVE。 - 使用 Trivy 扫描：在任何严重程度上均有 **0 个可修复漏洞**。 `golden-image/build-and-scan.sh` 会构建镜像，如果存在任何可修复的 HIGH/CRITICAL CVE，则会失败 — 即“安全门”模式。 ## 如何运行 前提条件：Python 3.12、Docker、Semgrep、Trivy 以及 Anthropic API 密钥。 ``` # 设置 python3 -m venv .venv && source .venv/bin/activate pip install anthropic export ANTHROPIC_API_KEY=sk-ant-... # Triage：扫描目标，然后使用 Claude 进行 triage semgrep scan --config auto --json --quiet target-apps/DSVW > findings.json python3 scanner/triage.py # writes report.md # Golden image：构建 + 扫描 ./golden-image/build-and-scan.sh ``` ## 关键经验与观察 - **Prompt 校准是一种权衡。** 过于宽松会导致分诊对所有内容都一路绿灯； 过于严格则会漏报真实的 SQL 注入（假阴性， 这是更危险的错误）。Prompt 在不确定时会偏向于进行标记。 - **LLM 的能力仅取决于其上下文的质量。** 一个持续的假阳性结果 被证明是上下文提取的 bug：位于长达 9,800 个字符的常量内的发现 给模型提供了误导性的输入。修复提取器后，判定结果也随之修复。 - **总 CVE 数 ≠ 可操作的 CVE 数。** Golden 镜像显示有 142 个总 CVE，但有 0 个 _可修复的_ CVE — 大多数是无法在上游修复的 Debian 问题。基于可修复的 HIGH/CRITICAL 进行门禁拦截可以避免警报噪声，而这正是本项目致力于解决的问题。 - **扫描器的设计初衷就是过度报告。** 在 DSVW 上的 10 个原始 Semgrep 发现中，有两个 是同一行被不同的规则标记，还有一个是演示数据 — 因此 真正的信号是大约 8 个独立问题。去重和分诊才是将原始 输出转化为可操作列表的关键。 - **即使是官方基础镜像也会带有 CVE。** “安全的” python:slim 镜像 开箱即有 142 个漏洞。强化可以减少它们，但有些 漏洞是继承自上游且无法移除的 — 这就是为什么持续 扫描，而不是一次性强化，才是真正的实践。 - **Dockerfile 中的顺序很重要。** 在切换到非 root 用户_之后_升级 pip 会导致旧的易受攻击的 pip 留在原处（安装在用户的本地 文件夹中）。将升级操作移至切换用户之前可以干净地替换系统 pip — 这提醒我们，如果顺序排错，安全修复可能会在悄无声息中失效。 ## 路线图 - EPSS 评分，按真实世界的利用概率对发现进行优先级排序 - CI pipeline：在每个 PR 上进行扫描 + 分诊，发布报告，并对严重问题进行门禁拦截 - Agentic 安全：安全编码规则文件 + pre-commit hook - 向 AI 编程代理公开扫描工具的 MCP server ## 测试目标 - `DSVW` — 微型的单文件应用，用于验证分诊的正确性 - `PyGoat` — 真实的 Django 应用，用于更加嘈杂的真实世界演示 （两者都被克隆到 `target-apps/` 中，该目录已被 gitignored。）

标签：AI安全, Chat Copilot, CI/CD安全, Docker, Llama, LNA, 安全防御评估, 请求拦截, 逆向工具, 防御框架, 静态代码扫描