81.1%
of triaged findings were actionable
92 findings
were resolved
The challenge was never effort or expertise.
It was context. No one can hold that much context in their head on every review, even with two sets of eyes on it.
About hackajob
Founded in 2014, hackajob builds AI hiring technology used by more than 200 companies across over 50 industries, including American Express, Tesco, Barclays, HSBC and Sainsbury’s.
Its flagship product, Archer, finds, engages and qualifies candidates for enterprise hiring teams. It draws from 1.5 million vetted candidates and more than 800 million indexed profiles, qualifying 250,000 candidates against live hiring briefs each day.
That scale means authorization controls around customer-scoped data are critical.
The challenge
hackajob already had a robust review process in place. Every pull request was reviewed by at least two engineers, neither of whom was the author. The constraint was not review effort, but the amount of system context available to each reviewer.
A reviewer sees a diff, not the full call graph, so the flaws that slipped through were usually the ones that only become visible when you trace how a change interacts with code elsewhere in the system.
Continuous security review with Hacktron
hackajob now runs every pull request through Hacktron Review. Hacktron traces each change across the codebase, surfaces findings in the review workflow and re-scans changes after fixes. hackajob has also set a severity threshold that blocks a merge when Hacktron finds an issue above that threshold.
Hacktron surfaces more than a manual pass realistically can, and it runs on every PR rather than only the ones someone flags as security-relevant.
We're at 200-250 scans a week now across a growing number of projects. That includes rescans after fixes, but it's still a volume we couldn't have reviewed manually at that depth.
Hacktron reviews your code and finds real vulnerabilities before they ship to production.
Since hackajob’s first Hacktron review in June 2026:
| Metric | Value |
|---|---|
| PRs scanned | 1,846 |
| Total findings | 295 |
| Findings evaluated | 143 |
| Actionable findings | 81.1% |
| Weekly scan volume | 200-250 |
Of the 143 findings triaged, 81.1% were real, not noise.
The finding: a cross-customer authorization gap
Hacktron found a high-severity broken object-level authorization issue in a pull request adding Archer’s assistant chat feature.
The endpoint checked ownership for book-scoped requests, but not for account- or cohort-scoped requests. A standard user could supply another customer’s identifier and retrieve that customer’s communications and sentiment data outside the user’s authorized scope.
// A book scope may only be the caller's own book unless they're an admin.if ( parsed.data.scope.kind === "book" && parsed.data.scope.ownerEmail !== user.email && !user.isAdmin) { return new Response("Forbidden", { status: 403 });}// <- no equivalent check existed for "account" or "cohort" scopesThe changed file looked internally consistent. The issue became visible only when Hacktron compared authorization behavior across the different scope types.
Nothing in the diff looked wrong, which is exactly why it's the kind of thing that gets missed in manual review regardless of the reviewer's experience.
Hacktron caught the issue before it reached the main branch. hackajob fixed it in the same pull request in under an hour by introducing a shared authorization function and regression tests for the affected paths.
The results
Every pull request now receives the same codebase-wide security review. Engineers retain ownership of triage and merge decisions; Hacktron gives them the system context to make those decisions before code reaches main.
Hacktron caught it in the PR, so it never reached our main branch.
That's the part that matters to us.