Security Ownership Map：把Git历史变成安全地图，OpenAI开源的人-代码-风险图谱工具

你们团队负责认证模块的那个人如果明天离职，你知道哪些文件会变成孤儿吗？

大多数团队的回答是“不太确定”。CODEOWNERS文件写了名义归属，但git log讲的才是真话。OpenAI内部安全团队最近释出的Security Ownership Map，干的事情就是把这两者之间的差距量化出来。

CODEOWNERS是理想，git log是现实

很多团队都有一份CODEOWNERS文件，规定了每个目录或文件由谁负责。但现实是，代码的“实际维护者”和“名义负责人”常常不是同一拨人。有人调岗了、有人离职了、有人只是挂了个名——而git历史里记录着谁真正在改这些文件。

Security Ownership Map的思路不复杂：扫一遍git历史，提取每个人碰了哪些文件。然后做两件传统安全扫描器不干的事：算bus factor和标记孤儿敏感代码，顺便把人和代码之间的“隐藏所有权”也翻出来。

这不是另一个“装一下就出报告”的扫描器。它做的是更底层的事，把人、代码、风险三者拉成一张可以查询的图。

算三笔账：bus factor、孤儿代码、隐藏所有者

工具自动算三个指标，每一个都对应着一个真实的安全风险场景。

Bus factor——每个文件有多少个“够格”的维护者。这个概念很直白：如果一个文件只有一个人真正在维护，这个人被“bus”撞了（离职或失联），这个文件就没人管了。auth/、crypto/、secrets/这些敏感路径如果bus factor等于1，基本等于一个定时炸弹。

Orphaned sensitive code——敏感文件但维护者不足，且最近一次安全相关提交太久。有些代码可能三年前被标记为敏感，但最近一年没人动过它，也没有人真正理解它。一旦出问题，没人能修。

Hidden owners——某些人对某类敏感代码的控制权远超预期。有些人虽然在组织架构图上不是负责人，但git历史显示他才是真正在改这些文件的人。如果这个人突然走了，实际控制权就断了。

这三个指标回答的是同一个问题：“名义上有人管”和“实际上有人管”之间的差距有多大。

怎么用：三步走，纯本地跑

这个工具的依赖轻到让人意外。只需要Python 3和networkx一个库，没有数据库、没有向量存储、没有需要配置Token的后端服务，纯本地跑。

第一步，建图。run_ownership_map.py遍历git log，对每次提交提取作者、文件列表、时间戳。它不只看“谁写了哪一行”，还看“哪些文件总是在同一个提交里一起被改”，用Jaccard系数算文件间的共变强度。这一步输出三张核心CSV：people.csv（贡献者节点）、files.csv（文件节点）、edges.csv（人碰了哪个文件的边）。

第二步，打标签。工具内置了一套默认的敏感路径规则，auth、crypto、secrets相关路径自动标记。你也可以传一个自定义的CSV配置文件，每条规则带一个weight字段用来加权计算敏感接触的严重程度。密钥文件权重设到1.0，普通配置文件压到0.2，让最终的风险排序更贴近真实威胁面。

第三步，算风险。query_ownership.py可以按条件查询，比如“找出bus factor <= 1的auth相关文件”。所有数据存在summary.json里。工具默认还会在共变图上跑社区发现算法，把“经常一起被改”的文件聚成一组，给每个社区标上主要维护者。如果需要，整张图可以导出成CSV/JSON，导入Neo4j或Gephi做可视化。

适用场景：谁该用，什么时候用

这个工具面向的是安全工程师和平台团队的日常刚需，而不是大众开发者的尝鲜场景。几个典型的触发场景：

人员变动前的风险评估：核心员工要离职，跑一遍ownership map，知道哪些敏感文件会变成孤儿

安全审计：检查auth/、crypto/、secrets/目录的bus factor，找出单点依赖

CODEOWNERS文件体检：名义负责人和实际维护者到底匹不匹配

敏感代码热力图：哪些文件被频繁修改但维护者不足

Security Ownership Map做的事情本质上不复杂。它不发明新的安全理论，只是把git历史里已经存在的信息重新组织成一张可查询的图。但正是这种“不复杂”让它有用——它回答的是安全团队每天都在面对但一直靠猜的问题：这些代码到底谁在管？如果这个人走了怎么办？CODEOWNERS写的那个人真的还在改这些文件吗？

CODEOWNERS是理想，git log是现实。Security Ownership Map帮你看清这两者之间的差距——而这个差距，往往就是安全风险最集中的地方。