OSINT Bible 2026：把散落各处的开源情报工具，编成一本可执行的工作手册

项目地址：https://github.com/frangelbarrera/OSINT-BIBLE ｜ 997 Stars ｜ 183 Forks ｜ GPL-3.0 ｜ 主语言 Python

一、一个真实的困境

如果你是一名安全研究员、手握一起疑似数据泄露事件的告警，需要在 48 小时内判断"这个账号是不是真的把客户数据挂出去了"——你会怎么做？

大概率是这样：打开搜索引擎，输入关键词，撞上一堆互相抄录的"OSINT 工具推荐列表"。这些列表本身早已过时：链接点进去是 404，工具早已停更，教程停留在五年前的 Shodan 用法。最后你花掉大半个工作日筛掉垃圾，剩下的还得自己拼成一套流程。

OSINT Bible 2026 想解决的正是这一层摩擦。 它不试图教你怎么用每一个工具（那是各个工具自己的 README 的事），而是回答一个更前置的问题：面对一个调查目标，我该按什么顺序、用哪一类工具、去覆盖哪些数据维度。

截至 2026 年 11 月，这个仓库已积累 47 个主章节、1086 条唯一外链、30 份国家/地区专题文档，Star 数从创建之初（约 2025 年 12 月）的零起步涨到近千，用了不到一年。

二、作者与项目动机：一个人的情报方法论仓库

仓库作者 Frangel Raúl Crespo Barrera 是一名网络安全工程师，专注防御架构，个人主页有 1300+ 关注者。他同时维护着几个姊妹项目：osint-agent-skills（把 OSINT 方法论打包成 AI Agent 技能与 MCP Server）、Abster-Intelligence（本地优先的隐私优先 OSINT 平台）、agentic-harness（可审计的自动化工作流）、Artificial-Intelligence-Universe（AI 工具目录）。

这个组合透露了项目的真实意图：OSINT-BIBLE 是这组项目的"知识内核"。文档定义方法论，skills 把它变成 Agent 可调用的技能，Abster 把它变成可交互的工具，harness 负责让流程留下审计痕迹。README 中有一处细节印证了这种工程化倾向——第 35 章专门讲"AI Agent Skills & MCP"，包括如何在 ~/.claude/settings.json 里挂载 MCP Server，以及一份相当完整的 Agent 安全基线。

换句话说，作者并不满足于做一本"链接收藏夹"，他想让这份知识最终能被 AI Agent 消费。

三、类比理解：一本"菜谱 + 食材清单"的组合

如果非要把这个仓库比作什么，它更像米其林指南 + 菜谱集的合体，而不是一本教科书。

• 方法论层（菜谱）：第 2 章的 4 步流程——定义问题 → 识别数据源 → 采集 → 验证与留证。最后一步是关键：截图、哈希值、时间戳、URL、archive.org 存档。这一步把"我觉得是这样"和"我能证明是这样"区分开。
• 工具层（食材清单）：47 章按数据维度而非按工具名组织，覆盖 Google Dorks 与替代搜索引擎、13 个社交平台的逐一打法、域名/IP/DNS 分析、邮件与手机号溯源、泄露库查询、区块链追踪、船舶与航空器追踪、暗网研究、WiFi 侧信道、深网身份反查等。
• 地域层（地方菜单）：countries/ 目录给出 30 个国家/地区的情报资源入口，从阿根廷到乌克兰，各有不同的公开记录制度与查询路径。

四、真正值得称道的工程设计

多数"awesome list"只维护一份 Markdown，而这个项目把链接健康当成构建步骤来管理，这正是它区别于同类项目的地方。

