Wie findet und behebt Devin Sicherheitslücken im eigenen Code? Security Swarm, das Sicherheitsprodukt von Cognition, soll diese Frage beantworten. Das Werkzeug durchsucht ein Repository nach Schwachstellen, bewertet sie und schlägt Korrekturen vor. Der folgende Überblick fasst die Dokumentation des Herstellers zusammen: was der Scan leistet, wie man ihn bedient und wo die Grenzen liegen.
Was Security Swarm ist und wie Agentic MapReduce arbeitet
Security Swarm ist laut Devin Docs ein Produkt für Sicherheitsscans und deren Behebung. Es erstellt zuerst ein Bedrohungsmodell, das auf den konkreten Code zugeschnitten ist, untersucht dann potenzielle Schwachstellen und hilft, die Befunde über Pull Requests zu beheben. Erfasst werden unter anderem Remote Code Execution, SQL-Injection, Path Traversal, Server-Side Request Forgery, Authorization Bypasses, Memory-Safety-Fehler und Denial-of-Service. Auch verkettete Exploits über mehrere Dateien sollen erkannt werden.
Man kann sich das wie ein Ermittlerteam vorstellen, das ein großes Gebäude durchkämmt. Statt dass ein einzelner Prüfer jeden Raum abläuft, bekommt jeder Ermittler einen Trakt, und alle arbeiten parallel. Am Ende werden die Notizen zusammengeführt. Genau das ist der Kern der Schwachstellenanalyse in diesem System: nicht ein längerer Spaziergang, sondern viele gleichzeitige.
Das Verfahren nennt der Anbieter Agentic MapReduce. Das Repository wird unter parallelen Devin-Instanzen aufgeteilt, was breite Abdeckung bei tiefer Untersuchung erlaubt, ohne die Kosten aus dem Ruder laufen zu lassen. Laut Anbieter macht das den Scan auch großer Codebasen praktikabel. Nach eigenen Angaben hat Cognition Security Swarm gegen einen Referenzdatensatz veröffentlichter Schwachstellen aus der GitHub Advisory Database getestet; Ergebnisse nennt die Dokumentationsseite nicht.
Wer scannen darf: Rollen und Berechtigungen
Vor einem Lauf müssen die organisatorischen Voraussetzungen stimmen. Die Organisation braucht Zugriff auf das Repository, und die angemeldete Person muss Devin-Sitzungen nutzen dürfen. Verlangt wird außerdem die Berechtigung „Use code scans“. Für automatische Scans nach Zeitplan braucht man zusätzlich „Manage code scans“ und das Recht, Automatisierungen zu verwalten.
Fehlt der Eintrag „Security“ in der Seitenleiste oder lässt sich kein Scan starten, liegt das meist an der zugewiesenen Rolle. Ein Administrator sollte dann die Rechte prüfen und die Rolle anpassen.
Der erste Scan
Der erste Durchlauf folgt einer festen Reihenfolge. Man öffnet „Security“ in der linken Seitenleiste und klickt auf „Start scan“. Unter „Single repo“ wählt man ein Repository aus, optional ein Scan-Profil und einen Aufwandsgrad – bleibt das Profil leer, greift der Standardscan. Danach prüft man, ob der interaktive Modus aktiv ist, und startet den Lauf.
Sobald das vorgeschlagene Bedrohungsmodell fertig ist, wird es geprüft. Man bestätigt mit „Looks good, start scanning“ oder gibt Rückmeldung, woraufhin ein überarbeitetes Modell entsteht. Während der Untersuchung erscheinen nach und nach Befunde, die man einzeln bewertet und abarbeitet. Beim ersten Repository sollte man den interaktiven Modus eingeschaltet lassen. Er kostet einen Zwischenschritt, gibt aber die Gelegenheit, das Bedrohungsmodell zu korrigieren, bevor die Untersuchung beginnt. Dasselbe empfiehlt die Dokumentation, wenn sich Risikofläche oder Profil deutlich ändern.
Neben dem Einzelmodus bietet das Fenster für neue Scans weitere Varianten: mehrere Repositories gleichzeitig oder der Import von Befunden aus einem bestehenden Scanner. Sie sind weiter unten beschrieben.
Findings bewerten und Sicherheitslücken mit Pull Requests beheben
Ein geöffneter Scan zeigt links die Funde nach Schweregrad gruppiert und rechts die Details des ausgewählten Eintrags. Die Statusreiter zählen live mit: „Open“ braucht Aufmerksamkeit, „Reviewed“ ist gesichtet und braucht keine Aktion mehr, „Dismissed“ markiert Fehlalarm oder Dublette. Während der Scan läuft, aktualisiert sich die Seite automatisch, sobald neue Befunde eintreffen. Wichtig: „Reviewed“ ist ein Arbeitsstatus und keine Bestätigung, dass ein Fix zusammengeführt wurde.
Ein Finding enthält mehr als eine Zeile Warnung. Aufgeführt werden Schweregrad, Status, Ausnutzbarkeit, Konfidenz und Kategorie, dazu der betroffene Dateipfad mit Codeausschnitten. Dazu kommen eine Beschreibung des Problems, eine Empfehlung zur Behebung und das Ergebnis einer Sandbox-Validierung samt Belegen. Sind Pull Requests verknüpft, zeigt die Ansicht deren Zustand – offen, zusammengeführt oder geschlossen.
Aus einem Fund heraus gibt es drei Aktionen. „Assign to Devin“ startet eine Sitzung, die das Problem behebt und einen Pull Request öffnet; Sitzung und Pull Request bleiben am Finding verfolgbar. „Feedback“ schickt Kontext an eine Sitzung, die das Scan-Profil für künftige Läufe schärft – etwa der Hinweis, dass ein gemeldeter Datenfluss durch ein internes Gateway geschützt ist. „Adjust Status“ stuft den Schweregrad neu ein, optional mit Begründung, und markiert einen Fund als offen, geprüft oder verworfen. Wer Lücken beheben statt nur sammeln will, arbeitet an dieser Stelle.
Scan-Profile: von der Bedrohung bis zur Validierung
Ein Scan-Profil steuert den Umfang des Laufs und gibt für jede Phase Anweisungen. Jeder Scan nutzt genau ein Profil; um ein Repository gegen mehrere Angreifertypen zu prüfen, startet man mehrere Läufe mit unterschiedlichen Profilen. Verwaltet werden sie im Reiter „Profiles“ der Security-Seite.
Ein Profil lässt sich auf zwei Wegen anlegen. Bei „Generate with Devin“ beschreibt man Anwendung, Bedrohungen, Umfang, Ausschlüsse und Schweregrad-Standards in natürlicher Sprache, und Devin entwirft das Profil. Alternativ füllt man jedes Feld manuell aus. Der generierte Entwurf ist ein brauchbarer Startpunkt, aber jedes Feld sollte vor der Nutzung geprüft werden. Bleibt ein optionales Feld leer, greift das eingebaute Standardverhalten.
Ein Profil deckt mehrere Stationen ab. Das Bedrohungsmodell beschreibt Angreifer, schützenswerte Werte, Vertrauensgrenzen und Einstiegspunkte. Die Untersuchungsanleitung legt fest, wie Devin ein Problem verfolgt und welche Belege es sammelt, inklusive bestehender Schutzmaßnahmen. Die Triage-Anleitung bestimmt, wie Funde dedupliziert und priorisiert werden. Optional lässt sich die Sandbox-Validierung aktivieren, die für jeden Fund ab einem einstellbaren Schweregrad (standardmäßig kritisch, hoch und mittel) eine eigene Sitzung startet und prüft, ob sich die Lücke tatsächlich ausnutzen lässt. Dafür braucht das Profil Anweisungen, wie die Anwendung gebaut, gestartet und mit Testdaten bestückt wird. Und eine gescheiterte Validierung widerlegt einen Fund nicht unbedingt. Für die Behebung kann das Profil außerdem Vorgaben machen, etwa kleinste sichere Änderung, Regressionstest und keine großen Abhängigkeits-Upgrades. Über erweiterte Eingaben steuert man Dateimuster und die Batch-Größe, die zwischen einem und 500 Dateien liegt und standardmäßig bei fünf steht.
Ingest-Profile bilden den zweiten Modus und eignen sich, wenn bereits Befunde aus anderen Werkzeugen vorliegen. Statt Code zu analysieren, importieren sie Ergebnisse und ersetzen die Scope- und Bedrohungsfelder durch zwei Angaben: die Ingestion-Quelle und die Triage nach dem Import. So lassen sich offene Alarme aus dem GitHub Code Scanning per REST-Schnittstelle holen oder ein Semgrep-Bericht einlesen. Zugangsdaten gehören dabei als Organisationsgeheimnis referenziert, nicht als eingefügter Token. Neue Profile gelten organisationsweit; Enterprise-Administratoren können die Sichtbarkeit später auf das gesamte Unternehmen ausweiten.
Skalierung: Scan-Modi, Aufwand und Kostenrahmen
Für größere Vorhaben bietet das Fenster für neue Scans vier Modi. „Single repo“ prüft ein einzelnes Repository, „Multi-repo“ analysiert bis zu 200 Repositories gemeinsam, sodass auch Fehler über Repositoriumgrenzen hinweg auffallen. „Bulk scan“ startet für jedes passende Repository einen eigenen, unabhängigen Lauf, während „Ingest findings“ bestehende Ergebnisse importiert. Der Bulk-Modus erlaubt eine Filterung nach Repository-Namen und überspringt auf Wunsch bereits gescannte Repositories; die Vorschau ist ein Probelauf und wird ungültig, sobald man Filter oder Profil ändert.
Beim Aufwand gibt es zwei Stufen. „Normal“ ist der Standard: schneller, mit größeren Untersuchungsstapeln. „Deep“ verfolgt jeden Fund weiter durch die Codebasis, kostet mehr und dauert länger. Für Routine- und inkrementelle Scans reicht Normal; ein erster Lauf über eine risikoreiche Codebasis oder eine periodische Tiefenprüfung spricht für Deep. Welcher Aufwand verwendet wurde, steht anschließend im Kopf des Scans.
Bezahlt wird nicht pro Scan, sondern über Rechenzeit: Scans laufen als Devin-Sitzungen und verbrauchen ACUs, die der Kopf jedes Scans samt Dauer und Pull-Request-Statistik ausweist. Günstiger wird es mit Auto Scan, der täglich, wöchentlich oder monatlich nur die Commits seit dem letzten abgeschlossenen Lauf untersucht; dasselbe leistet „Scan new commits“ von Hand. Wer Cognitions Agenten schon kennt, findet hier dieselbe Sitzungslogik wie beim Lernen aus vergangenen Sitzungen.
Security Swarm ersetzt kein Sicherheitsteam, sondern verstärkt es dort, wo Arbeit sonst liegen bleibt. Das Werkzeug durchsucht, validiert und schlägt Korrekturen vor; die Entscheidung, was ein Risiko ist und was nicht, bleibt beim Menschen. Auch die Dokumentation sagt deutlich: Kein Scanner garantiert vollständige Abdeckung, und weil die Analyse agentisch läuft, können zwei Scans unterschiedliche Funde liefern. Ein klar umrissenes Profil und der interaktive Modus für die ersten Läufe machen die Ergebnisse vergleichbarer. Wer ihn einmalig laufen lässt und die Findings ignoriert, hat vor allem ein gutes Gefühl gekauft.
Quelle: docs.devin.ai
