5.3 自动化与脚本编写

5.3 自动化与脚本编写

本节摘要：自动化在授权测试里的正确位置是"承接重复、释放判断"。本节先划清该自动化与不该自动化的边界，再给分层的自动化技术栈（命令别名与函数、脚本、编排框架、流水线集成），最后完整走一个可运行的脚本案例：把扫描输出自动归并为统一清单的归并器。

5.2 的复盘里藏着大量重复动作：每天对同一批资产做服务识别、把输出整理进证据索引、统计命中变化。这些正是自动化的对象——但边界要先划清。

先划边界：什么交给机器，什么留在人手里

交给机器的四类：重复采集（每日的例行扫描、固定范围的探测）；格式归并（把不同工具的输出转成统一清单）；差异计算（今天与昨天的资产/服务差异）；数据组装（报告的证据索引、工具版本清单生成）。

留在人手里的三类：验证判断（三态加工里"待验证到已确认"的每一步）；影响评估（业务影响的描述与分级）；修复建议（落地方案依赖对客户环境的理解）。划界的逻辑一句话：机器处理可枚举的，人处理需要担责的。报告上签字的是人，所以一切"结论性"的环节必须在人的手里完成。

分层技术栈：从别名到流水线

第一层：命令别名与 shell 函数。 成本最低、见效最快。把高频的长参数命令封装成短命令，顺手统一输出文件命名——证据索引的规范性从这一层开始。这一层的纪律：别名带默认的输出路径约定，保证"每次采集都落盘且可检索"。

第二层：独立脚本。 把一个完整动作（采集加归并加差异）写成一个脚本，配参数与帮助。3.1 的环境重建脚本、1.2 的范围核对脚本都属于这一层。

第三层：编排框架。 当"多个工具的输出要互为输入"时，用通用脚本语言写编排器，管理任务依赖与失败重试。安全领域有不少成熟框架可以承担这类编排，选择标准是团队熟悉度而非功能清单——框架是用来管理流程的，不是用来炫耀集成的。

第四层：流水线集成。 把自动化接到持续集成流水线里，实现"代码变更触发安全扫描"的左移形态。这已经跨进开发流程治理的领域，属于组织级工程。

# 第一层示例：几个立即可用的封装
alias recon-svc='nmap -sV -oN $(date +%F)-svc.txt'   # 服务识别，输出按日期命名
alias today-evid='ls -t *.txt | head -5'              # 最近五份证据文件

# 第二层示例骨架：每日归并器（见下文完整案例）
# 用法：./daily-merge.sh 2026-08-31
​

一个完整案例：扫描输出归并器

背景：5.2 那类演练里，每天的服务识别输出是多个文本文件，报告需要一份"资产到服务"的统一视图，手工拼接费时且易漏。

操作：写一个归并脚本，读入当日全部扫描输出，抽取"地址、端口、服务、版本"四元组，去重排序后生成统一清单。

#!/usr/bin/env bash
# daily-merge.sh —— 把当日扫描输出归并成统一服务清单
# 用法：./daily-merge.sh 2026-08-31
set -euo pipefail
day="${1:?用法: $0 日期}"
outfile="merged-${day}.csv"

echo "host,port,service,version" > "$outfile"
grep -hE "^[0-9]+/tcp" "${day}"-svc.txt 2>/dev/null | while read -r line; do
    port=$(echo "$line"   | awk '{print $1}' | cut -d/ -f1)
    svc=$(echo "$line"    | awk '{print $3}')
    ver=$(echo "$line"    | cut -d$'\t' -f2- | sed 's/^ *//')
    host=$(grep -B20 "$line" "${day}"-svc.txt | grep -oE "([0-9]{1,3}\.){3}[0-9]{1,3}" | tail -1)
    echo "${host:-unknown},${port},${svc},${ver}" >> "$outfile"
done
sort -u -t, -k1,4 -o "$outfile" "$outfile"
echo "[done] 归并完成：$(wc -l < "$outfile") 行（含表头）"
​

