Security Swarm is Devin’s security scanning and remediation product. It builds a threat model tailored to your code, investigates and validates potential vulnerabilities, and helps you fix findings through pull requests. It can identify vulnerabilities like remote code execution (RCE), SQL injection, path traversal, server-side request forgery (SSRF), authorization bypasses, memory-safety bugs, denial-of-service vulnerabilities, and more. It can even identify chained exploits spanning multiple files. Security Swarm is a custom orchestration of Devins we are calling Agentic MapReduce. It divides your repo among parallel Devins, providing broad coverage and deep investigation while bounding cost, making it cost-effective to scan large codebases.

Prerequisites

To run a scan:

• Your organization must have access to the repository you want to scan.
• You need to be authorized to use Devin sessions.
• You need the Use code scans permission.
• To configure an Auto Scan schedule, you also need Manage code scans and permission to manage automations.

Run your first scan

1. Open Security in the left sidebar and click Start scan.
2. Under Single repo, choose a repository to scan.
3. Optionally select a scan profile and a scan effort. Leaving the profile blank uses Security Swarm’s built-in security scan.
4. Make sure Interactive mode is enabled.
5. Click Run Scan.
6. When the proposed threat model is ready, review it and either click Looks good, start scanning or provide feedback.
7. As findings appear, review the evidence and act on the findings that need attention.

Review and act on findings

Open a scan to see its findings. The page displays a list of findings on the left, grouped by severity, and the selected finding’s details on the right. The status tabs show a live count:

• Open — needs attention.
• Reviewed — has been reviewed and no longer requires action.
• Dismissed — was determined as a false positive or duplicate.

What’s in a finding

A finding includes:

• Severity, status, exploitability, confidence, and category.
• The affected file path and code snippets.
• A description of the issue and a remediation recommendation.
• A sandbox validation result, supporting evidence, and validation artifacts.
• Associated pull requests and their open, merged, or closed state.
• Code owners and notes, when available.

Act on a finding

• Assign to Devin: Starts a Devin session to remediate the issue and open a pull request.
• Feedback: Sends context to a feedback session that refines the scan profile for future scans.
• Adjust: Overrides the finding’s severity, with optional context for Devin.
• Status menu: Marks the finding as Open, Reviewed, or Dismissed.

Scan profiles

A scan profile controls the scan’s scope and provides guidance for each stage of the scan. Every scan can use one profile.

Create a profile

• Generate with Devin — describe the application, threats, scope, exclusions, and severity standards in natural language.
• Create manually — fill in each profile input yourself.

Threat model

Assume an unauthenticated internet attacker or an authenticated user in one tenant.
Focus on public HTTP handlers, OAuth callbacks, API tokens, administrative actions,
and accesses to tenant-owned data. Treat internal development scripts and local-only
tools as out of scope. Prioritize authentication bypasses, cross-tenant access, token
leakage, injection, and SSRF.

Investigation guidance

Trace untrusted input from the route through middleware and service layers to the
sensitive operation. Check authentication, authorization, tenant scoping, validation,
and escaping at every boundary. Identify the exact reachable path and cite the relevant
files and lines. Do not report a theoretical issue when an effective mitigation blocks
the path.

Triage guidance

Group findings that share the same root cause. Treat unauthenticated remote code
execution and cross-tenant write access as critical. Treat cross-tenant read access and
credential disclosure as high. Treat single-user availability issues as medium unless
they can affect shared infrastructure. Label defense-in-depth recommendations as low.

Sandbox validation

Use the repository's documented development setup. Start the API and create two
non-production tenants with one test user in each. Attempt the suspected request as a
user from the other tenant, then verify both the HTTP response and persisted data.
Do not call production services or modify production data.

Remediation guidance

Prefer the smallest safe change and preserve existing public API behavior. Add a
regression test that fails before the fix and passes afterward. Run the affected package's
lint and test commands. Avoid major dependency upgrades unless the vulnerability cannot
be fixed safely without one.

Scale scanning

Access and permissions

FAQ

How does Security Swarm reduce false positives?
Security Swarm investigates potential vulnerabilities in the context of your repository rather than reporting risky patterns in isolation. Devin traces relevant data flows, checks for validation and authorization controls, and evaluates whether the issue has a concrete security impact.

What does sandbox validation add?
Sandbox validation attempts to reproduce a finding by building and exercising the application in an isolated environment. A successful validation provides stronger evidence of exploitability.

How does Security Swarm find vulnerabilities that span multiple files?
Security Swarm analyzes parts of the repository in parallel and combines the results into a repository-wide view. This allows it to identify relationships between components.