每次给网站做安全评审最头疼的往往不是漏洞本身而是“先知道该查什么”。团队里有人用在线扫描器有人手动查响应头有人翻浏览器开发者工具一通忙活下来结果散落在各处下次检测又得重来一遍。如果有一个工具能把常见的、不需要发恶意请求的检测项全部收拢起来本地跑完后直接出报告效率会高很多。Tblue 就是这样一个项目它提供 614 个被动安全扫描器面向任意网站运行而且整套流程都在本地完成。这篇文章会围绕 Tblue 展开先介绍被动安全扫描的概念和这项工具的核心设计再演示从环境准备到运行扫描的完整过程同时说明输出结果怎么看、常见问题怎么排查最后给出一套适合开发团队落地的使用建议。1. 什么是被动安全扫描器Tblue 解决了什么问题1.1 主动扫描和被动扫描的区别在安全测试领域扫描器大体上可以分为两类。主动扫描器会主动向目标发送探测请求比如常见的端口扫描、目录爆破、SQL 注入测试 payload 等。这类工具的特点是需要和目标建立大量交互可能与目标应用产生实际的数据变更甚至触发风控或报警。严格来说主动扫描需要非常谨慎因为一旦 payload 构造不当轻则干扰业务重则造成数据污染。被动安全扫描器则完全不同。它不主动发送攻击性请求而是基于目标网站已有的响应内容、响应头、证书信息、Cookie 属性、页面源码、JavaScript 文件、第三方依赖等公开可见信息进行分析。它的工作方式更像“检查清单自动执行器”拿到一个页面的响应后逐项比对安全基线把不符合要求的地方标记出来。Tblue 就属于后者。它的检测内容覆盖范围很广包括 HTTP 安全头是否缺失、Cookie 是否设置了 HttpOnly 和 Secure、TLS 版本是否过旧、CSP 策略是否过于宽松、CORS 配置是否存在风险、前端依赖是否包含已知漏洞等。这些项目不需要向目标发送恶意流量仅凭正常访问就能完成检测因此风险低适合在日常迭代中频繁使用。1.2 Tblue 的核心特征根据项目标题可以看到三个关键信息614 个扫描器、适用于任意网站、本地运行。614 这个数字代表默认规则集中的检测项数量。需要注意的是这个数量会随着版本更新而变化实际运行时应以当前版本展示的配置为准。检测项多意味着覆盖面广但它并不会一次性全部套用到每一个目标上因为不同类型的网站适用规则不同。比如一个纯静态站点和一个带有登录接口的后台系统它们面临的风险维度就不一样。“任意网站”主要指 Tblue 的输入不需要特殊适配。只要目标网址能从本地网络访问Tblue 就可以抓取其首页、静态资源、证书链、DNS 解析结果等内容再运行规则集进行分析。当然对于需要登录才能访问的内页它的检测深度会受限这个问题后面会单独讨论。“本地运行”是 Tblue 最值得关注的设计选择。所有扫描请求都从你自己的机器或内网发出不会把目标 URL 提交给第三方服务。对于企业内部系统、预发环境、未公开上线的业务这一点非常实用。扫描结果也全部保存在本地避免了数据外传带来的合规风险。1.3 常见应用场景Tblue 的使用场景可以归纳为四类第一类是开发阶段的快速自查。开发人员在提交代码前可以用 Tblue 对测试环境跑一遍提前发现安全头配置遗漏、Cookie 属性不规范等问题。第二类是上线前的安全门禁。运维或测试人员将 Tblue 集成进 CI/CD 流程在发布前自动生成一份安全基线报告如果关键检测项不达标可以阻止发布或提醒人工复核。第三类是历史项目安全体检。很多老项目长期迭代后安全配置早已支离破碎。Tblue 可以低成本地给这类系统做一次全面梳理输出一份整改清单。第四类是第三方站点风险评估。比如需要对接一个外部服务商提供的控制台先跑一遍被动检测对对方的整体安全水平做一个快速判断作为技术选型的参考依据。2. 环境准备与快速开始2.1 运行环境说明Tblue 采用 Go 语言开发发布形式是一个可执行二进制文件官方也提供了 Docker 镜像方便在不同系统中保持一致行为。本地运行需要准备的环境如下操作系统Windows 10/11、macOS、主流 Linux 发行版均可。Docker建议安装 Docker Engine 20.10 及以上版本用于运行官方镜像。命令行工具Windows 下可使用 PowerShell 或 CMDmacOS/Linux 下使用 Terminal。网络环境运行 Tblue 的机器需要能够访问目标网站同时能正常拉取 Docker 镜像。目标授权确保你对要扫描的目标网站拥有合法测试权限。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。具体安装步骤以 Tblue 官方 README 为准。2.2 获取 Tblue如果项目发布了 Docker 镜像最直接的方式是拉取镜像运行docker pull tblue/tblue:latest镜像名称以官方发布为准这里只是一个示例。如果不希望使用 Docker也可以从 Release 页面下载对应平台的二进制文件解压后直接放到系统 PATH 目录中。以 Linux 为例wget https://example.com/tblue-linux-amd64.tar.gz tar -zxvf tblue-linux-amd64.tar.gz sudo mv tblue /usr/local/bin/ tblue --version以上链接为示意实际下载地址请参考项目仓库的 Release 说明。2.3 确认安装成功Docker 方式安装完成后可以运行一条最简单的命令检查版本信息docker run --rm tblue/tblue:latest --version如果能看到版本号输出说明工具已经可以正常运行。接下来我们需要准备一个示例项目结构用来存放配置文件、扫描结果和报告tblue-demo/ ├── config/ │ └── tblue.yaml ├── results/ │ └── reports/ └── README.mdconfig 目录存放配置文件results 目录存放扫描输出结果reports 目录用于保存格式化报告。3. 配置文件详解3.1 配置文件的作用Tblue 允许通过 YAML 文件来定义扫描目标、输出格式、规则过滤条件等参数。配置化设计的好处是同一份配置可以应用到多个环境也可以提交到 Git 仓库统一管理避免每次扫描都在命令行输入一长串参数。下面是一个基础配置示例用于说明常见字段的含义# 文件路径config/tblue.yaml target: https://example.com output-format: json output-dir: ./results/reports verbosity: info include-scanners: - security-headers - cookie-attributes - tls-config - cors-policy exclude-scanners: - style-guide这个配置的意思是对 example.com 执行扫描输出 JSON 格式的报告到 results/reports 目录日志级别为 info。include-scanners 表示只运行指定的四类检测器exclude-scanners 则用来排除不想要的检测器。在实际使用中include-scanners 和 exclude-scanners 通常只需要配置一个。如果你希望跑全量 614 个检测项可以不用配置 include-scanners如果你只关心某几类风险建议显式配置 include-scanners减少不必要的输出噪声。3.2 扫描器分类与选择思路Tblue 的 614 个检测器会按类别组织常见的类别包括类别检测方向典型检查项security-headersHTTP 安全头Strict-Transport-Security、X-Frame-Options、Content-Security-Policycookie-attributesCookie 安全属性HttpOnly、Secure、SameSitetls-configTLS/证书配置协议版本、证书有效期、证书链完整度cors-policyCORS 跨域策略Access-Control-Allow-Origin 是否可被外部控制dependency-audit前端依赖风险已知漏洞版本的 JS 库information-disclosure信息泄露源码注释中的敏感信息、错误页面泄露堆栈content-type内容类型配置静态资源是否缺少 X-Content-Type-Options第一次运行时建议先不加过滤条件完整跑一遍看看报告整体长什么样再根据业务实际情况决定是否收敛规则集。3.3 多目标扫描配置如果需要同时扫描多个网址可以在配置文件中使用 targets 列表# 文件路径config/tblue.yaml targets: - https://app.example.com - https://api.example.com - https://admin.example.com此时 Tblue 会按顺序对每个目标执行扫描并分别输出报告。注意目标之间最好相互独立如果 A 站点依赖 B 站点的登录态扫描结果可能因为会话隔离而出现误报。4. 编写核心扫描流程4.1 基础扫描命令配置好 config/tblue.yaml 后执行一次扫描非常简单。Docker 方式可以使用以下命令docker run --rm \ -v $(pwd)/config:/app/config \ -v $(pwd)/results:/app/results \ tblue/tblue:latest \ scan --config /app/config/tblue.yaml这里使用了 Docker 的目录挂载功能。$(pwd)/config 是宿主机上的配置文件目录$(pwd)/results 是输出目录它们会被映射到容器内的 /app/config 和 /app/results。如果使用二进制方式命令更直接tblue scan --config ./config/tblue.yaml执行后终端会滚动输出日志显示正在运行的检测器名称和状态。检测项数量较多时整个过程可能需要几分钟具体时间取决于目标网站的响应速度以及规则集的整体耗时。4.2 单目标命令行快速扫描有时候项目刚起步还没准备好完整的配置文件只是想快速对一个网址跑一遍。这种场景下可以不使用配置文件直接在命令行指定目标tblue scan https://example.com --output-format json --output-dir ./results这样 Tblue 会使用默认的完整规则集对 example.com 执行扫描并把结果输出到 ./results 目录。这种方式的优点是快速缺点是无法保存配置不方便后续复用。建议当命令行验证通过后还是把参数整理成配置文件统一管理。4.3 指定输出格式Tblue 的扫描结果支持多种输出格式常见的有text纯文本格式适合终端直接查看。json结构化数据适合后续脚本处理或导入其他系统。html静态网页报告适合分享给团队成员阅读。在配置文件中可以这样指定output-format: html也可以同时输出多个格式output-formats: - json - html建议至少保留一份 JSON 格式的输出方便之后做趋势分析和自动化处理。4.4 运行与验证以 Docker 方式运行一次完整扫描后如果执行成功在 results/reports 目录下应该能看到生成的报告文件。可以列出目录确认ls -la results/reports/预期输出类似total 64 drwxr-xr-x 5 user staff 160 Aug 20 10:30 . drwxr-xr-x 3 user staff 96 Aug 20 10:30 .. -rw-r--r-- 1 user staff 10240 Aug 20 10:30 example.com.json -rw-r--r-- 1 user staff 20480 Aug 20 10:30 example.com.html文件名会根据目标域名自动命名方便在扫描多个站点时做区分。5. 扫描结果解读与报告分析5.1 报告结构概览Tblue 生成的 JSON 报告通常包含以下几类信息目标信息扫描的 URL、扫描时间、扫描器版本。检测结果列表每条记录包含检测器名称、严重级别、描述、建议。统计信息通过项数量、失败项数量、警告项数量、信息项数量。报告中的严重级别一般会区分为级别含义建议处理时间Critical高风险问题可能导致安全事件立即处理High明显不符合安全基线尽快处理Medium需要关注可能组合利用计划处理Low低风险属于防御纵深优化排期优化Info信息类提示不构成风险选择性参考拿到报告后最先应该看的是 Critical 和 High 两项优先安排整改然后再处理 Medium 和 Low。5.2 常见检测结果示例举几个常见的被动检测发现第一个例子是缺少 Content-Security-Policy 响应头。CSP 用来限制页面可以加载哪些外部资源如果没有配置页面一旦被注入恶意脚本浏览器几乎不会做任何拦截。Tblue 会把它标记为 High 或 Medium建议配置一段基础策略。第二个例子是 Cookie 未设置 SameSite 属性。SameSite 用于限制跨站请求是否携带 Cookie缺失时可能增加 CSRF 攻击风险。Tblue 会提示在 Set-Cookie 响应头中补充 SameSiteLax 或 SameSiteStrict。第三个例子是静态资源缺少 X-Content-Type-Options: nosniff。这个响应头可以防止浏览器对 MIME 类型进行猜测降低基于类型混淆的攻击面。修复方式是在 Web 服务器层统一添加响应头。第四个例子是前端 JS 文件版本存在已知漏洞。Tblue 会对页面中引用的第三方 JavaScript 库进行版本识别并与漏洞库比对。遇到这种情况需要升级到安全版本或者寻找替代库。5.3 误报分析与处理被动扫描的误报主要分为两类。一类是“检测器判断口径过严”比如某些老旧系统存在兼容性限制无法使用现代安全头但并不代表系统一定会被攻击。这类误报可以结合业务实际情况人工判定为可接受风险。另一类是“检测深度不足导致的信息缺失”比如目标页面是登录页Tblue 只能分析到登录页的响应头无法覆盖登录后的业务接口此时报告会显示大规模“未检测”状态而不是真正的问题。处理误报的正确方式是把人工结论记录在报告备注或独立的漏洞管理平台中避免每次扫描后重复分析同一个问题。6. 常见问题与排查思路6.1 扫描时报错“connection refused”这个报错说明 Tblue 无法连接到目标网站。可能原因有三种目标网站本身不可访问本地网络策略拦截了请求目标网站做了来源 IP 限制。排查步骤先用 curl 或浏览器确认目标网址可以正常打开。查看 Tblue 运行日志确认请求是否到达了目标服务器。如果目标有防火墙确认当前机器的出口 IP 是否在允许列表中。解决方案修复网络连通性后重新扫描。如果目标网站只允许特定 IP 访问确保运行 Tblue 的机器 IP 已加入白名单。6.2 扫描结果很少只有基础信息如果报告内容明显偏少通常是因为目标网站需要登录认证Tblue 默认情况下只能访问到公开页面。解决方案有三种第一种在 Tblue 配置中设置 Cookie 或 Authorization Header把登录后的会话凭证注入扫描请求中。示例配置headers: Cookie: sessionyour-session-token Authorization: Bearer your-token第二种先手动登录系统从浏览器开发者工具中复制完整 Cookie再填写到配置文件中。第三种接受现状只对公开访问部分做被动检测登录后的接口改用其他具备登录态处理能力的扫描工具。使用 Cookie 方式时需要注意Cookie 有有效期过期后扫描会失败。建议在 CI 流程中通过脚本动态获取 Cookie而不是长时间维护一个静态值。6.3 Docker 容器运行后没有生成报告先检查目录挂载是否配置正确。如果宿主机上的 results 目录没有映射到容器内Tblue 无法把报告写到宿主机。确认方法是在启动命令中保留 -v 参数docker run --rm \ -v $(pwd)/config:/app/config \ -v $(pwd)/results:/app/results \ tblue/tblue:latest \ scan --config /app/config/tblue.yaml再检查容器内的输出目录是否具有写权限。如有必要可以在容器命令中指定一个明确的输出路径tblue scan --config /app/config/tblue.yaml --output-dir /app/results6.4 扫描时间过长614 个检测器逐一执行确实需要一些时间但如果耗时异常可能是目标响应过慢或者某些检测器存在外部请求超时等待。处理建议先缩小检测范围只运行关键分类比如 security-headers 和 cookie-attributes。为每个请求设置超时时间避免长时间等待无响应的资源。确认本地网络到目标服务器之间的延迟正常。下面的配置示意如何设置超时request-timeout: 10s max-concurrency: 20max-concurrency 控制并发请求数合理提升可以缩短总耗时但不要设置过高避免对目标服务器造成压力。6.5 提示“no scanners matched”这个提示说明当前配置的过滤器没有匹配到任何检测器。通常是 include-scanners 中填写的名称和实际检测器名称不一致。解决方案是先不加过滤器运行一次完整扫描在输出的检测器列表中找到准确的名称再更新配置文件。下表汇总了上述常见问题。问题现象常见原因解决思路connection refused网络不通或目标限制 IP检查连通性确认来源 IP 白名单扫描结果过少目标需要登录态配置 Cookie 或 Authorization HeaderDocker 无报告生成目录挂载或写权限问题检查 -v 参数确认容器输出路径扫描时间过长目标响应慢或规则集太大精简规则集、设置超时、调整并发no scanners matched检测器名称配置错误全量运行一次查看准确名称7. 最佳实践与工程建议7.1 本地运行的优势要充分利用Tblue 的“本地运行”特性决定了它适合处理敏感目标。每周定时扫描一次预发环境报告直接保存到内网存储不经过任何外部服务这是最稳妥的使用方式。为了实现定时扫描可以借助系统的计划任务。Linux 下使用 crontab 示例0 2 * * 1 cd /opt/tblue-demo docker compose run --rm tblue scan这条命令的含义是每周一凌晨 2 点执行一次扫描。生产环境建议把这条命令放到独立的 CI Runner 上而不是直接跑在业务服务器上。7.2 配置文件纳入版本管理配置文件应提交到 Git 仓库同时把扫描报告目录加入 .gitignore避免大量报告文件污染代码仓库。一个建议的仓库结构security-scans/ ├── config/ │ └── tblue.yaml ├── scripts/ │ ├── scan.sh │ └── parse-report.py ├── .gitignore └── README.mdscripts 目录存放辅助脚本比如自动解析 JSON 报告并统计风险数量、将结果推送到内部监控平台等。7.3 建立修复闭环扫描只是发现问题的第一步更重要的是推动修复。建议给每个检测结果定义明确的负责人和处理时限。Critical 和 High 级别要求在 3 个工作日内完成修复Medium 级别要求在一个迭代周期内处理Low 级别进入待办池。如果团队已经有 Jira、禅道或内部工单系统可以通过脚本把 JSON 报告转换为工单描述自动创建任务。7.4 安全与合规提醒使用 Tblue 扫描目标时务必确保你拥有合法授权。建议在扫描前完成两步确认目标是否属于你所在公司或团队资产。是否已获得业务方和安全负责人的书面测试授权。不要在未授权的目标上运行扫描工具即使它是被动扫描器不代表完全没有法律和合规风险。内部工具要管好权限最小化这条原则一定要守住。8. 总结与下一步方向Tblue 把大量被动安全检查项整合到了一个工具中通过本地运行解决了敏感目标的数据外传问题很适合开发团队、测试团队和安全工程师配合使用。通过配置文件统一管理参数可以把它顺畅地接入日常迭代和发布流程让安全测试从一次性的“人工抽检”变成持续的“自动体检”。接下来可以继续深入学习的方向有三个一是理解每个检测项背后的原理建议从安全头开始逐个弄清为什么需要配置这些响应头、不同配置组合在不同场景下的优缺点。二是学习如何把 JSON 报告接入内部可视化平台做成趋势图表观察业务系统的安全状态变化。三是研究登录态处理方式例如如何安全地管理扫描用的 Cookie 或 Token这是扩展检测覆盖率的关键。做安全自动化不需要一开始就追求大而全。从最简单的安全头检查开始跑通一次扫描、看懂一份报告、推动一次修复这个闭环走通之后再逐步扩展检测场景会踏实得多。如果这篇文章对你有帮助可以先收藏备用等实际运行 Tblue 时再对照着配置。