最近我在 arXiv 上刷到一个有意思的项目思路，标题大意是“把渗透测试拆成 pytest 能断言的子任务：Google 式记分法轮到防守方用了”。这个想法我第一眼看到就觉得必须好好聊聊。干安全这么多年，渗透测试的自动化一直是老大难，不是没工具，而是大家要么是纯脚本流水账，要么是“跑完工具再人工看报告”这种半自动状态。把渗透测试动作拆成 pytest 能断言的子任务，再配上类似 Google 内部用于优先级排序的记分模型，等于把进攻方那套“挑肥拣瘦”的打法和防守方最需要的“验证补丁有没有用”“风险面缩没缩小”直接对齐了。这篇文章我会把背后的拆解思路、实操落地步骤，以及我在实际踩坑中总结出来的教训，完整地铺开讲一遍。如果你是做 DevSecOps、红队自动化、或者是搞企业安全防御体系的人，这篇应该能给你不少可以直接抄作业的东西。
1. 项目概述：当渗透测试遇上 pytest 子任务
1.1 这个项目解决的到底是什么问题
传统渗透测试的核心产物是“报告”和“漏洞列表”。流程通常是：信息收集 → 漏洞扫描 → 验证利用 → 写报告。这里面最大的问题不是“扫不出来”，而是“扫出来的东西没法自动验证、没法自动回归”。你这次修完一个漏洞，下次发版会不会又漏出来？你不敢确定，因为漏洞验证往往是人在浏览器里手动点两下，或者用 Burp 重放一下包就算了。代码仓库里根本没有留下一个可以反复执行的“安全断言”。
而 pytest 恰恰是自动化测试领域最成熟的断言工具之一。它有 fixture 管理环境、有参数化批量跑用例、有断言机制判断通过还是失败。把渗透测试拆成子任务，本质上是把一次性的“攻击表演”变成可持续执行的“安全回归测试”。比如“检查登录接口是否存在弱口令”，就可以拆成“用弱口令字典请求接口 → 断言预期返回 200 而不是 401”；“检查响应头是否缺失 X-Frame-Options”，就是“发一个请求 → 断言响应头里存在对应字段”。一旦这些子任务能跑能用 pytest 断言，安全验证就从“人肉抽查”变成了“机器全量巡检”。
1.2 为什么突然冒出“Google 式记分法”
解决“能跑”还不够，还得解决“先跑哪个”和“跑了之后怎么定量评价结果”。Google 内部有一种很有名的记分方法叫 RICE，在项目管理里经常用来决定“哪个功能该做”。RICE 是四个字母：Reach（影响范围）、Impact（影响力）、Confidence（置信度）、Effort（工作量）。公式是 (Reach × Impact × Confidence) / Effort。这个模型天然适合渗透测试里的子任务排序：影响范围越大、危害越高、我们有把握程度越高、耗时越少的漏洞测试优先执行。以前这套思维多半被进攻方用来规划“打哪里收益最高”，现在防守方完全可以反过来用，决定“先补哪个洞、先测哪个模块、哪个安全控制最值得投入”。这个标题里说的“轮到防守方用了”，我理解就是这个意思，把 Google 那套给功能排序、给漏洞严重性排序的思路，嵌套进一个防守方自己的自动化验证框架里。
在这里先插一句我的观点：很多人一听到“用 pytest 跑渗透测试”，第一反应是“又要写一堆工具脚本”。但真正有价值的地方不是脚本本身，而是它表达的“断言思维”和“量化思维”。你有多少安全控制是能拿出来给 pytest 一条条断言的？有多少调整是可以被 RICE 公式算出一个数字的？想清楚这两个问题，这套东西才算入门了。
2. 核心拆解：如何把一次渗透拆成“可断言”的积木
2.1 从“自由探索”到“子任务流水线”
渗透测试之所以难自动化，是因为思维过程依赖人：你得根据响应内容的变化实时决定下一步。这个特性让很多自动化方案看起来都像刻舟求剑。但换个角度想，真正的渗透测试并不是完全没法拆。绝大多数执行过程可以被分成几个固定的阶段：信息收集、端口与指纹识别、漏洞探测、漏洞利用、权限维持和痕迹清理。每个阶段内部又是一系列固定的动作和判断。
所以“拆子任务”的正确姿势不是“把一次攻击脚本化”，而是“把一次攻击动作里面的判断逻辑脚本化”。比如“探测目标是否存在目录穿越”可以拆成一个子任务：
- 输入：目标 URL、特征路径
- 动作：请求带
../的路径 - 预期断言：响应码 200，响应内容包含
/etc/passwd的典型片段
这样一个子任务跑完是“通过”还是“失败”，完全由断言决定。至于前一步如何进行更深入的利用，那是另一个子任务的事情。子任务之间可以是链式的，也可以是完全独立的。独立的最好，因为独立意味着并发、意味着可以随机执行、意味着局部错误不会污染全局。
如果你做过实际的自动化测试，应该能体会这种感觉：把一个复杂的渗透过程拆成一个一个小格子，每个格子都有明确的输入、动作和期待返回值，本质上和写单元测试是一回事。只不过单元测试验证函数逻辑，安全子任务验证的是系统边界逻辑。这套东西一旦跑起来，你得到的不是一个让人看花眼的报告，而是一份“测试套件”和“测试报告”，团队里任何一个开发都能看得懂。
2.2 一张子任务定义的模板
我在实际落地时，习惯给每个子任务定义一个统一的结构，方便后续统一调度和记分。模板大概长这样：
- 子任务编号：用于统计和定位，例如 TASK-001
- 名称：一句话说清楚这个子任务测什么
- 类别：属于信息收集 / 漏洞探测 / 漏洞利用 / 权限维持 / 合规校验
- 前置条件：比如需要登录态，需要某个端口开放
- 目标：被测系统的 URL、IP、接口
- 请求定义：方法、路径、请求头、请求体
- 预期断言：状态码、响应头、响应体关键字、耗时等
- 风险评估：发现漏洞后的潜在影响等级（高/中/低）
- 测试资产权重：这个系统业务上有多重要（用于记分）
- 置信度：这个测试方法本身的可信度（用 0 到 1 表示）
- 耗时预估：执行一次大概需要多少秒
这张模板可以写到 yaml 文件里，也可以用 Python 类定义。我更推荐先用 Python 类定义，因为可以直接被 pytest 收集到。后续扩展哪怕只是加一个新的 HTTP 请求，都只需要改一个类属性，不需要动测试逻辑。
2.3 pytest 为什么是天然载体
pytest 有一个很重要的特性就是parametrize，这个特性用来做安全子任务批量执行简直再合适不过。你可以把一个“探测接口是否未做访问控制”的子任务，套上几十个接口路径，一次性把所有路径都跑一遍。每个参数组合都是一个独立的测试用例，跑错了也能单独定位。
再比如 fixture，可以用来管理请求会话、保持登录态、启动或销毁临时测试环境。安全子任务里非常常见的需求是“先登录拿 token，再测试后续接口”，这个需求用 pytest 的 fixture 实现非常清爽。你在一个conftest.py里定义一个login_token的 fixture，凡是依赖登录态的测试函数都声明依赖它就行。
断言又是 pytest 最核心的东西。安全测试里大量判断就是“等于”、“不等于”、“包含”、“不包含”、“状态码是 200”、“状态码不是 500”。pytest 的assert语句配合 Python 原生的数据操作，表达力已经足够。你不需要引入复杂的断言库，只需要把期望逻辑写清楚。
另外还有一点，pytest 生态有大量插件，比如pytest-html可以直接生成 HTML 测试报告，pytest-xdist可以做分布式并发执行。你完全可以把安全子任务套件纳入 CI/CD 流水线，跑完直接把 HTML 报告丢给研发群。这种可观测性，是传统渗透测试报告很难给的。
2.4 记分法：RICE 模型与防守场景的适配
前面讲了 RICE 是 Google 的优先级模型，但直接用还不能完全贴合防守场景。我的适配版本是这样：
防守方的 RICE 可以理解为：影响范围（Reach）等于“该漏洞如果存在，影响的资产数量”，影响力（Impact）等于“漏洞被利用后的业务后果”（可以映射成高中低分数，比如数据泄露 9 分，拒绝服务 5 分，信息泄露 3 分），置信度（Confidence）等于“子任务测试方法的技术可靠程度”，工作成本（Effort）等于“修复或加固这个控制需要投入的人天”。
这样一来，每个子任务跑完之后，如果断言失败（意味着漏洞仍然存在或加固措施未生效），就可以用公式算出一个“危险系数”：
危险系数 = (影响范围 × 影响级别 × 置信度) / 修复成本
这个数值越大，代表越应该优先处理。更妙的是，这个公式不是只能用在“测出漏洞”的时候。即便是断言通过，也就是漏洞不存在，你一样可以对“这个子任务有没有必要继续保留”按类似逻辑做评估。如果一个子任务影响范围很小、置信度又低、跑一次还特别费时间，那它就可以被降优先级甚至删除。这样测试套件本身就是可以自我演进的对象。
我觉得这里才是整个标题最锋利的地方：攻击方用记分模型是为了从一堆可能目标里挑出“最肥的一块肉”，防守方反用同一个模型是为了从一堆可能问题里挑出“最该修的一个洞”。两边数字直接对齐，不是各说各话。
3. 实操过程：写一个能自动“打点”的 pytest 套件
3.1 搭建最小可运行框架
假设我们要验证一个内部 Web 应用的安全控制，目标地址是http://demo.internal。我会先创建一个项目目录，里面至少要有：
requirements.txt用于管理依赖。conftest.py用于定义公共 fixture。subtasks/目录存放各子任务的 pytest 文件。scoring.py存放记分逻辑。
依赖方面，只要两个东西：pytest和requests。装完之后，直接在项目根目录执行pytest就可以开始跑。
pip install pytest requests然后建立一个最基础的conftest.py：
import pytest import requests @pytest.fixture(scope="session") def attack_session(): s = requests.Session() yield s s.close()这里我用requests.Session()的好处是，如果子任务之间有需要保持 cookie 的场景，同一个 session 能自然支持。暂不设置全局超时，后面每个子任务单独控制。
3.2 定义第一个子任务：探测响应头
先写一个最简单的安全子任务，不是漏洞渗透，而是安全配置基线检查，比如检查响应头X-Frame-Options是否存在。这个属于最稳定的子任务之一，断言清晰，不依赖业务数据。
在subtasks/test_security_headers.py里写：
import requests from urllib.parse import urljoin BASE_URL = "http://demo.internal" def test_x_frame_options_exists(attack_session): target_url = urljoin(BASE_URL, "/login") resp = attack_session.get(target_url, timeout=10) assert resp.status_code == 200, f"预期返回 200，实际返回 {resp.status_code}" assert "X-Frame-Options" in resp.headers, "响应头缺少 X-Frame-Options"这个测试的意图很清楚：如果断言失败，说明点击劫持防御配置缺失。把它写进 pytest 后，运行结果会明确告诉你具体是哪个头没带上。这种即时反馈，比人工翻响应头方便太多。
接着扩展一下，把多个响应头放到参数化里：
import pytest from urllib.parse import urljoin BASE_URL = "http://demo.internal" HEADERS = [ "X-Frame-Options", "Content-Security-Policy", "X-Content-Type-Options", "Referrer-Policy", ] @pytest.mark.parametrize("expected_header", HEADERS) def test_security_headers_exist(attack_session, expected_header): target_url = urljoin(BASE_URL, "/login") resp = attack_session.get(target_url, timeout=10) assert resp.status_code == 200 assert expected_header in resp.headers, f"响应头缺少 {expected_header}"这里用了parametrize，pytest 会自动生成多个用例，每个头单独报告。以后要加新的响应头，只需要往HEADERS列表里加字符串。这套写法的可维护性非常强，适合作为子任务的基础样板。
3.3 加入参数化批量测试多个子任务
接下来看一个真正贴近“渗透测试”的场景，比如验证路径是否存在未授权访问。
假设目标系统有这些接口：/admin、/api/users、/backup.zip、/console。我们想验证这些路径不登录是否可以被直接访问。子任务可以这样设计：
import pytest from urllib.parse import urljoin BASE_URL = "http://demo.internal" SENSITIVE_PATHS = [ "/admin", "/api/users", "/backup.zip", "/console", ] @pytest.mark.parametrize("path", SENSITIVE_PATHS) def test_no_unauthenticated_access(attack_session, path): target_url = urljoin(BASE_URL, path) resp = attack_session.get(target_url, timeout=10, allow_redirects=False) assert resp.status_code in (401, 403, 302), ( f"路径 {path} 未登录可访问，状态码: {resp.status_code}" )这个用例如果断言失败，大概率说明对应接口存在越权访问风险。你可以把SENSITIVE_PATHS换成从历史渗透报告里提取的高危路径，或者从爬虫结果里自动收集。这样每个路径都对应一个独立的 pytest 用例，任何一个异常都清晰可见。
为了防止误判，我通常还会加一个“登录后访问”的对照组，用同一组路径在登录态下访问，断言状态码不是 401/403。两个子任务一对比，就能过滤掉一部分“因为登录机制本身有问题导致的假阳”。
3.4 给子任务绑定记分逻辑
现在到了标题里“Google 式记分法”真正落地的地方。每个子任务跑完，我们会收集测试结果，然后调用记分模块，计算出这个子任务当前的危险系数。
举一个例子，定义一个子任务的数据结构：
class SecurityTask: def __init__(self, task_id, name, category, reach, impact, confidence, effort): self.task_id = task_id self.name = name self.category = category self.reach = reach # 影响资产数量，例如 5 个系统 self.impact = impact # 影响分数，例如数据泄露 9 分，DoS 5 分 self.confidence = confidence # 置信度，0 到 1 之间 self.effort = effort # 修复人天 def risk_score(self): return (self.reach * self.impact * self.confidence) / self.effort然后在 pytest 跑完之后，用一个脚本读取测试结果，把失败用例和SecurityTask匹配，计算出每个失败用例的risk_score。分数越高，越应该进入排期修复。
再进一步，为了让这个过程自动化，可以在pytest的钩子函数里收集测试结果。比如在conftest.py里实现pytest_sessionfinish，把所有失败测试输出成 JSON，再由scoring.py汇总计算。这样整个流程就是：
- 跑安全子任务。
- 拿到失败列表。
- 用 RICE 公式计算风险。
- 输出一份带优先级的工单。
这套流程最大的意义不是算出“某个漏洞是 4.5 分”，而是让安全团队有一个可以不断校准的数字模型。你把不同子任务的历史执行结果和真实漏洞报告放一起对比，慢慢就能知道哪些子任务的置信度调低了、哪些影响分数估高了。这个校准过程本身，才真正像 Google 内部做产品优先级那种调调。
4. 常见问题与排查实录
4.1 测试目标不稳定导致断言漂移
安全子任务最大的敌人是“目标不稳定”。接口响应偶尔超时、页面脚本动态渲染、负载均衡节点返回不同的响应头，都会让测试结果飘忽不定。我在实际项目里遇到过很典型的情况：某个响应头在节点 A 有，节点 B 没有，跑测试三分之一的概率是失败，但我们排查半天最后发现跟代码无关，是网关层某台机器配置漏了。
要减少这种问题，我建议给每个子任务设置合理的重试机制，并且区分“业务性失败”和“基础设施抖动”。可以在conftest.py里封装一个带重试的请求函数：
import time import requests def request_with_retry(session, url, retries=3, timeout=10, **kwargs): for attempt in range(retries): try: resp = session.get(url, timeout=timeout, **kwargs) return resp except requests.exceptions.Timeout: if attempt == retries - 1: raise time.sleep(1)这样能过滤掉一部分因为服务重启、冷启动导致的偶发失败。但要注意，重试次数不能太多，重试本身也会掩盖真实故障。建议核心子任务重试 2 到 3 次，非核心的干脆不要重试，看到失败就报警。
4.2 误报怎么压下来
误报的主要来源是“预期断言设置得不够准”。比如检查未授权访问，很多系统的登录接口本身是 200，但返回的是登录页而不是业务接口数据，你如果只看状态码，必然会误报。解决办法是加入关键字判断。
我平时在写断言时会额外关注响应体的特征，比如访问/admin未登录时如果返回了“登录页关键词”或“unauthorized”，那应该视为访问被拒绝，而不是未授权访问成功。改进版本长这样：
UNAUTH_KEYWORDS = ["login", "unauthorized", "请登录", "sign in"] def test_no_unauthenticated_access(attack_session, path): target_url = urljoin(BASE_URL, path) resp = attack_session.get(target_url, timeout=10, allow_redirects=False) assert resp.status_code in (401, 403, 302), f"路径 {path} 未登录可访问" if resp.status_code == 200: body = resp.text.lower() assert any(kw in body for kw in UNAUTH_KEYWORDS), ( f"路径 {path} 返回 200 且无登录标识，疑似未授权访问" )这种“状态码 + 关键字”的组合断言，可以显著压低误报率。当然，它也会带来新的漏报风险：万一某个系统未授权访问后返回的页面是空白状态码 200，这种判断就会漏掉。所以我又加了一条“登录态对照”，两边响应体如果高度相似，就说明未授权访问基本成立。
4.3 子任务之间的依赖关系如何编排
很多安全子任务是天然有依赖顺序的，必须先信息收集，再漏洞探测，再漏洞利用。pytest 本身并不适合描述复杂的拓扑依赖，它的定位是并发跑平铺的用例。处理依赖关系我有几种思路。
第一种，只把“可独立验证”的子任务放到 pytest 里，把“需要前后衔接的链式动作”放到单独的 Python 脚本里跑，最终产物是文件或者数据库记录。pytest 只消费这些产物。这种方式最稳定，也最容易排查。
第二种，借助 pytest 的 fixture 层做依赖管理。比如需要登录态才能测的接口，定义一个依赖登录的 fixture，pytest 会自然保证登录发生在测试之前。这是我日常最常用的方式，但只适合“单层依赖”。
第三种，复杂的子任务链路用单独的编排工具跑，比如在所谓的智能体框架里定义任务流程图。pytest 在这里只负责最底层的原子断言。记住：pytest 不是工作流引擎，你非要把复杂的多阶段攻击全塞进 pytest 里，最后调试成本会高得让你怀疑人生。
4.4 评分要不要交给机器自动决策
用 RICE 给漏洞排优先级，很容易让人产生一种错觉：算出分数最高的就直接修，分数低的不用管。我在这里必须泼一盆冷水：分数只是辅助排序的手段，不是绝对真理。
影响最大、置信度最高、修复成本最低的项，优先修，这个没问题。但有些时候，某个子任务测出的问题置信度很低，可万一真的被人利用，造成的后果又极其严重。这种“低置信度高影响”的组合，RICE 分数可能不高，但业务风险未必小。我的经验是，把 RICE 分数当作“待办列表排序器”，而不是“执行死刑判决”。每周人工审一次高分列表和低分列表，结合业务实际情况调整，永远比完全让机器自动决定要稳。
还要强调一点：很多安全控制不是靠一次子任务跑通就算结束了。比如“响应头有没有”这类检查，跑过只能代表那一刻没问题。配置漂移是常态，一个团队一个月后重新部署，很可能把之前的加固项漏掉。所以评分模型真正的作用，是告诉大家“哪些子任务应该被放进每周自动回归”，而不是“哪些子任务跑完就从此不用管了”。
4.5 合规与责任感：自动化进攻的边界
这个话题我必须认真说。把渗透测试拆成 pytest 子任务，本质上是在建一套“自动攻击系统”。这套系统跑起来以后，威力不比一个手动渗透测试人员小，可能还大得多。正因为如此，它天然自带合规和伦理风险。
我建议所有做这套东西的团队，一开始就明确边界。跑测试的目标范围必须白名单化，不允许任何子任务自己发现一个新 IP 就顺手打过去。执行前要做最小权限设计，尽量用只读账号、临时环境、隔离的测试域。生产环境上跑没充分验证过的子任务，纯属给自己找事。
还有一个容易被忽略的点：子任务本身可能会携带敏感数据，比如测试用的弱口令、后门路径、攻击载荷。这个仓库应该和普通代码仓库隔离，权限控制严格一点。我见过有人把这类测试代码直接推到公司统一代码库里，结果被扫描系统扫到，然后被安全团队约谈的案例。所以，安全自动化再酷，也别忘了保护好自己手里的“武器代码”。
5. 我的实操体会
这套“把渗透测试拆成 pytest 子任务 + Google 式记分”的思路，我已经在内部项目里试着落地过两轮了。最大的感受是：它能非常有效地把安全验证这件事变成“所有人都能看懂”的东西。以前你给开发提一个漏洞风险，开发第一反应可能是“你用什么姿势打进来的，复现一下给我看”。现在你给开发提一个 pytest 用例失败，开发第一反应是“哪个断言挂了，我看看为什么”。这个心态差异，真的能省掉很多扯皮。
我最后悔的一件事，就是最早落地时太贪心，想一次性把所有渗透步骤全部自动化，结果平台搭建耗时太长，子任务质量也没跟上。后面学乖了，只挑稳定且能明确断言的安全基线、常见漏洞探测类任务先跑起来，比如响应头检查、未授权访问、弱口令探测、敏感信息泄露，这些任务是整个系统里“性价比最高”的一批。它们跑稳了之后，再去扩展更复杂的利用链。如果你也要做类似的实践，我真心建议你从最简单的子任务开始，先让 pytest 在自己的监控下连续跑通一个星期，再逐步往上加复杂度。这个节奏，比一开始就搞大而全的方案稳妥太多了。
