Devin Security Swarm Brings Context-Aware Code Scanning to Development Teams
Devin has launched Security Swarm, a code scanning tool that investigates vulnerabilities in the context of your repository rather than flagging risky patterns in isolation. The system traces data flows, checks for validation and authorization controls, and evaluates whether each issue has concrete security impact. Each finding includes a confidence level and supporting evidence so developers can review the reasoning before acting.
How Security Swarm Differs From Traditional Scanners
Most static analysis tools report pattern matches without understanding the surrounding code. Security Swarm takes a different approach. When Devin identifies a potential issue, it builds a threat model for your application, then investigates each signal by tracing how data moves through the codebase. The tool checks whether existing mitigations — input validation, authorization checks, encryption — actually block the exploit path. This contextual investigation distinguishes between vulnerabilities that are reachable in practice and those that remain theoretical concerns.
Running Your First Scan
To start a scan, your organization needs access to the target repository and you must have permission to use Devin sessions and the Use code scans role. Open Security in the left sidebar, click Start scan, and choose a repository under Single repo. You can optionally select a scan profile and effort level. Leaving the profile blank uses Security Swarm's built-in security scan. Interactive mode is enabled by default for first-time scans. After clicking Run Scan, Devin builds a proposed threat model and pauses. You review the model and either accept it with Looks good, start scanning or provide feedback to refine it. Findings then appear in real time, grouped by severity with live counts for Open, Reviewed, and Dismissed statuses.
Understanding Findings and Taking Action
Each finding displays severity, status, exploitability, confidence, and category alongside the affected file path and code snippets. The description includes a remediation recommendation. When sandbox validation is enabled, the finding shows validation results and supporting artifacts. Associated pull requests appear with their current state. You can assign a finding to Devin for remediation, which starts a session that opens a pull request tracked on the finding. You can also provide feedback to improve future scans or adjust the finding's classification.
Scan Profiles Control Scope and Guidance
A scan profile defines the scope and provides guidance for each stage of the scan. Every scan uses one profile. To evaluate against multiple attacker personas or threat categories, run separate scans with different profiles. You can create profiles in two ways: generate with Devin by describing the application, threats, scope, exclusions, and severity standards in natural language, or create manually by filling in each field.
Basic information includes a profile name that identifies the application surface or threat category — for example, Multi-tenant API authorization — and a description summarizing the scope and security objective. The threat model section describes 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.
Investigation guidance defines how Devin should investigate potential issues and what evidence to collect. Triage guidance specifies how to deduplicate and prioritize findings, including severity criteria that match your organization's standards. Sandbox validation can be enabled when Devin can safely build and exercise the application. You explain how to start the application, create test data, authenticate, and demonstrate the expected security boundary. The Validate severities setting chooses the lowest severity that triggers sandbox validation — by default critical, high, and medium findings are validated.
Report settings enable summary artifacts after the scan with specified audience and emphasis. Remediation guidance defines constraints for Devin when fixing findings, including testing expectations, compatibility requirements, and practices to avoid. Advanced inputs control file scope with include and exclude globs, and batch size for investigation batches (default 5, range 1–500).
Ingestion Profiles Import Existing Findings
Ingestion profiles import findings from other scanners or reports so you can triage, validate, and remediate them alongside Devin's own findings. Instead of scope and threat model inputs, ingestion profiles use two guidance fields: Ingestion source specifies where existing findings live and how Devin should fetch them — for example, fetching open alerts from GitHub code scanning through its REST API or reading a Semgrep report at a repository path. Credentials are referenced by organization secret name. Post-ingestion triage defines how Devin should handle imported findings: what to dismiss, reprioritize, or treat as duplicates.
Interactive Mode Lets You Review the Threat Model
With Interactive mode enabled, Devin builds a proposed threat model and pauses before investigation. The scan page displays the proposed rules so you can accept them or provide feedback describing what to add, remove, or emphasize. Devin then revises the model for your review. This mode is available for single-repo and multi-repo security scans and is enabled by default for single-repo scans when your organization has not run a scan yet.
Sandbox Validation Reproduces Findings in Isolation
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. An unsuccessful validation can identify assumptions or environment limitations that need further review. This feature requires the profile to have sandbox validation enabled with sufficient validation guidance for Devin to build, run, seed, and authenticate the application safely. If the repository has declarative configuration, Devin can reuse its build and installation setup.
Scan Effort and Bulk Scanning Options
Every scan runs at one of two effort levels. Normal (default) uses larger investigation batches for faster completion. Deep traces each finding further through the codebase for maximum thoroughness at higher cost and longer runtime. Bulk scan queues a separate scan for every matching repository with an optional repository name filter and profile selection. You can skip already-scanned repositories, preview the matching repositories, deselect any you don't want to scan, and confirm.
Auto Scan and Incremental Coverage
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, or from an existing scan by adding, editing, or disabling its schedule. Auto Scan requires automations to be enabled for your organization and both Manage code scans and permission to manage automations. Auto Scans are incremental — each run only investigates new commits. Clicking Start scan manually defaults to a full scan of the repository scope.
You can also click Scan new commits on a completed scan to investigate commits added since its last scanned commit. Each full or incremental run is recorded in the scan's scan history, showing whether it was a Full scan or Incremental, its status, effort level, profile, ACUs consumed, and a link to the Devin session.
Automations Enable Scheduled and Event-Driven Scans
Automations include a Code scan agent type for scans that 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. You choose between Start code scan, which runs a fresh scan of the configured repositories, type, profile, and effort each time the automation fires, and Scan new commits, which extends an existing scan with an incremental run covering commits added since its last completed run. The scan must already have a completed run for the incremental option.
Managing and Monitoring Scans
The scan header provides access to reports, usage metrics (ACUs consumed, session count, scan duration, pull request statistics), the main Devin session, scan history, profile changes, CSV export, archive options, and Scan new commits. Scan history shows every run newest first with details for comparing full and incremental run costs and confirming Auto Scan schedules. You can change a scan's profile on a completed scan — the new profile applies to future runs including Auto Scan and Scan new commits; completed runs and findings are unaffected.
Security Dashboard and Access Control
After the first completed scan, the Security page displays an organization-wide dashboard for the last 7, 30, or 90 days showing pull request statistics (created, merged, open, closed, and merge rate) and findings over time grouped by severity. Access is controlled through code scan permissions in the role editor. Starting scans, submitting feedback, and assigning findings to Devin require Devin session permission. Auto Scan additionally requires permission to manage automations. By default, members do not receive code scan permissions. Owners have all permissions, and administrators grant permissions through custom roles. The same permissions gate the Code Scans API, though API calls don't require session permission except for uploading scanner reports for ingestion scans.
Comparing Security Swarm With Other Scanners
For a meaningful comparison, give both scanners the same scope, threat model, severity criteria, and validation expectations. Configuration differences can otherwise obscure underlying capability differences. Use profiles to encode comparison criteria, interactive mode to confirm the generated threat model, and sandbox validation to apply the same standard of evidence to reported findings.
Common Questions About Security Swarm
Security Swarm reduces false positives by investigating potential vulnerabilities in repository context rather than reporting risky patterns in isolation. Devin traces relevant data flows, checks for validation and authorization controls, and evaluates concrete security impact. Each finding includes a confidence level and supporting evidence. Review that evidence before acting, especially for findings not validated in a sandbox.
When reviewing a finding, check the affected code, entry point, data flow, existing mitigations, stated impact, confidence, and exploitability. With sandbox validation enabled, also review the validation result and supporting artifacts. If evidence overlooks a control or claims an unsupported impact, use Feedback to provide missing context for future scans.
Sandbox validation reproduces findings by building and exercising the application in isolation. Successful validation strengthens exploitability evidence. Unsuccessful validation can reveal assumptions or environment limitations needing further review. Sandbox validation is optional and requires sufficient validation guidance for Devin to build, run, seed, and authenticate the application safely.