Introducing dfs-large1: A New Frontier for Cybersecurity | depthfirst

Sign in Request demo

Platform Your autonomous security command center<br>Code Find vulnerabilities scanners were never built to see<br>Supply chain Know what's reachable, not just what's present<br>Secrets Stop leaks before they leave the repo<br>Agentic Pentesting Find vulnerabilities in code that's already running<br>Dependency Firewall Detect malicious behavior before it spreads through your environment

About Learn how we help teams uncover threats before attackers do<br>Careers We're growing the team<br>Blog Insights, research, and security trends from our team<br>Events Join us at conferences, webinars, and live security sessions

depthfirst Open navigation<br>Sign in Request demo

Introducing dfs-large1: A New Frontier for Cybersecurity

Introduction

dfs-large1 is now in preview within the depthfirst platform. It is our most capable model to date, designed for vulnerability discovery and validation across large enterprise repositories. Built on GLM 5.2, it was post-trained inside depthfirst’s security agent harness using our RL stack, in partnership with Fireworks AI to scale training and inference.

dfs-large1 has shown consistent gains throughout our ongoing RL climb on long-horizon tasks that combine repository-level context, tool use, and executable verification. Performance continues to improve, with no clear sign of plateauing. Across our evaluations, dfs-large1 achieves best-in-class performance and establishes a new Pareto frontier for our production workload.

depthfirst-bench<br>Score<br>30% 40% 50% 60% 70% $5 $10 $15 $20 dfs-large1 GLM 5.2 GPT-5.6 Sol xhigh GPT-5.6 Luna xhigh Opus 5 xhigh Opus 4.8 high Kimi K3 max Grok 4.5 Gemini 3.6 Flash

Task price

dfs-large1<br>GLM 5.2<br>GPT-5.6 Sol<br>GPT-5.6 Luna<br>Opus 5<br>Opus 4.8<br>Kimi K3<br>Grok 4.5<br>Gemini 3.6 Flash<br>Note: Mythos and GPT-5.6 Cyber are omitted from this comparison because we did not have access to either model during evaluation.<br>To measure progress, we constructed depthfirst-bench to reflect the complexity of real-world security audits. Tasks are sourced from vulnerabilities in large repositories, where the evidence needed to establish a finding may be distributed across multiple components or repositories. Individual tasks can also contain several vulnerabilities, requiring the model to continue beyond the first plausible issue. depthfirst-bench captures the full workflow of a security audit, requiring findings to hold up under broader analysis and, where possible, executable verification. We will describe the construction and methodology of depthfirst-bench in greater detail in a future post.

In this report, we describe the multi-task RL recipe used to train dfs-large1, the audit behaviors that have emerged during training, and zero-day vulnerabilities discovered by the model.

Security Harness

Large enterprise monorepos are difficult for single-agent architectures to audit effectively. As repositories grow, audits become more expensive while code coverage and performance degrade. Our production security harness divides each repository into targeted audit scopes, giving every agent a bounded investigation surface while preserving the broader context required for vulnerability analysis. Each agent receives a bounded list of files and the corresponding scoped threat model, including attack surfaces, trust boundaries, and relevant data flows. Its shell remains rooted at the full repository, so it can inspect shared libraries, callers, dependencies, and other out-of-scope files when tracing reachability or exploitability. In multi-repository audits, related repositories are also available as supporting context. The harness executes these scopes concurrently at scale, allowing us to maximize code coverage while shortening the time required to assess the repository as a whole. dfs-large1 is optimized to operate within this framework across even the largest repositories.

Repository context is essential because vulnerability analysis is rarely local. An input that appears attacker-controlled may have been validated upstream, while a dangerous-looking sink may be unreachable from any untrusted path. Code that looks safe in isolation may also become exploitable through behavior elsewhere in the repository. Consequently, agents that reason only from local snippets can miss real vulnerabilities or report findings that do not survive broader analysis.

dfs-large1 is trained jointly on three tasks: detecting vulnerabilities in application code, detecting vulnerabilities in low-level systems code, and validating candidate findings. We include both detection and validation as learning objectives because they provide complementary learning signals. Low-level repositories often expose fuzz targets and reproducers that make defects directly testable, with a reproducible address sanitizer (ASan) report providing strong evidence of reachable memory corruption. Web application findings are harder to validate automatically...