> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Swarm
> Use Devin Security Swarm to find, triage, and remediate security vulnerabilities across your repositories with code scans and automated fixes
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](https://devin.ai/blog/agentic-map-reduce). 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](https://devin.ai/blog/security-swarm-eval) against a ground-truth set of published vulnerabilities from the GitHub Advisory Database.
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](#access-and-permissions) for details.
## 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](#scan-profiles) and a [scan effort](#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](#interactive-mode) 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](#act-on-a-finding) that need attention.
The New Scan sheet offers other [scan modes](#choose-a-scan-mode) 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
Starts a Devin session to remediate the issue and open a pull request. The session and resulting pull request are tracked on the finding.
Sends context to a feedback session that refines the scan profile for future scans. For example, explain that a reported data flow is protected by an internal gateway so future scans can account for that control.
Overrides the finding's severity, with optional context for Devin. For example, lower the severity when exploitation requires privileged internal access, and include that constraint as context.
Marks the finding as Open, Reviewed, or Dismissed. Keep a finding Open while it needs action, mark it Reviewed after triage, or dismiss it when it is a false positive or duplicate.
## 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.
```text theme={null}
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.
```text theme={null}
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.
```text theme={null}
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.
```text theme={null}
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](#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.
```text theme={null}
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.
```text theme={null}
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](#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](/onboard-devin/environment/blueprints), 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](#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:
1. Optionally enter a **Repository name filter**.
2. Optionally select a scan profile.
3. Keep **Skip already-scanned repos** enabled to exclude repositories already scanned with the selected profile.
4. Click **Preview**.
5. 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:
1. Select one or more repositories the findings belong to.
2. Select an [ingestion profile](#ingestion-profiles). The profile tells Devin where the findings live and how to triage them after import.
3. 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.
4. Optionally enable **Interactive mode**. After importing, Devin pauses so you can review what was ingested, including possible duplicates, and request corrections before it continues.
5. Choose a [scan effort](#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](/api-reference/v3/code-scans/organizations-code-scans-start-ingestion).
### 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](/product-guides/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](#scan-history).
### Start scans from Automations
[Automations](/product-guides/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](/work-with-devin/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](#scan-history).
* **Change profile** — switch the profile used by future runs. See [Change a scan's profile](#change-a-scans-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](/admin/billing/usage). 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](/enterprise/security-access/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](/api-reference/v3/code-scans/organizations-code-scans-start), [start ingestion scans](/api-reference/v3/code-scans/organizations-code-scans-start-ingestion), and [remediate findings](/api-reference/v3/code-scans/organizations-code-scans-remediate); **View code scans** covers [listing scans](/api-reference/v3/code-scans/organizations-code-scans-list), [profiles](/api-reference/v3/code-scans/organizations-code-scans-profiles) and [their guidance](/api-reference/v3/code-scans/organizations-code-scans-profile), [findings](/api-reference/v3/code-scans/organizations-code-scans-findings), and [metrics](/api-reference/v3/code-scans/organizations-code-scans-metrics). See [Triggering Code Scans via the Devin API](/api-reference/v3/code-scans/triggering-code-scans) 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
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.
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](#act-on-a-finding) to provide the missing context for future scans.
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](#configure-sandbox-validation) for Devin to build, run, seed, and authenticate the application safely.
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.
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](#scan-profiles), use [interactive mode](#interactive-mode) to review the proposed threat model, and provide feedback when a result misses important context.
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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.