1. 自动化链路体检。 仓库配置了 lychee.toml，通过 GitHub Actions 的 lychee-action 在每次涉及 README、countries/** 的提交上跑链接检查，同时每周一 03:00 UTC 定时跑。当检查发现坏链，会自动创建带 broken-links、automated 标签的 Issue。

2. 可解释的体检报告。 audit/latest.md 并不只报"好/坏"，而是把 1086 条链接分成五档：OK 690 条、Dead 0 条、Blocked（WAF/登录墙/地域限制）126 条、Redirect 106 条、No response 164 条。报告还特别声明：被 WAF 拦截和无响应都不等于链接已死，读者必须自行复核。这种"承认不确定性"的态度在开源文档里相当少见。

3. Registry 驱动的内容生成。 scripts/build_readme.py 在 README 中用 <!-- AUTOGEN:sources:xxx:START/END --> 标记对，把工具表格从 data/sources.yml 自动渲染进来，散文部分保持手写；--check 模式可在内容过期时返回非零退出码给 CI 用。这就是"不产生失效链接"的机制根源。

4. Schema 约束的数据层。 data/tools.json 收录 66 条结构化工具元数据（含 id、name、url、category、type、license、purpose 必填字段），配合 data/tools.schema.json 与 jsonschema 做校验；countries.json 与各国 md 文件做一致性交叉检查。工具类型分布为 web 29、cli 21、dataset 12、cli+gui 4，许可证分布为 open-source 31、free 17、freemium 14、commercial 3、public 1。

5. 零依赖的实用 CLI。 scripts/ 下 8 个工具全部是纯标准库实现（仅开发依赖 pyyaml/jsonschema/requests）：osint_bible.py 提供 stats/search/country/validate/dorks/check/export/countries 八个子命令；dork_builder.py 为指定域名批量生成被动侦察 Google Dorks；username_check.py 检查用户名在各平台的路由是否响应；link_checker.py 做并发链接健康检查并输出 CSV。所有工具支持 --dry-run 与 --limit，便于在受限网络环境下安全使用。

五、门槛低到几乎没有，但也有明确局限

上手难度极低。 git clone 后直接读 README，或 pip install -r requirements-dev.txt 后用 CLI。无需 API Key 即可运行核心功能（仅 check 子命令和链接/用户名检查需要发 HTTP 请求）。这在当前工具依赖清单里几乎是个异类——绝大多数"情报框架"需要 Shodan、VirusTotal 等多套付费 Key 打通才能跑通。

但它不是工具，也不是课程。 局限同样清晰：

• 是索引，不是教程。 它告诉你"该去查平台元数据"，但不教你 EXIF 的具体字段含义。零基础用户读完仍然做不出一份报告。
• 链接可用 ≠ 内容准确。 作者自己在策展政策里写明："链接可用不能证明来源的准确性、安全性或授权状态。" 被收录的工具是否合法、是否仍在维护，需要使用者自行判断。
• 强烈的双用途属性。 仓库收录了大量渗透测试、泄露库查询、追踪类工具。这本身是 OSINT 研究的固有属性，但读者必须自行把控法律与授权边界——仓库开篇的伦理声明是严肃的，不是免责模板。
• 无自动化测试。 项目没有 pytest 之类的单元测试，CI 保障的是数据与链接的正确性，而非代码逻辑。考虑到它本质是文档仓库 + 脚本集合，这属于可接受的现状，但脚本修改缺乏回归保护。
• 内容偏英文。 全库为英文撰写，中文使用者需自行翻译，术语（Burn Notice、Trace ID 等）翻译后仍需回查原文。

六、行业意义与作者生态

OSINT 领域长期存在一个结构性问题：工具极多、教程极多，但"从目标到报告"的完整路径极稀缺。 大多数 awesome list 停留在"链接 + 一句话描述"，读者仍要自己设计流程。OSINT-BIBLE 的差异化在于把方法论、工具矩阵、地域适配和自动化维护打包在一起，形成一个可以持续更新的知识资产。

更值得注意的是它与作者其他项目的联动形态：文档定义知识边界，AI Agent 负责执行，人工保留最终判断权。 第 35.4 节的 Agent 安全基线写得相当克制——把每个页面、文档、搜索结果都视为不可信输入、MCP 工具最小权限、密钥与个人数据不得进入提示词、发送消息与大���下载需人工确认、模型生成的每条主张都必须独立验证。这套约束与主流 AI 安全实践是同频的。

从社区反馈看，"链接体检徽章显示 690/1086 可用"这个细节常被评测点名为最有价值的信息——因为读者可以据此判断某个引用是否值得跟进。一个诚实的坏链率，远比一个装满死链的漂亮徽章更有用。

七、适合谁，不适合谁

适合： 已有基本 OSINT 概念、需要一份工具版图和流程索引来快速定位方向的安全分析师、记者、威胁情报从业者；以及正在搭建 Agent 技能库、需要一份成熟 OSINT 知识骨架的开发者。

不适合： 期待手把手教学的小白；需要开箱即用、可视化界面或多源自动关联的完整工具链用户；以及希望项目提供持续更新的在线情报服务（而非一份需要自己判断时效的静态索引）的人。

结论： 这是一份高质量、高维护度、诚实标注不确定性的领域工作手册。它的价值不在于提供新的情报能力，而在于把散落的能力重新组织成可用的结构——并且诚实地告诉你哪些部分还在腐烂。

分析时间：2026-11-05 ｜ 数据来源：GitHub REST API（repos/contents/contributors）、仓库 README 与 audit 报告、外部评测站点（hysenlabs、osintcompass）