结果：当日六份扫描文件归并为一行一服务的清单，报告的"资产服务矩阵"直接由它生成。

解读：脚本的价值不在代码量，在于把"归并"这个动作标准化了——任何人任何一天跑它，得到同格式的产物。这正是 5.1 说"交接可复现"的技术支撑。注意脚本刻意只做归并不做判断：三态归类、影响评估都不在它的职责里（对照上文的边界表）。

变式：同样的骨架可以改造成差异计算器（两天的清单做集合差，输出"新增服务、消失服务"）、证据索引生成器（按文件时间戳与命名规则产出索引页）。差异计算器在多轮整改跟踪里尤其有用——第 2 轮复测时，"变化了什么"比"现在是什么"更接近客户的问题。

自动化的工程纪律

其一，脚本本身要进版本管理。 它们是团队资产，散落在个人目录里的脚本会在人员流动时蒸发。

其二，脚本输出必须可追溯。 每份产物带上生成时间、输入文件、脚本版本——报告引用数据时，这三样缺一不可。

其三，自动化不改变授权边界。 脚本跑得再快，范围核对（1.2）仍是前置闸门；事实上自动化的速度让这道闸门更重要——机器犯错的速度也比人快。

💡 一个起步建议：不要一上来就搭框架。第一周只做第一层（五个别名），第二周写一个第二层脚本解决你最烦的那个重复动作。自动化是长出来的，不是设计出来的。

脚本质量：可维护性的四条底线

脚本写多了以后，质量差异开始主导效率。四条底线值得在团队里立成规范：其一，入口自解释——脚本的用法说明写在开头注释里，无参数运行时输出帮助而不是直接执行；其二，失败即停——默认严格模式，任何一步失败立即中止并留下清晰的错误现场，"带病继续"的脚本比没有脚本更危险；其三，输出可追溯——产物文件名带日期与输入标识，内容里带生成命令的摘要；其四，幂等可重跑——同样的输入重跑得到同样的产物，不依赖执行历史。四条合起来就是一个标准：半年后你或任何同事拿到这个脚本，不用问人就能安全地使用它。

一个反例值得记住：某团队的自动化脚本里藏着一个写死的旧目标地址，无人记得它为什么在那里。某次参数拼写错误导致脚本回退到默认值，扫描打向了那个写死的地址——恰是早已超出本期授权的旧项目资产。事故没有造成损失，但复盘结论很刺眼：写死的参数是自动化里的定时成分。修复方式不是"下次小心"，而是把脚本改成"无显式参数即拒绝执行"——让错误在第一时间暴露，而不是在错误的对象上默默执行。

自动化与判断的分界再强调

结合本册的整体框架，把分界再压缩成一句可操作的判据：如果一个环节的产出会出现在报告的结论字段里，它必须经过人。采集、归并、统计可以全自动；但凡要写"已确认""影响为""建议做"的地方，人必须在环。自动化的正确雄心是把人从重复里解放出来，去把判断做得更好——而不是替代判断本身。理解了这一点，新工具新框架的取舍也就简单了：凡宣称"全自动出报告"的方案，先问它把判断放在了哪里。

自动化与判断的分界再强调一次，落到团队管理上还有一层含义：评审机器的产出与评审人的判断，要用不同标准。脚本的输出（清单、差异、索引）核对其完整性与格式；人的判断（分级、影响、建议）核对其推理链。两种评审混着做，要么对机器要求"解释为什么"（它解释不了），要么对人只查格式（放过逻辑漏洞）——分界清晰，评审才有的放矢。

本节要点回顾

• 边界原则：机器处理可枚举的，人处理需要担责的；
• 四层栈：别名函数、脚本、编排框架、流水线，按痛感逐层上；
• 归并器案例：标准化的价值是同格式产物与可复现交接；
• 三条纪律：进版本管理、输出可追溯、不改变授权边界；
• 成长路径：从五个别名开始，自动化长出来而非设计出来；
• 下一章接力：测试侧的流程到此完整，下一章坐到防守席——取证、加固、监控与红蓝紫对照。