Cognition launches Devin Security 2.0 and hands out hundreds of millions in credits

Cognition has released Devin Security 2.0, a product that takes a vulnerability from discovery to a verified pull request. It combines guided scanning with Claude Mythos and other frontier cybersecurity models, prioritization against a specific company's threat model, and autonomous fixes. With the release, Cognition is promising Devin credits worth hundreds of millions of dollars: free scans for current and future enterprise customers, and credits for new customers to fix their most critical holes.

Why the vulnerability queue now matters more than the vulnerabilities

The company points to recent events to explain the launch. Last week the PHP and Node.js projects disclosed remote code execution vulnerabilities, and every company running those stacks ended up in the same position: a public exploitation path, attackers reading the same advisory, and patches to roll out across container images, OS packages, CI pipelines and infrastructure configurations in dozens of repositories.

Cognition also breaks down the PHP2Shell exploit. Signs of one of the underlying problems were noticed as early as 2024, but the maintainers did not find a concrete path to RCE. The fix stalled on compatibility trade-offs, lack of resources and disagreements over approach, while more obvious bugs took priority. According to Wiz, frontier models helped researchers build and adapt working exploits for several applications within hours. The conclusion is uncomfortable: backlogs may hold many deferred bugs that AI has made practical to attack.

AI is also inflating the inbound stream. curl maintainer Daniel Stenberg described it as "high volume at high quality." According to the project's data as of October 22, 2026, it has already received 356 reports, against 181 for all of 2025. For comparison, 2024 brought 86 and 2023 brought 102.

How the Devin Security pipeline works

Scanning is built on a model-agnostic Agentic MapReduce architecture. Frontier models are used for the most critical repositories, and cheaper ones can be selected for the rest. The process has five steps:

• Plan: the agent maps the repository to the threat model and writes rules for sensitive code: routes, authorization boundaries, data access, deserialization, dangerous API calls. • Shard: the selected code is split into groups. • Map: separate agents investigate the groups in parallel. • Reduce: results are aggregated, duplicates are removed, and findings that together form a more serious attack chain are linked. • Verify: priority cases are checked in a sandbox against a running instance of the application.

Findings can then be assigned to Devin one at a time or in batches. It checks them against the current code, groups those that a single fix can resolve, and launches independent sessions, each with its own virtual machine. There Devin spins up real services, reproduces the problem, writes a targeted fix, runs a reproduction test and the existing tests, and opens a PR with the results of its investigation.

A finding stays open until the PR is merged and Devin confirms that the attack path is closed. If a permanent fix is still in the works and access is configured, the agent can temporarily add a WAF rule, change a security group or shut off public access to a service.

A threat model instead of a single CVSS score

Priority comes down to a set of questions. Is the vulnerable code reachable from untrusted input, across which trust boundary, does it require authentication or a special configuration, and is the code live? And what does the damage mean for the business: reading other people's data, escalating to organization admin, using the product without paying? Devin assembles the answers into a threat model together with the team: services, hosts, network policies, data flows, trust boundaries. Some of this can be read from code and infrastructure definitions. Some of it cannot (a service's region, whether an internal tool is reachable from the internet), so the work is collaborative.

Even strong models need verification. According to Anthropic's Glasswing review, of 1752 findings initially rated high or critical, 90.6% turned out to be real vulnerabilities, but only 62.4% were confirmed as high or critical. Finding a bug and correctly judging its severity are different tasks.

The same process works on existing backlogs. Devin imports findings from Snyk, Wiz, CSV files and bug bounty reports, keeping the original identifiers and links. Parallel sessions re-check them against the current code, look for duplicates and determine whether the problem has already been fixed. Decisions to close or reopen are synced back to supported tools. Older reports produced by weaker AI models can be re-checked as well.

Compliance is a separate scenario. Under FedRAMP, PCI DSS and internal policies, a high or critical finding starts a remediation clock, and the rating can be lowered only with documentation. For every re-scored finding, Devin keeps the original CVSS and writes a justification along six axes:

• reachability: whether untrusted input can reach the code; • authentication: what privileges are required; • data: what can be exposed or modified; • trust boundaries: which boundary has to be crossed; • validation: what was tried and what was observed, including inconclusive results; • source: where the finding came from.

A human approves the conclusion and exports it to a POA&M or GRC system. Devin does not re-score vulnerabilities from the CISA KEV catalog.

Where a security team should start

The practical minimum: gather the accumulated backlog from Snyk, Wiz and bug bounties in one place and re-check it against the current code, without trusting the old ratings. In parallel, it is worth writing down a threat model: without one, any automatic prioritization remains a guess. For critical repositories, it makes sense to run a scan with a strong model while Cognition's free scans are available, and to leave all fixes to human review. Cognition expects the "first mile" of incident response to soon run without a human. The company's head of security, Alex Stamos, plans to talk about the threat situation at a meeting on October 26 at 10:30 Pacific time.