"安全左移"这词喊了好几年了，但大部分团队实际啥样？

• 代码提交时压根没安全检查，顶多跑个secret scan凑合
• 安全审计是上线前才干的事，发现漏洞已经晚了
• SAST工具跑在独立环境里，跟CI/CD流水线是脱节的
• 扫出漏洞没人验证，一堆待确认工单在那堆着

问题不在工具少，在于安全根本没嵌进开发流程里。

天启时代最近开源了棋士AI代码审计平台和龙王小龙虾AI原生安全工作流，我从CI/CD集成的角度扒了一下，发现这俩东西的设计思路还真就适合做流水线里的安全门禁。下面说说我怎么搭的。

---

CI/CD里到底需要几个安全节点？

先别急着动手，把需求捋清楚。一条能用的DevSecOps流水线，至少得有三个安全卡点：

代码提交 → [门禁1：静态扫描] → 构建 → 部署到测试环境 → [门禁2：漏洞验证] → 上线
                                        ↓
                                  [门禁3：合规检查] → 出报告

门禁	要什么能力	现在怎么干的
1：静态扫描	低误报的漏洞检测	SAST跑一版，误报一堆，开发不看
2：漏洞验证	自动PoC验证，确认漏洞真假	手动搭环境写PoC？算了吧，基本跳过
3：合规输出	标准化报告直接出	手动拼凑，跟流水线完全脱节

三个门禁，棋士+龙王小龙虾刚好各管一段。下面逐个说怎么接。

---

门禁1：棋士做提交时的静态扫描

为啥棋士比传统SAST更适合放CI/CD里？

CI/CD里的安全门禁有个硬要求：误报必须少。不然每次提交都报一堆"高危"，开发第一反应就是把安全检查关了。

棋士的LLVM编译器前端+CodeBERT微调模型，解决的恰好就是这事：

• LLVM前端：编译器级别AST解析，理解代码结构，不是在那匹配字符串
• CodeBERT增强：语义层面二次判断，把不可达路径的误报滤掉

官方说误报率降了30%+，门禁信号更干净——报出来的大概率是真的，开发才愿意看。

怎么接

IDE插件——写代码时实时反馈

装个VS Code或IDEA插件，写代码的时候实时标可疑点。这是最"左"的位置——代码还没提交就发现问题了。

// VS Code settings.json
{
  "qishi.enable": true,
  "qishi.languages": ["java", "python", "go"],
  "qishi.severityThreshold": "high",
  "qishi.complianceStandard": "等保2.0"
}

CI/CD——提PR时自动扫

GitHub Actions为例：

name: Security Gate - SAST
on: [pull_request]

jobs:
  sast-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Qishi SAST Scan
        uses: qishi/scan-action@v1
        with:
          target: ./src
          languages: java,python
          severity-threshold: high
          fail-on-vulnerability: true
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: sast-report
          path: ./qishi-report.json

几个参数说明：

• severity-threshold: high——只高危阻断，中低危只记录。别把开发逼急了
• fail-on-vulnerability: true——高危漏洞时PR不让合，强制修
• 报告自动上传成Artifact，PR页面直接看

GitLab CI、Jenkins同理，都有集成示例。

门禁策略

别所有漏洞都阻断，得分级：

风险等级	怎么处理	为啥
高危（RCE、SQL注入）	阻断合并	不修不能上线
中危（信息泄露）	标记不阻断	后面排期修就行
低危	只记录	别影响开发节奏
合规类（等保）	标记+通知	让合规的人确认

---

门禁2：龙王小龙虾做漏洞自动验证

静态扫出漏洞了，但这漏洞是真的能打吗？没验证过的漏洞报告就是个"疑似"。以前验证靠手动，CI/CD里基本跳过——没时间也没手段。

龙王小龙虾刚好把这空白填上了。

怎么接进CI/CD

方案一：PR触发自动验证（轻量）

SAST门禁发现高危后，自动拉起龙王小龙虾验证：

name: Security Gate - Vulnerability Verification
on:
  workflow_run:
    workflows: ["Security Gate - SAST"]
    types: [completed]

