Figma showing a virtuous circle between bug bounty, AI security scans and fixes

Figma Inc. reports that in the first week of its AI-powered security review system, only 15% of findings (4 of 27) were valid, prompting the company to hold back developer-facing comments until precision stayed above 70% over a two-week lookback. The system, which combines custom prompts, skills, and a precedents database, uses both OpenAI's GPT-5.6 Sol and Anthropic's Opus 4.8 models to maximize precision, and the effort produced a 99-line, 2,560-word threat model with 68 precedents that serves as a complete onboarding document for new hires.

Jot https://cephalosec.com/tag/jot/ Figma showing a virtuous circle between bug bounty, AI security scans and fixes Excellent, detailed article by Figma security engineers on how they stay ahead of vulnerabilities with agents https://www.figma.com/blog/how-figma-stays-ahead-of-vulnerabilities-with-agents/?ref=cephalosec.com . Let's start with the key vocabulary you need to know to understand the rest of the article: Precisionis the share of reported findings that are real vulnerabilities. High precision implies low false positives.Recallis the share of real vulnerabilities the system catches. High recall implies low false negatives.Ablationis the process of removing lines from a prompt to understand the impact of each line. Aprecedentis an example that explains why a finding is or is not valid in context. In this system, we prefer precedents over broad rules because they preserve the security reasoning an agent needs. The whole article is about how Figma managed to fine-tune a set of custom prompts, skills, and precedents database to feed into their own cybersecurity harness. This security review workflow is then leveraged for every new PR to spot new vulnerabilities and suggest for fixes before it makes it into production. I'll focus on the main takeaways. Fine-tuning the instructions is key to optimize signal versus noise. If you don't, you end up with a lot of “slop” in the form of invalid cybersecurity findings, and you'll exhaust the goodwill of your developers and lose the credibility of your cybersec team: ... in week one, only about 15% of findings 4 of 27 were valid. That is the trust problem behind OpenAI's argument that precision matters more than recall: Developers stop trusting any tool that floods them with low-quality findings. Precision had to come first, which is not the order you might guess. ... We held back developer-facing PR comments until precision stayed above 70% over a two-week lookback, with no embarrassingly bad false positives. This requires a lot of iteration and human expertise to label false positives and highlight the relevant precedents to steer the model into focusing on what matters. The author mentions that this is a very good exercise to go through even without any AI automation goal. It forces you consolidate your organic, collective knowledge into a comprehensive threat model. This is useful to everyone, especially new joiners: Ninety-nine lines, 2,560 words, and 68 precedents later, this work had a side effect we did not plan for: We had written a complete threat model, in roughly the form we'd want a new hire to read on day one.The policy is the threat model.Agents need security context in an explicit, structured format and at an unusually high resolution. Over Figma's first decade, that context accumulated across documentation, incident learnings, and deep institutional knowledge. It had not yet been consolidated at the resolution an agent needs. That artifact is the real payoff. Secure code generation and repo-wide auditing run on the same threat model, so we never had to build it twice. When it comes to models, they ended up leveraging both OpenAI and Anthropic model, respectively GPT-5.6 Sol and Opus 4.8, as they realised they have their own specialities when it comes to vulnerability findings. Combining them gave the highest precision. It's a shame they don't mention whether they tried cheaper models like GLM 5.2, DeepSeek V4 Flash or Kimi K3 and if so, if the tradeoff in performance is worth the cost savings. As the models kept getting better at doing complex and long horizon-tasks, they realised most of their prompt was unnecessary rehashing of banalities and ablated most of it. The prompting best practices also evolved a lot in the last year. It's not enough to switch to the latest SotA models, you also have to adapt the entire instructions set to get most of it: Following prompting best practices , the policy consists of precedents instead of rules. For example, rather than “don’t flag SQL injection in dbops ”, we write something like “ dbops is only run by highly privileged operators who already have direct database access.” The whole workflow also involves not one, but a multitude set of agents chained one after another. The most interesting one being the “adjudicator”, controlling the reviewer's agent work and making sure it didn't dismiss proper findings: The reviewer kept missing real bugs, and from analyzing eval data we kept seeing the same pattern: Chasing precision, the agent talked itself out of true findings with "pre-existing pattern," "low confidence," or "preparatory plumbing." The first pass already emits the candidates it dropped as structured output, so we added a second pass that re-examines those borderline dismissals. In our evals with known-bad commits, adjudication raised pass-rate recall by a relative ~30%. This constant chase for the highest recall and precision rates seems to be the most difficult part of the project. It requires constant adjustment as making any change to the instruction set can impact one or the other in unpredictable ways. For recall, they leverage historical work done by humans, this includes past audits and incidents, but also bug bounty findings: The framework uses a growing corpus of 66 tasks, each a real vulnerability that got past human review and into the codebase, surfaced only later by a bounty, an incident, or an audit. Forty-six of the 66 are tagged from our HackerOne bug bounty program 24 of those from a single top researcher and the remaining 20 are from internal incidents and audits. At a time were bug bounties are being overwhelmed with low-quality, hard to triage reports. It's refreshing to see companies like Figma findings ways to make it worthwhile. Part of the secret is to leverage AI again, this time for triage, similar to what Google https://cephalosec.com/blog/cybersecurity-harnesses-everywhere/ has been doing: Put a triage agent, with source access, on every incoming bug bounty report.A newer kind of bug bounty researcher chains low-severity vulnerabilities into high-impact exploits. Triage fast, build trust, and treat these researchers as some of your most valuable security assets. We can’t rely on the reviewer to catch a novel bug class outside the threat model. Those still fall to internal security experts and external sources such as the bug bounty program. Manual triage is too slow to sustain the whole feedback loop, whereas an agent enables fast triage that builds trust with researchers, feeds better evals, and eventually drives better recall. With that in mind, the recall improvement loop with bug bounties looks like this: 1/ A cloud agent picks up the report and triages it. 2/ The agent filters out the low-quality reports roughly 75% of submissions , and recognizes this one as different: a rare exploit chain. ... 3/ The agent writes a fix and opens a PR. Security on-call reviews the patch and merges it. 4/ The agent traces the vulnerability back to the commit that introduced it, andadds that commit to our eval corpus. 5/ A second agent runs our existing PR reviewer agent against that root-cause commit.If the reviewer doesn’t catch the bug, the second agent reads the reviewer’s own chat transcripts, works out why it missed Was the file even read? Read but not flagged? Flagged but excluded? , updates the policy until the reviewer catches the bug, and opens a PR with the change. Note all the doesn't “replace” your cybersecurity experts, they stay involved on the most impactful steps, once everything else has been curated away: Security on-call reviews the policy change and adjusts if needed. ... We use humans at several stages in this loop, because we still want human judgment on what we merge, especially if an external researcher reported the bug. Furthermore, automated policy refinement can still overfit “ Goodhart ” to the one bug in front of it, or produce a verbose amendment no human wants to read. To score recall, they also use an eval framework that score based on exhaustively but also on the severity of what the model detects. Again, this is where the bug bounty program helped, as the grade is based on the bounty payout, smart Precision is harder to optimize, it feels similar to research where papers rarely get published when the protocol failed. You have plenty of vulnerability write-ups and databases, but false positive ones? Not so much. To help, they leverage the most knowledgeable of the codebase to assess how harmful a finding is, the developers: The reviewer already runs on every PR, and the author knows their own change better than a security engineer seeing it for the first time, so the first call on each finding goes to them, though it isn’t final.A separate agent periodically re-reads the current code behind recent findings, and any disputed or unaddressed case whose flagged pattern is still present goes to security on-call to decide.Because findings are rare, PR authors encounter them only occasionally. ... If a PR author dismisses a comment as a false positive—either by a thumbs-down reaction, a comment indicating why, or both—we run a simplified version of the previous loop: 1/ An agent skill runs and updates the policy so that this class of false positives never shows up again. It takes into account developer feedback and looks through chat transcripts to see why the model made the error. 2/ Security on-call reviews the policy change and adjusts if needed. 3/ We run the reviewer against the baseline eval corpus with the updated policy. If you're worried about the extra workload for your security teams, Sigma managed 0 disputed finding for over a month in production. To keep the reviewer bearable for the developers, they tame models' verbosity by forcing the output format to “ one-sentence finding, numbered exploit steps, a short recommendation, and relevant code links ”. Is all this engineering effort worthwhile though? Models are getting more clever, most instructions become obsolete and good for ablation, shouldn't it be the case for documenting all those threat models and precedents? Not quite, the gap is still sharp enough to justify the extra work, especially to reduce noise i.e.: improve precision : To see what the engineering is worth versus the raw model, we ran the same Claude Code reviewer with our entire Figma policy ablated to nothing: just "find vulnerabilities," the model, and tools. It still cleared 44.4% of the corpus on payout weight.While a frontier model finds plenty of vulnerabilities with no help at all, our policy is still a significant advantage. With our policy back in, the same single reviewer climbs from 44.4% to 64.2%. Precision is the larger gap: With no exclusions to lean on, the empty prompt flags every suspicious pattern. Now that they have a stable PR review lifecycle they can trust, Figma tackled more ambitious tasks such as secure code auditing of their entire codebase: Auditing runs on the exact same policy we built for PR review. ... Models are stochastic and might not surface everything in a single review pass. Plus, our threat model is constantly evolving, and each new model generation can catch vulnerabilities the last one couldn’t. ... We made the task tractable by brute-forcing the problem with many agents. ... Two more adjustments helped: ablating low-severity bug classes so the budget goes where it matters, and bringing back a lightweight adversarial review pass to refute findings.On our first run, we found more than a hundred latent vulnerabilities, including two criticals missed by traditional SAST tools, which we patched immediately. We added both to our eval corpus, where they are now its two highest-scored tasks. They also addressed unsecure code generation at its core by adding dedicated agent hooks: To help agents generate secure code, we use hooks. We've found they steer agents more reliably than the same guidance placed in AGENTS.md .For some bug classes like logging safety writing data to the wrong logs , the drop after we added a guidance hook was about 50%. Next time you budget for your yearly penetration tests and bug bounty payouts, think about adding some token budget to the mix.