Security Swarm - Devin Docs

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. We also benchmarked Security Swarm against a ground-truth set of published vulnerabilities from the GitHub Advisory Database.

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.

If you do not see Security in the sidebar or cannot start a scan, ask an administrator to review your role. See Access and permissions for details.

Run your first scan

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

The New Scan sheet offers other scan modes for scanning several repositories at once or importing findings from an existing scanner.

For repeatable scans, create a profile that captures your scope, threat model, severity criteria, validation steps, and remediation constraints.

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.

While a scan is running, the page updates automatically as findings arrive.

Reviewed is a workflow status, not confirmation that a fix was merged. A finding can be marked Reviewed manually or when a later scan determines that it is no longer present.

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.

Treat a risky code pattern as a lead, not proof of a vulnerability. Check that the finding traces a reachable path from attacker-controlled input, accounts for validation and authorization controls, and explains a concrete security impact.

Act on a finding

Assign to Devin
Feedback
Adjust
Status menu

Starts a Devin session to remediate the issue and open a pull request. The session and resulting pull request are tracked on the finding.

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. To evaluate a repository against multiple attacker personas or threat categories, run separate scans with different profiles.

A specific threat model is one of the most effective ways to keep coverage consistent across scans. Define the attacker, sensitive assets, trust boundaries, important entry points, and explicit exclusions.

Manage profiles from the Profiles tab on the Security page.

Create a profile

You can create a profile in two ways:

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

Generating with Devin is a useful starting point, but review every generated field before using the profile. Leaving an optional guidance field blank applies Security Swarm’s built-in behavior for that stage.

Basic information

Profile name — name the application surface or threat category, rather than the team running the scan. Example: Multi-tenant API authorization.
Description — summarize the profile’s scope and security objective. Example: Find authentication, authorization, and tenant-isolation vulnerabilities in the public API.

The examples below combine into a single profile for a multi-tenant API. Adapt the boundaries, commands, and severity standards to your application.

Threat model

Describe the attacker, sensitive assets, trust boundaries, important entry points, and anything explicitly out of scope. This guidance shapes the rules Devin generates before investigation begins.

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

Define how Devin should investigate a potential issue and what evidence it should collect. Ask it to account for existing mitigations and to distinguish reachable vulnerabilities from theoretical concerns.

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

Define how Devin should deduplicate and prioritize findings. Include your severity criteria so results match your organization’s standards.

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

Enable sandbox validation when Devin can safely build and exercise the application. Explain how to start the application, create test data, authenticate, and demonstrate the expected security boundary. Use Validate severities to choose the lowest severity that Devin validates in a sandbox. Only findings at or above that severity start a validation session; by default, critical, high, and medium findings are validated. Raise the threshold to critical or high to spend validation effort only on the findings that matter most.

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.

An unsuccessful validation does not always disprove a finding. Review the validation result and artifacts to determine whether an effective mitigation blocked the exploit or the configured environment prevented Devin from completing the test.

Sandbox validation starts a separate Devin session for each finding. See Configure sandbox validation for environment guidance.

Report

Enable reports when you need a summary artifact after the scan. Specify the intended audience and the information the report should emphasize.

Write an executive summary for security and engineering leads. List confirmed critical
and high findings first, followed by unvalidated findings. Include affected components,
validation status, pull request status, and a prioritized remediation plan.

Remediation guidance

Specify constraints that Devin should follow when you assign a finding for remediation. Include testing expectations, compatibility requirements, and practices to avoid.

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.

Advanced inputs

Open Advanced to control file scope and investigation batches:

Include globs — restrict the scan to matching files. For example, apps/api/** and packages/auth/**.
Exclude globs — remove irrelevant files from the selected scope. For example, **/generated/**, **/vendor/**, and **/fixtures/**.
Batch size — control how many files with signals are grouped into each investigation batch. Leave this at its default unless you are deliberately tuning scan behavior. The accepted range is 1–500; the default is 5.

Overly broad exclusions can hide vulnerable code or remove context needed to understand a data flow. Exclude only files you are confident are irrelevant to the profile.

Ingestion profiles

A profile’s mode is fixed when you create it. Discover profiles (the default) analyze your code to find new issues and use the guidance fields above. Ingest profiles import findings you already have from another scanner or report, and replace the scope and threat model inputs with two guidance fields:

Ingestion source — where the existing findings live and how Devin should fetch them. For example, fetch open alerts from GitHub code scanning through its REST API, or read a Semgrep report committed at reports/semgrep.json. Reference credentials by organization secret name rather than pasting a token.
Post-ingestion triage — how Devin should triage the imported findings: what to dismiss, what to reprioritize, and what to treat as a duplicate. For example, dismiss findings in test fixtures and treat findings with the same rule ID and file as duplicates.

See Ingest existing findings for how to run a scan with an ingestion profile. The Profiles tab can be filtered by scan type and by mode (Discover or Ingest).

Organization and enterprise profiles

New profiles are organization-scoped. Enterprise admins can later change a profile’s visibility to Enterprise, making it available across the enterprise. Enterprise profiles can only be edited or archived by enterprise admins. Other users with access to Security can view and use them but cannot modify them.

Interactive mode

With Interactive mode enabled, Devin builds a proposed threat model and pauses before investigation. The scan page displays the proposed rules and lets you:

Looks good, start scanning — accept the threat model and begin investigation.
Provide feedback on the threat model — describe what to add, remove, or emphasize, then review the revised model.

Use interactive mode for the first scan of a repository and whenever its risk surface or profile changes significantly. Once the profile captures the approved guidance, routine scans can run without the pause.

Configure sandbox validation

Sandbox validation runs only when the selected profile has sandbox validation enabled and contains validation guidance. Give Devin enough information to build, run, seed, and authenticate the application in its sandbox. If the repository has declarative configuration, Devin can reuse its build and installation setup. Otherwise, add the required setup commands to the profile’s validation guidance.

Do not put production credentials or secret values directly in profile guidance. Use non-production test accounts and credentials already provided through your organization’s environment configuration.

Scale scanning

Choose a scan mode

The New Scan sheet offers four scan modes:

Mode	What it does	Best for
Single repo	One scan of one repository.	A focused scan of one codebase.
Multi-repo	One scan across up to 200 repositories that Devin analyzes together.	Microservices or repositories that call each other, so Devin can catch issues that span repository boundaries. Findings can be filtered by repository.
Bulk scan	A separate, independent scan for every matching repository.	Covering a whole organization at once. Repositories are not analyzed together.
Ingest findings	Imports findings from your existing tooling or reports instead of discovering new ones.	Bringing results from another scanner into Devin for triage and remediation. See Ingest existing findings.

Interactive mode is available for single-repo and multi-repo security scans. It is enabled by default for a single-repo scan when your organization has not run a scan yet.

Scan effort

Every scan runs at one of two effort levels, selected under Scan effort when you start it:

Normal (default) — a faster scan that uses larger investigation batches.
Deep — traces each finding further through the codebase for maximum thoroughness, at a higher cost and longer runtime.

Use Normal for routine and incremental scans, and Deep for a first scan of a high-risk codebase or a periodic in-depth review. The effort a completed scan ran with is shown in its header.

Bulk scan an organization

Use Bulk scan in the New Scan sheet to queue a separate scan for every matching repository:

Optionally enter a Repository name filter.
Optionally select a scan profile.
Keep Skip already-scanned repos enabled to exclude repositories already scanned with the selected profile.
Click Preview.
Review the matching repositories, deselect any you do not want to scan, and confirm.

The preview is a dry run. Changing the filter, profile, or skip setting invalidates the preview so you cannot confirm a stale list.

Ingest existing findings

Use Ingest findings to bring results from another scanner into Security Swarm so you can triage, validate, and remediate them alongside Devin’s own findings:

Select one or more repositories the findings belong to.
Select an ingestion profile. The profile tells Devin where the findings live and how to triage them after import.
Optionally attach up to 10 reports or exports (for example SARIF, CSV, or PDF files) for Devin to read findings from. If the profile’s ingestion source already points at an API or a file in the repository, no attachment is needed.
Optionally enable Interactive mode. After importing, Devin pauses so you can review what was ingested, including possible duplicates, and request corrections before it continues.
Choose a scan effort and click Run Scan.

Imported findings appear on the scan page like any other finding, so you can assign them to Devin, adjust them, or change their status. The scans list can be filtered by mode to show only Discover or only Ingest scans.

Uploading attachments goes through the attachments API, so ingesting from uploaded files also requires Use Devin sessions. Ingestion scans can also be started from the API.

Auto Scan

Auto Scan periodically scans commits added since the last completed scan. You can configure it:

While starting a single-repository scan by selecting a daily, weekly, monthly, or custom schedule.
From an existing scan by adding, editing, or disabling its schedule, or by clicking Scan now to run it immediately.

Schedule times are shown in your local timezone.

Auto Scan is only available when automations are enabled for your organization. Configuring it requires both Manage code scans and permission to manage automations.

Auto Scans are incremental: each run only investigates the commits added since the last completed scan. Clicking Start scan instead defaults to a full scan of the repository scope.

Scan new commits

Click Scan new commits on a completed scan to investigate commits added since its last scanned commit. Auto Scan uses the same incremental behavior, making subsequent scans less expensive than repeatedly scanning the full repository scope. Each full or incremental run is recorded in the scan’s scan history.

Start scans from Automations

Automations include a Code scan agent type for scans that should run on a schedule or in response to an event. Instead of starting a Devin session with a prompt, the automation starts the scan directly. Choose one of two actions:

Start code scan — starts a fresh scan of the configured repository or repositories, scan type, profile, and effort each time the automation fires.
Scan new commits — extends an existing scan with an incremental run covering the commits added since its last completed run. The scan must already have a completed run.

Auto Scan is a preconfigured automation of the second kind. Use the Automations page when you want other triggers, such as a webhook, or when you want to manage all scheduled scans in one place. You can also start a scan from a session’s composer with the /scan command. For performance, test coverage, dead code, and other non-security scans, see Code Scans.

Manage and monitor scans

Depending on the scan and its profile, the scan header can include:

Reports — download reports generated for the scan.
Usage — view ACUs consumed, session count, scan duration, and pull request statistics.
Session — open the main Devin session that performed the scan.
Scan history — view every run of the scan. See Scan history.
Change profile — switch the profile used by future runs. See Change a scan’s profile.
Export as CSV — export the scan’s findings.
Archive or Unarchive — hide the scan from or restore it to the default list.
Scan new commits — start an incremental scan.

Scans run as Devin sessions and consume ACUs. The scans list on the Security page can be filtered by status, pull request state, and scan mode (Discover or Ingest).

Scan history

Open Scan history on a scan to see every time it has run, newest first. Each run shows whether it was a Full scan or Incremental, its status, the effort and profile it used, the ACUs it consumed, and a link to its Devin session. Use it to confirm that Auto Scan is running as scheduled and to compare the cost of full and incremental runs.

Change a scan’s profile

Click Change profile on a completed scan to select a different profile. The new profile applies to future runs of the scan, including Auto Scan and Scan new commits; completed runs and their findings are unaffected. You cannot change the profile while a scan is running. Changing a profile requires Use code scans.

Security dashboard

After the organization completes its first scan, the Security page displays an organization-wide dashboard for the last 7, 30, or 90 days:

Pull request statistics — created, merged, open, and closed pull requests, plus merge rate.
Findings over time — findings grouped by severity across the selected period.

Access and permissions

Security access is controlled through code scan permissions in the role editor:

Permission	What it unlocks	Default roles
View code scans	View scans, profiles, findings, and associated scan sessions.	Admin
Use code scans	Start scans, create organization profiles, submit finding feedback, adjust findings, change finding statuses, and assign findings to Devin.	Admin
Manage code scans	Archive or unarchive scans and configure Auto Scan schedules.	Admin
Manage account code scans	Promote organization profiles to enterprise scope and edit or archive enterprise profiles.	Enterprise admin

Starting scans, submitting feedback, and assigning findings to Devin also require permission to use Devin sessions. Auto Scan additionally requires permission to manage automations. By default, members do not receive code scan permissions. Owners have every permission, and administrators can grant permissions to members through custom roles. The same code scan permissions gate the Code Scans API (API calls do not additionally require session permission, except that uploading scanner reports for ingestion scans goes through the attachments API, which needs Use Devin sessions). Service users or personal access tokens with Use code scans can start scans, start ingestion scans, and remediate findings; View code scans covers listing scans, profiles and their guidance, findings, and metrics. See Triggering Code Scans via the Devin API for the end-to-end flow.

Compare Security Swarm with another scanner

For a useful comparison, give both scanners the same scope, threat model, severity criteria, and validation expectations. Differences in configuration can otherwise obscure differences in underlying capability. Use profiles to encode the comparison criteria, interactive mode to confirm the generated threat model, and sandbox validation to apply the same standard of evidence to reported findings.

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.Each finding includes a confidence level and supporting evidence. Review that evidence before acting, especially when a finding has not been validated in a sandbox.

What evidence should I review in a finding?

Check the affected code, entry point, data flow, existing mitigations, stated impact, confidence, and exploitability. When sandbox validation is enabled, also review the validation result and its supporting artifacts.If the evidence overlooks a control or claims an unsupported impact, use Feedback to provide the missing context for future scans.

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, while an unsuccessful validation can identify assumptions or environment limitations that require further review.Sandbox validation is optional and requires enough validation guidance for Devin to build, run, seed, and authenticate the application safely.

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, such as one endpoint exposing an identifier required to exploit another endpoint.Any resulting chained finding should still identify the relevant code paths and explain how the individual conditions combine into a concrete impact.

Why might results vary between scans?

Security Swarm uses agentic analysis, so separate scans may not produce identical findings or wording. A focused scope, explicit threat model, clear severity criteria, and specific investigation guidance help keep coverage consistent.Capture those requirements in a reusable scan profile, use interactive mode to review the proposed threat model, and provide feedback when a result misses important context.

Does a completed scan mean the repository has no other vulnerabilities?

No security scanner can guarantee complete coverage. Results depend on the selected scope, profile guidance, available repository context, and whether findings can be validated in the configured environment.Run separate scans for distinct attacker models or threat categories, keep profiles current as the application changes, and use Security Swarm alongside your existing security review and testing practices.

​Run your first scan

​Review and act on findings

​What’s in a finding

​Act on a finding

​Scan profiles

​Create a profile

​Basic information

​Threat model

​Investigation guidance

​Triage guidance

​Sandbox validation

​Report

​Remediation guidance

​Advanced inputs

​Ingestion profiles

​Organization and enterprise profiles

​Interactive mode

​Configure sandbox validation

​Scale scanning

​Choose a scan mode

​Scan effort

​Bulk scan an organization

​Ingest existing findings

​Auto Scan

​Scan new commits

​Start scans from Automations

​Manage and monitor scans

​Scan history

​Change a scan’s profile

​Security dashboard

​Access and permissions

​Compare Security Swarm with another scanner

​FAQ

Run your first scan

Review and act on findings

What’s in a finding

Act on a finding

Scan profiles

Create a profile

Basic information

Threat model

Investigation guidance

Triage guidance

Sandbox validation

Report

Remediation guidance

Advanced inputs

Ingestion profiles

Organization and enterprise profiles

Interactive mode

Configure sandbox validation

Scale scanning

Choose a scan mode

Scan effort

Bulk scan an organization

Ingest existing findings

Auto Scan

Scan new commits

Start scans from Automations

Manage and monitor scans

Scan history

Change a scan’s profile

Security dashboard

Access and permissions

Compare Security Swarm with another scanner

FAQ