Devin Security 2.0: Built for the new threat landscape
By Steven Van ·
Devin Security 2.0 adds scans with Claude Mythos and other frontier models, threat-model prioritization, and parallel remediation sessions that open PRs.
Devin Security now covers the whole path from a vulnerability finding to a reviewable fix. Devin launched Devin Security 2.0, which joins scanning, prioritization and remediation in one workflow. Each finding goes through an investigation that establishes the attack path, assesses its consequences in the customer's environment, and carries that evidence into a proposed fix.
Managed scans with frontier cyber models
Devin Security can run managed scans with Claude Mythos and other frontier cyber models. Enterprise security teams can use them through Devin without separate access to the models. The process is model agnostic, so Devin can pick a model per investigation and use frontier cyber models for the most critical repositories.
Scanning uses an architecture Devin calls Agentic MapReduce:
- Devin maps the codebase for routes, authorization boundaries, data access patterns and other security-relevant code, against a threat model of the repo.
- The selected code is batched into groups and investigated in parallel.
- Devin aggregates the results, checks candidate findings, removes duplicates, and connects findings that may form a more serious attack path.
- Higher-priority findings are validated in a sandbox against a running instance of the application.
Prioritization from a threat model
When an investigation finishes, Devin labels the finding by answering two questions. The first is whether an attacker can exploit it in the customer's environment: whether the code is reachable from untrusted input, across which trust boundary, what has to be true for the exploit to work, and whether the code is live or dead. The second is what the damage would mean for the organization, such as one user reading another's data or escalating to org admin.
The answers come from a threat model Devin builds with the team. It is described as a living document that improves with every scan, covering services, hosts, network policies, security groups, deployment, data flows and trust boundaries. Some of this can be read from code and infrastructure definitions. Other details, such as which region a service runs in or whether an internal tool is reachable from the internet, have to be supplied, which is why building the model is collaborative.
Remediation as pull requests
Selected findings can be assigned to Devin individually or in bulk. Devin checks them against the current code, groups findings that share a fix, and starts independent remediation sessions in parallel. Each session has its own virtual machine, where Devin can run real services, reproduce the issue, implement a targeted fix and test it. Devin runs the reproduction test and the existing tests, then opens a PR with the investigation and test results. Findings stay open until the PR merges and Devin checks that the change closes the attack path.
Findings from other sources
The same workflow can be applied to findings from other scanners, bug bounty reports and existing backlogs. These can be imported from report files, exports and connected sources, with original identifiers and links preserved. Teams can choose to re-triage them with frontier models. Parallel sessions check the reported issues against the current code, identify duplicates, and test whether a vulnerability is still present or already mitigated.
With runtime validation enabled, selected findings are tested against a running build of the application. Devin records what it attempted and observed, including inconclusive results. Each finding stays traceable to its source as priority and status change, and supported integrations sync dismissal and reopening decisions back to the original tool.
