Hacktron 如何为 hackajob 的每个拉取请求带来覆盖整个代码库的安全上下文

“挑战从来不在于投入或专业能力。

“而在于上下文。没有人能在每次审查时把这么多上下文都记在脑子里，即便有两个人一起看也做不到。”

Dragos Dimitriu
合规负责人

关于 hackajob

hackajob 成立于 2014 年，打造的 AI 招聘技术服务于 50 多个行业的 200 多家公司，包括 American Express、Tesco、Barclays、HSBC 和 Sainsbury’s。

其旗舰产品 Archer 为企业招聘团队寻找、联系并筛选候选人。它的人才来源包括 150 万名经过审核的候选人和超过 8 亿份已索引的档案，每天根据实时招聘需求筛选 25 万名候选人。

在这样的规模下，围绕客户范围数据的授权控制至关重要。

挑战：审查者看到的是 diff，而不是调用图

hackajob 原本就有一套完善的审查流程。每个拉取请求都至少由两名工程师审查，且两人都不是作者。限制因素不在于审查投入，而在于每位审查者能掌握多少系统上下文。

“审查者看到的是 diff，而不是完整的调用图，所以漏网的缺陷通常是那些只有追踪一次改动如何与系统其他位置的代码交互时才会显现的问题。”

Dragos Dimitriu
合规负责人

Hacktron 如何融入：对每个 PR 持续审查

现在，hackajob 的每个拉取请求都会经过 Hacktron Review。Hacktron 在整个代码库中追踪每次改动，在审查流程中呈现发现，并在修复后重新扫描改动。hackajob 还设置了严重程度阈值：Hacktron 发现高于该阈值的问题时，就会阻止合并。

“Hacktron 发现的问题比人工审查实际能发现的更多，而且它在每个 PR 上运行，而不只是在有人标记为与安全相关的 PR 上运行。

“我们现在每周在越来越多的项目中运行 200 至 250 次扫描。这包括修复后的重新扫描，但这样的量仍然是我们无法以同等深度人工审查的。”

Dragos Dimitriu
合规负责人

发现分析

自 hackajob 于 2026 年 6 月首次使用 Hacktron 审查以来：

在已分诊的 143 个发现中，81.1% 是真实问题，而非噪音。

对象级授权失效导致跨客户数据泄露（高危）

Hacktron 在一个为 Archer 添加助手聊天功能的拉取请求中，发现了一个高危的对象级授权失效问题。

该端点会检查 book 范围请求的所有权，却不检查 account 或 cohort 范围的请求。普通用户只要提供另一个客户的标识符，就能越过自身的授权范围，获取该客户的沟通记录和情感分析数据。

1
// A book scope may only be the caller's own book unless they're an admin.
2
if (
3
    parsed.data.scope.kind === "book" &&
4
    parsed.data.scope.ownerEmail !== user.email &&
5
    !user.isAdmin
6
) {
7
    return new Response("Forbidden", { status: 403 });
8
}
9
// <- no equivalent check existed for "account" or "cohort" scopes

改动的文件本身看起来前后一致。只有当 Hacktron 比较不同范围类型的授权行为时，问题才显现出来。

“diff 中看不出任何问题，正因如此，无论审查者经验多丰富，这类问题在人工审查中都容易被漏掉。”

Dragos Dimitriu
合规负责人

Hacktron 在问题进入主分支之前就发现了它。hackajob 在同一个拉取请求中用不到一小时完成了修复：引入一个共享的授权函数，并为受影响的路径添加回归测试。

成果：覆盖整个代码库的安全上下文

现在，每个拉取请求都会接受同样覆盖整个代码库的安全审查。分诊和合并决策仍由工程师负责，Hacktron 则为他们提供系统上下文，让他们在代码进入主分支之前做出这些决策。

“Hacktron 在 PR 中就发现了它，所以它从未进入我们的主分支。

“这正是我们看重的。”

Dragos Dimitriu
合规负责人