jobs:
  verify-vulns:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Verification Environment
        run: |
          python workflow.py --module setup --auto-select
          # 根据漏洞类型自动选靶场模板
      
      - name: AI Generate & Run PoC
        run: |
          python workflow.py --module exploit --auto-verify
          # AI生成PoC直接跑验证
      
      - name: Generate Verification Report
        run: |
          python workflow.py --module reporting --format markdown
          # 出报告，复现步骤+证据
      
      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          script: |
            const report = require('./verification-report.json');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              body: `## 漏洞验证结果\n${report.summary}`
            });
      
      - name: Cleanup
        if: always()
        run: python workflow.py --module cleanup

效果：PR提交后，扫描→验证→报告全自动，结果直接评论在PR上。开发啥都不用管。

方案二：定时批量验证（深度）

上线项目跑定时任务，对已知漏洞做批量验证：

name: Weekly Security Verification
on:
  schedule:
    - cron: '0 2 * * 1'  # 每周一凌晨2点

jobs:
  batch-verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Recon - Asset Discovery
        run: python workflow.py --module recon --target ${{ secrets.TARGET }}
      - name: Full Verification Pipeline
        run: python workflow.py --full-pipeline
      - name: Upload Weekly Report
        uses: actions/upload-artifact@v4

验证结果怎么处理

验证结果	怎么搞
确认可利用	自动建Issue，标P0，分配给开发
打不了（误报）	关掉告警，记为误报，反馈回棋士优化规则
不确定	标待确认，通知安全负责人看

---

门禁3：合规报告自动出

等保2.0、数据安全法、个保法……合规要求越来越多，但材料准备往往是最后一公里最烦的。

棋士的合规输出

内置等保2.0规则库，扫完直接出合规格式报告：

qishi scan --target ./src --report compliance --standard "等保2.0" --output ./compliance-report.pdf

漏洞清单、风险等级（对标等保分级）、漏洞位置、整改建议——基本拿去就能用。

龙王小龙虾的验证报告

验证完自动出报告：复现步骤、PoC代码、证据截图、修复建议。

两份报告合一下

CI/CD里自动合并：

- name: Merge Security Reports
  run: |
    python merge-reports.py \
      --sast ./qishi-report.json \
      --verification ./verification-report.json \
      --output ./full-security-report.pdf

一份完整合规材料 = 棋士的合规报告 + 龙王小龙虾的验证报告，从扫到交全程自动化。

---

串起来看：完整流水线

三个门禁串起来就是这样：

开发提交代码
      ↓
[棋士] IDE实时扫描 ← 写代码时就反馈
      ↓
[棋士] CI/CD门禁扫描 ← PR级别安全检查
      ↓ （发现高危）
[龙王小龙虾] 自动验证 ← AI生成PoC一键验证
      ↓ （确认漏洞）
[龙王小龙虾] 自动出报告 ← 证据链+修复建议
      ↓
[棋士+龙王小龙虾] 合并合规报告 ← 等保2.0格式
      ↓
开发修复 → 合并 → 部署

核心原则：安全检查别阻断正常开发节奏，但高危漏洞绝不能放过。

---

踩过坑的几点建议

1. 别想一步到位，分着来

第一周：先把棋士的CI/CD扫描接上，跑通，调阈值
第二周：接龙王小龙虾的自动验证，先在测试项目上试
第三周：合并报告输出，对接合规流程

2. 阈值必须调

每个项目承受度不一样。金融项目可能中危就得阻断，内部工具高危才管。按业务场景调severity-threshold。

3. 误报反馈要闭环

开发遇到误报得有个简单路径反馈（PR评论标记误报就行）。这些反馈回流到规则优化，门禁才会越用越准，不然就是个摆设。

4. 验证环境一定做隔离

龙王小龙虾的Docker靶场跑在CI/CD的runner上，网络隔离别忘——验证流量打到生产环境那就搞笑了。

---

开源地址：

GitHub 仓库地址：https://github.com/orgs/tianqi-era-ai/repositories

安全左移不是一个工具能搞定的事，但把安全嵌进流水线的第一步，就是从"事后救火"变"事前防控"。这两款开源工具至少让这步的门槛降到了"能干"的程度。