Security Swarm - Devin Docs

Security Swarm ist Devins Produkt für Sicherheitsscans und Fehlerbehebung. Es erstellt ein auf Ihren Code zugeschnittenes Bedrohungsmodell, untersucht und validiert potenzielle Schwachstellen und hilft Ihnen, Befunde mithilfe von Pull Requests zu beheben. Es kann Schwachstellen wie Remote-Code-Ausführung (RCE), SQL-Injection, Path Traversal, Server-Side Request Forgery (SSRF), Autorisierungsumgehungen, Speichersicherheitsfehler, Denial-of-Service-Schwachstellen und mehr identifizieren. Es kann sogar Exploit-Ketten erkennen, die sich über mehrere Dateien erstrecken. Security Swarm ist eine speziell angepasste Orchestrierung von Devins, die wir Agentic MapReduce nennen. Es teilt Ihr Repo auf parallel arbeitende Devins auf und bietet so breite Abdeckung und tiefgehende Untersuchungen bei kalkulierbaren Kosten, sodass sich auch große Codebasen kosteneffizient scannen lassen. Außerdem haben wir Security Swarm evaluiert anhand eines Ground-Truth-Datensatzes veröffentlichter Schwachstellen aus der GitHub Advisory Database.

Voraussetzungen

Um einen Scan auszuführen:

Ihre Organisation muss Zugriff auf das Repository haben, das Sie scannen möchten.
Sie müssen berechtigt sein, Devin-Sitzungen zu verwenden.
Sie benötigen die Berechtigung Code-Scans verwenden.
Um einen Auto-Scan-Zeitplan zu konfigurieren, benötigen Sie außerdem Code-Scans verwalten sowie die Berechtigung, Automatisierungen zu verwalten.

Wenn Sie Security nicht in der Sidebar sehen oder keinen Scan starten können, bitten Sie einen Administrator, Ihre Rolle zu überprüfen. Weitere Informationen finden Sie unter Zugriff und Berechtigungen.

Führen Sie Ihren ersten Scan aus

Öffnen Sie Security in der linken Sidebar und klicken Sie auf Scan starten.
Wählen Sie unter Einzelnes Repo ein Repository aus, das gescannt werden soll.
Wählen Sie optional ein Scan-Profil und einen Scan-Aufwand aus. Wenn Sie das Profil leer lassen, wird der integrierte Sicherheitsscan von Security Swarm verwendet.
Stellen Sie sicher, dass Interaktiver Modus aktiviert ist.
Klicken Sie auf Scan ausführen.
Wenn das vorgeschlagene Bedrohungsmodell bereit ist, überprüfen Sie es und klicken Sie entweder auf Sieht gut aus – Scan starten oder geben Sie Feedback.
Sobald Befunde erscheinen, prüfen Sie die Belege und gehen Sie die Befunde an, die Aufmerksamkeit erfordern.

Das Fenster „Neuer Scan“ bietet weitere Scan-Modi, um mehrere Repositorys gleichzeitig zu scannen oder Befunde aus einem vorhandenen Scanner zu importieren.

Erstellen eines Scan-Profils, Ausführen eines interaktiven Scans und Überprüfen der Befunde in Security Swarm

Erstellen Sie für wiederholbare Scans ein Profil, das Ihren Geltungsbereich, Ihr Bedrohungsmodell, Ihre Schweregradkriterien, Validierungsschritte und Einschränkungen für die Fehlerbehebung festhält.

Befunde überprüfen und darauf reagieren

Öffnen Sie einen Scan, um die zugehörigen Befunde anzuzeigen. Die Seite zeigt links eine Liste der Befunde, nach Schweregrad gruppiert, und rechts die Details des ausgewählten Befunds. Die Status-Tabs zeigen eine aktuelle Anzahl:

Open — erfordert Aufmerksamkeit.
Reviewed — wurde überprüft und erfordert keine weitere Aktion.
Dismissed — wurde als Fehlalarm oder Duplikat eingestuft.

Während ein Scan läuft, wird die Seite automatisch aktualisiert, sobald neue Befunde eingehen.

Reviewed ist ein Workflow-Status und keine Bestätigung dafür, dass eine Fehlerbehebung zusammengeführt wurde. Ein Befund kann manuell als Reviewed markiert werden oder wenn ein späterer Scan feststellt, dass er nicht mehr vorhanden ist.

Was ein Befund enthält

Ein Befund umfasst:

Schweregrad, Status, Ausnutzbarkeit, Konfidenzniveau und Kategorie.
Den betroffenen Dateipfad und die zugehörigen Codeausschnitte.
Eine Beschreibung des Problems und eine Empfehlung zur Fehlerbehebung.
Ein Ergebnis der Sandbox-Validierung, unterstützende Belege und Validierungsartefakte.
Zugehörige Pull Requests und ihren Status: offen, zusammengeführt oder geschlossen.
Code-Owner und Hinweise, sofern verfügbar.

Betrachten Sie ein riskantes Codemuster als einen Hinweis, nicht als Beleg für eine Schwachstelle. Prüfen Sie, ob der Befund einen erreichbaren Pfad von angreifergesteuerten Eingaben nachverfolgt, Validierungs- und Autorisierungskontrollen berücksichtigt und konkrete Sicherheitsauswirkungen erläutert.

Auf einen Befund reagieren

Devin zuweisen
Feedback
Anpassen
Statusmenü

Startet eine Devin-Sitzung, um das Problem zu beheben und einen Pull Request zu erstellen. Die Sitzung und der daraus resultierende Pull Request werden im Befund erfasst.

Scan-Profile

Ein Scan-Profil steuert den Geltungsbereich des Scans und gibt für jede Phase des Scans Hinweise vor. Jeder Scan kann ein Profil verwenden. Um ein Repository anhand mehrerer Angreiferprofile oder Bedrohungskategorien zu bewerten, führen Sie separate Scans mit unterschiedlichen Profilen aus.

Ein spezifisches Bedrohungsmodell ist eine der effektivsten Möglichkeiten, die Abdeckung über mehrere Scans hinweg konsistent zu halten. Definieren Sie den Angreifer, sensible Assets, Vertrauensgrenzen, wichtige Einstiegspunkte und explizite Ausschlüsse.

Verwalten Sie Profile über den Tab Profiles auf der Seite Security.

Ein Profil erstellen

Sie können ein Profil auf zwei Arten erstellen:

Mit Devin erzeugen — beschreiben Sie die Anwendung, Bedrohungen, den Geltungsbereich, Ausschlüsse und Standards für Schweregrade in natürlicher Sprache. Devin erstellt daraus einen Profilentwurf für Sie.
Manuell erstellen — füllen Sie jedes Eingabefeld des Profils selbst aus.

Das Erzeugen mit Devin ist ein nützlicher Ausgangspunkt, aber prüfen Sie jedes erzeugte Feld, bevor Sie das Profil verwenden. Wenn Sie ein optionales Hinweisfeld leer lassen, gilt für diese Phase das integrierte Verhalten von Security Swarm.

Grundlegende Informationen

Profilname — benennen Sie den Anwendungsbereich oder die Bedrohungskategorie, nicht das Team, das den Scan durchführt. Beispiel: Mandantenfähige API-Autorisierung.
Beschreibung — fassen Sie den Geltungsbereich und das Sicherheitsziel des Profils zusammen. Beispiel: Schwachstellen bei Authentifizierung, Autorisierung und Mandantenisolation in der öffentlichen API finden.

Die folgenden Beispiele ergeben zusammen ein einzelnes Profil für eine mandantenfähige API. Passen Sie Abgrenzung, Befehle und Schweregradstandards an Ihre Anwendung an.

Bedrohungsmodell

Beschreiben Sie den Angreifer, sensible Assets, Vertrauensgrenzen, wichtige Eintrittspunkte und alles, was ausdrücklich außerhalb des Geltungsbereichs liegt. Diese Hinweise bestimmen die Regeln, die Devin generiert, bevor die Untersuchung beginnt.

Gehen Sie von einem nicht authentifizierten Internetangreifer oder einem authentifizierten Nutzer in einem Tenant aus.
Konzentrieren Sie sich auf öffentliche HTTP-Handler, OAuth-Callbacks, API-Token, administrative Aktionen
und Zugriffe auf Tenant-eigene Daten. Betrachten Sie interne Entwicklungsskripte und rein lokale
Tools als außerhalb des Geltungsbereichs. Priorisieren Sie Authentifizierungs-Bypasses, mandantenübergreifende Zugriffe, Token-Leakage,
Injection und SSRF.

Hinweise zur Untersuchung

Definieren Sie, wie Devin ein potenzielles Problem untersuchen und welche Belege es sammeln soll. Fordern Sie Devin auf, vorhandene Gegenmaßnahmen einzubeziehen und tatsächlich ausnutzbare Schwachstellen von rein theoretischen Bedenken zu unterscheiden.

Verfolge nicht vertrauenswürdige Eingaben von der Route durch Middleware- und Service-Schichten bis zur
sensiblen Operation. Überprüfe Authentifizierung, Autorisierung, Tenant-Scoping, Validierung
und Escaping an jeder Grenze. Identifiziere den genauen erreichbaren Pfad und nenne die relevanten
Dateien und Zeilen. Melde kein theoretisches Problem, wenn eine wirksame Gegenmaßnahme den
Pfad blockiert.

Triage-Leitfaden

Definieren Sie, wie Devin Befunde deduplizieren und priorisieren soll. Geben Sie Ihre Schweregradkriterien an, damit die Ergebnisse den Standards Ihrer Organisation entsprechen.

Befunde mit derselben Grundursache zusammenfassen. Nicht authentifizierte Remote-Code-Ausführung und mandantenübergreifenden Schreibzugriff als kritisch einstufen. Mandantenübergreifenden Lesezugriff und Offenlegung von Zugangsdaten als hoch einstufen. Verfügbarkeitsprobleme einzelner Nutzer als mittel einstufen, sofern sie keine gemeinsam genutzte Infrastruktur beeinträchtigen können. Defense-in-Depth-Empfehlungen als niedrig kennzeichnen.

Sandbox-Validierung

Aktivieren Sie die Sandbox-Validierung, wenn Devin die Anwendung sicher bauen und testen kann. Erläutern Sie, wie die Anwendung gestartet wird, Testdaten erstellt werden, die Authentifizierung funktioniert und die erwartete Sicherheitsgrenze demonstriert wird. Mit Validate severities wählen Sie die niedrigste Severity aus, die Devin in einer Sandbox validiert. Nur Befunde ab dieser Severity starten eine Validierungssitzung; standardmäßig werden Befunde der Stufen kritisch, hoch und mittel validiert. Setzen Sie den Schwellenwert auf kritisch oder hoch, um den Validierungsaufwand nur für die wichtigsten Befunde einzusetzen.

Verwende das im Repo dokumentierte Entwicklungs-Setup. Starte die API und erstelle zwei
Nicht-Produktiv-Tenants mit je einem Test-Nutzer. Sende den vermuteten Request als
Nutzer des anderen Tenants und überprüfe anschließend sowohl die HTTP-Antwort als auch die persistierten Daten.
Rufe keine Produktionsdienste auf und ändere keine Produktionsdaten.

Eine fehlgeschlagene Validierung widerlegt einen Befund nicht immer. Prüfen Sie das Validierungsergebnis und die Artefakte, um festzustellen, ob eine wirksame Gegenmaßnahme den Exploit blockiert hat oder die konfigurierte Umgebung Devin daran gehindert hat, den Test abzuschließen.

Die Sandbox-Validierung startet für jeden Befund eine separate Devin-Sitzung. Hinweise zur Umgebung finden Sie unter Sandbox-Validierung konfigurieren.

Bericht

Aktivieren Sie Berichte, wenn Sie nach dem Scan ein Artefakt mit einer Zusammenfassung benötigen. Geben Sie die vorgesehene Zielgruppe und die Informationen an, die der Bericht hervorheben soll.

Erstelle eine Zusammenfassung für Sicherheits- und Engineering-Leads. Liste zunächst bestätigte kritische und schwerwiegende Befunde auf, gefolgt von nicht validierten Befunden. Gib betroffene Komponenten, den Validierungsstatus, den Pull-Request-Status und einen priorisierten Fehlerbehebungsplan an.

Hinweise zur Fehlerbehebung

Legen Sie Vorgaben fest, die Devin befolgen soll, wenn Sie ihm die Behebung eines Befunds zuweisen. Geben Sie dabei Testerwartungen, Kompatibilitätsanforderungen und zu vermeidende Vorgehensweisen an.

Bevorzuge die kleinstmögliche sichere Änderung und bewahre das bestehende Verhalten der öffentlichen API. Füge einen
Regressionstest hinzu, der vor dem Fix fehlschlägt und danach erfolgreich ist. Führe die Lint- und Testbefehle des betroffenen Pakets
aus. Vermeide größere Dependency-Upgrades, es sei denn, die Schwachstelle lässt sich ohne ein solches nicht sicher beheben.

Erweiterte Optionen

Öffnen Sie Advanced, um den Datei-Geltungsbereich und Untersuchungs-Batches zu steuern:

Include globs — beschränkt den Scan auf passende Dateien. Zum Beispiel apps/api/** und packages/auth/**.
Exclude globs — entfernt irrelevante Dateien aus dem ausgewählten Geltungsbereich. Zum Beispiel **/generated/**, **/vendor/** und **/fixtures/**.
Batch size — steuert, wie viele Dateien mit Signalen in jedem Untersuchungs-Batch gruppiert werden. Belassen Sie diese Einstellung auf dem Standardwert, sofern Sie das Scan-Verhalten nicht gezielt anpassen. Der zulässige Bereich ist 1–500; der Standardwert ist 5.

Zu weit gefasste Ausschlüsse können verwundbaren Code verbergen oder Kontext entfernen, der nötig ist, um einen Datenfluss zu verstehen. Schließen Sie nur Dateien aus, bei denen Sie sicher sind, dass sie für das Profil irrelevant sind.

Ingestion-Profile

Der Modus eines Profils wird beim Erstellen festgelegt und ist danach unveränderlich. Discover-Profile (der Standard) analysieren deinen Code, um neue Issues zu finden, und nutzen die oben beschriebenen Guidance-Felder. Ingest-Profile importieren Befunde, die dir bereits aus einem anderen Scanner oder Bericht vorliegen, und ersetzen die Eingaben für Geltungsbereich und Threat Model durch zwei Guidance-Felder:

Ingestion source — wo die vorhandenen Befunde liegen und wie Devin sie abrufen soll. Zum Beispiel offene Alerts aus GitHub Code Scanning über dessen REST-API abrufen oder einen Semgrep-Bericht auslesen, der unter reports/semgrep.json committet ist. Verweise auf Credentials über den Namen des Organisations-Secrets, statt ein Token direkt einzufügen.
Post-ingestion triage — wie Devin die importierten Befunde triagieren soll: was verworfen, was neu priorisiert und was als Duplikat behandelt werden soll. Zum Beispiel Befunde in Test-Fixtures verwerfen und Befunde mit derselben Rule-ID und derselben Datei als Duplikate behandeln.

Unter Vorhandene Befunde ingesten erfährst du, wie du einen Scan mit einem Ingestion-Profil ausführst. Der Tab Profiles lässt sich nach Scan-Typ und nach Modus (Discover oder Ingest) filtern.

Organisations- und Enterprise-Profile

Neue Profile sind auf den Org-Geltungsbereich begrenzt. Enterprise-Admins können die Sichtbarkeit eines Profils später auf Enterprise ändern und es so im gesamten Enterprise verfügbar machen. Enterprise-Profile können nur von Enterprise-Admins bearbeitet oder archiviert werden. Andere Nutzer mit Zugriff auf Security können sie einsehen und verwenden, aber nicht ändern.

Interaktiver Modus

Wenn Interaktiver Modus aktiviert ist, erstellt Devin ein vorgeschlagenes Bedrohungsmodell und hält vor der Untersuchung an. Die Scan-Seite zeigt die vorgeschlagenen Regeln an. Sie können dann:

Sieht gut aus, Scan starten — das Bedrohungsmodell übernehmen und die Untersuchung starten.
Feedback zum Bedrohungsmodell geben — beschreiben Sie, was hinzugefügt, entfernt oder stärker hervorgehoben werden soll, und prüfen Sie dann das überarbeitete Modell.

Verwenden Sie den interaktiven Modus beim ersten Scan eines Repositorys und immer dann, wenn sich dessen Risikolage oder Profil wesentlich ändert. Sobald das Profil die freigegebenen Vorgaben abbildet, können Routine-Scans ohne diese Pause ausgeführt werden.

Sandbox-Validierung konfigurieren

Die Sandbox-Validierung wird nur ausgeführt, wenn für das ausgewählte Profil die Sandbox-Validierung aktiviert ist und es Validierungshinweise enthält. Geben Sie Devin genügend Informationen, damit die Anwendung in seiner Sandbox gebaut, ausgeführt, mit Seed-Daten befüllt und authentifiziert werden kann. Wenn das Repository über eine deklarative Konfiguration verfügt, kann Devin das vorhandene Build- und Installations-Setup wiederverwenden. Andernfalls fügen Sie die erforderlichen Setup-Befehle zu den Validierungshinweisen des Profils hinzu.

Hinterlegen Sie Produktionszugangsdaten oder Secret-Werte nicht direkt in den Profilhinweisen. Verwenden Sie stattdessen Testkonten und Zugangsdaten außerhalb der Produktion, die bereits über die Umgebungskonfiguration Ihrer Organisation bereitgestellt werden.

Scanning skalieren

Einen Scan-Modus wählen

Das Fenster „New Scan“ bietet vier Scan-Modi:

Modus	Funktion	Am besten geeignet für
Single repo	Ein Scan eines einzelnen Repositorys.	Einen gezielten Scan einer einzelnen Codebase.
Multi-repo	Ein Scan über bis zu 200 Repositorys, die Devin gemeinsam analysiert.	Microservices oder Repositorys, die sich gegenseitig aufrufen – so erkennt Devin auch Probleme, die sich über Repository-Grenzen hinweg erstrecken. Befunde lassen sich nach Repository filtern.
Bulk scan	Ein separater, unabhängiger Scan für jedes passende Repository.	Eine ganze Organisation auf einmal abzudecken. Die Repositorys werden dabei nicht gemeinsam analysiert.
Ingest findings	Importiert Befunde aus Ihren bestehenden Tools oder Berichten, anstatt neue zu ermitteln.	Ergebnisse aus einem anderen Scanner für Triage und Fehlerbehebung nach Devin zu übernehmen. Siehe Bestehende Befunde importieren.

Der Interactive mode steht für Single-Repo- und Multi-Repo-Sicherheitsscans zur Verfügung. Bei einem Single-Repo-Scan ist er standardmäßig aktiviert, solange Ihre Organisation noch keinen Scan durchgeführt hat.

Scan-Aufwand

Jeder Scan läuft auf einer von zwei Aufwandsstufen, die beim Start unter Scan effort ausgewählt wird:

Normal (Standard) — ein schnellerer Scan, der größere Investigation-Batches verwendet.
Deep — verfolgt jedes Finding für maximale Gründlichkeit weiter durch die Codebase, bei höheren Kosten und längerer Laufzeit.

Verwende Normal für routinemäßige und inkrementelle Scans und Deep für den ersten Scan einer risikoreichen Codebase oder ein regelmäßiges, tiefgehendes Review. Mit welchem Aufwand ein abgeschlossener Scan gelaufen ist, wird in dessen Header angezeigt.

Massenscan einer Organisation

Verwenden Sie im Bereich Neuer Scan die Option Massenscan, um für jedes gefundene Repository einen separaten Scan in die Warteschlange zu stellen:

Geben Sie optional einen Filter für Repository-Namen ein.
Wählen Sie optional ein Scan-Profil aus.
Lassen Sie Bereits gescannte Repos überspringen aktiviert, um Repositories auszuschließen, die bereits mit dem ausgewählten Profil gescannt wurden.
Klicken Sie auf Preview.
Prüfen Sie die gefundenen Repositories, wählen Sie alle ab, die Sie nicht scannen möchten, und bestätigen Sie.

Die Vorschau ist ein Probelauf. Wenn Sie den Filter, das Profil oder die Einstellung zum Überspringen ändern, wird die Vorschau ungültig, sodass Sie keine veraltete Liste bestätigen können.

Vorhandene Befunde einlesen

Verwenden Sie Ingest findings, um Ergebnisse eines anderen Scanners in Security Swarm zu übernehmen und sie dort gemeinsam mit Devins eigenen Befunden zu triagieren, zu validieren und zu beheben:

Wählen Sie ein oder mehrere Repositorys aus, zu denen die Befunde gehören.
Wählen Sie ein Ingestion-Profil aus. Das Profil gibt Devin vor, wo die Befunde liegen und wie sie nach dem Import triagiert werden sollen.
Hängen Sie optional bis zu 10 Berichte oder Exporte an (zum Beispiel SARIF-, CSV- oder PDF-Dateien), aus denen Devin die Befunde auslesen soll. Wenn die Ingestion-Quelle des Profils bereits auf eine API oder eine Datei im Repository verweist, ist kein Anhang erforderlich.
Aktivieren Sie optional den Interactive mode. Nach dem Import pausiert Devin, damit Sie prüfen können, was eingelesen wurde – einschließlich möglicher Duplikate – und Korrekturen anfordern können, bevor Devin fortfährt.
Wählen Sie einen Scan-Aufwand und klicken Sie auf Run Scan.

Importierte Befunde erscheinen auf der Scan-Seite wie jeder andere Befund, sodass Sie sie Devin zuweisen, anpassen oder ihren Status ändern können. Die Liste der Scans lässt sich nach Modus filtern, sodass nur Discover- oder nur Ingest-Scans angezeigt werden.

Das Hochladen von Anhängen läuft über die attachments API, daher erfordert das Einlesen aus hochgeladenen Dateien ebenfalls Use Devin sessions. Ingestion-Scans lassen sich auch über die API starten.

Auto Scan

Auto Scan prüft regelmäßig Commits, die seit dem letzten abgeschlossenen Scan hinzugekommen sind. Sie können ihn wie folgt konfigurieren:

Beim Starten eines Scans für ein einzelnes Repository, indem Sie einen täglichen, wöchentlichen, monatlichen oder benutzerdefinierten Zeitplan auswählen.
In einem vorhandenen Scan, indem Sie den Zeitplan hinzufügen, bearbeiten oder deaktivieren oder auf Jetzt scannen klicken, um ihn sofort auszuführen.

Die Zeitangaben im Zeitplan werden in Ihrer lokalen Zeitzone angezeigt.

Auto Scan ist nur verfügbar, wenn Automatisierungen für Ihre Organisation aktiviert sind. Für die Konfiguration sind sowohl Code-Scans verwalten als auch die Berechtigung zum Verwalten von Automatisierungen erforderlich.

Auto Scans sind inkrementell: Bei jedem Durchlauf werden nur die Commits untersucht, die seit dem letzten abgeschlossenen Scan hinzugekommen sind. Wenn Sie stattdessen auf Scan starten klicken, wird standardmäßig ein vollständiger Scan des Repository-Geltungsbereichs ausgeführt.

Neue Commits scannen

Klicken Sie bei einem abgeschlossenen Scan auf Neue Commits scannen, um Commits zu untersuchen, die seit dem zuletzt gescannten Commit hinzugekommen sind. Auto Scan verwendet dasselbe inkrementelle Verhalten, sodass nachfolgende Scans kostengünstiger sind, als den gesamten Geltungsbereich des Repositorys wiederholt zu scannen. Jeder vollständige oder inkrementelle Durchlauf wird im Scan-Verlauf des Scans festgehalten.

Scans über Automatisierungen starten

Automatisierungen bieten den Agent-Typ Code-Scan für Scans, die nach einem Zeitplan oder als Reaktion auf ein Ereignis laufen sollen. Statt eine Devin-Sitzung mit einem Prompt zu starten, startet die Automatisierung den Scan direkt. Wählen Sie eine von zwei Aktionen:

Start code scan — startet bei jedem Auslösen der Automatisierung einen neuen Scan des bzw. der konfigurierten Repositorys mit dem festgelegten Scan-Typ, Profil und Aufwand.
Neue Commits scannen — erweitert einen bestehenden Scan um einen inkrementellen Durchlauf, der die seit dem letzten abgeschlossenen Durchlauf hinzugefügten Commits abdeckt. Für den Scan muss bereits ein abgeschlossener Durchlauf vorliegen.

Auto Scan ist eine vorkonfigurierte Automatisierung der zweiten Art. Nutzen Sie die Seite „Automatisierungen“, wenn Sie andere Trigger wie etwa einen Webhook verwenden oder alle geplanten Scans zentral verwalten möchten. Sie können einen Scan auch im Composer einer Sitzung mit dem Befehl /scan starten. Für Scans zu Performance, Testabdeckung, totem Code und andere nicht sicherheitsbezogene Scans siehe Code Scans.

Scans verwalten und überwachen

Je nach Scan und Profil kann die Scan-Kopfzeile Folgendes enthalten:

Berichte — für den Scan generierte Berichte herunterladen.
Verbrauch — verbrauchte ACUs, Anzahl der Sitzungen, Scandauer und Pull-Request-Statistiken anzeigen.
Sitzung — die Devin-Hauptsitzung öffnen, die den Scan ausgeführt hat.
Scan-Verlauf — jeden Durchlauf des Scans anzeigen. Siehe Scan-Verlauf.
Profil wechseln — das Profil für künftige Durchläufe ändern. Siehe Profil eines Scans ändern.
Als CSV exportieren — die Befunde des Scans exportieren.
Archivieren oder Dearchivieren — den Scan aus der Standardliste ausblenden oder dorthin zurückverschieben.
Neue Commits scannen — einen inkrementellen Scan starten.

Scans werden als Devin-Sitzungen ausgeführt und verbrauchen ACUs. Die Scan-Liste auf der Seite „Security“ lässt sich nach Status, Pull-Request-Zustand und Scan-Modus (Discover oder Ingest) filtern.

Scan-Verlauf

Öffnen Sie den Scan-Verlauf eines Scans, um alle bisherigen Durchläufe zu sehen – der neueste zuerst. Zu jedem Durchlauf wird angezeigt, ob es ein Full scan oder ein Incremental war, welchen Status er hat, welcher Aufwand und welches Profil verwendet wurden, wie viele ACUs verbraucht wurden und ein Link zur zugehörigen Devin-Sitzung. So prüfen Sie, ob Auto Scan wie geplant läuft, und vergleichen die Kosten von vollständigen und inkrementellen Durchläufen.

Profil eines Scans ändern

Klicken Sie bei einem abgeschlossenen Scan auf Change profile, um ein anderes Profil auszuwählen. Das neue Profil gilt für künftige Durchläufe des Scans, einschließlich Auto Scan und Scan new commits; bereits abgeschlossene Durchläufe und deren Befunde bleiben unverändert. Solange ein Scan läuft, lässt sich das Profil nicht ändern. Zum Ändern eines Profils ist die Berechtigung Use code scans erforderlich.

Security-Dashboard

Sobald die Organisation ihren ersten Scan abgeschlossen hat, zeigt die Seite Security ein organisationsweites Dashboard für die vergangenen 7, 30 oder 90 Tage:

Pull-Request-Statistiken — erstellte, zusammengeführte, offene und geschlossene Pull Requests sowie die Merge-Rate.
Befunde im Zeitverlauf — nach Schweregrad gruppierte Befunde im ausgewählten Zeitraum.

Zugriff und Berechtigungen

Der Zugriff auf Security wird im Rollen-Editor über Berechtigungen für Code-Scans gesteuert:

Berechtigung	Dadurch möglich	Standardrollen
Code-Scans anzeigen	Scans, Profile, Befunde und zugehörige Scan-Sitzungen anzeigen.	Admin
Code-Scans verwenden	Scans starten, Organisationsprofile erstellen, Feedback zu Befunden geben, Befunde anpassen, den Status von Befunden ändern und Befunde Devin zuweisen.	Admin
Code-Scans verwalten	Scans archivieren oder dearchivieren und Zeitpläne für Auto Scan konfigurieren.	Admin
Code-Scans des Accounts verwalten	Organisationsprofile in den Enterprise-Geltungsbereich hochstufen sowie Enterprise-Profile bearbeiten oder archivieren.	Enterprise-Admin

Zum Starten von Scans, Geben von Feedback und Zuweisen von Befunden an Devin ist außerdem die Berechtigung zum Verwenden von Devin-Sitzungen erforderlich. Auto Scan erfordert zusätzlich die Berechtigung zum Verwalten von Automatisierungen. Standardmäßig erhalten Member keine Berechtigungen für Code-Scans. Owner haben alle Berechtigungen, und Administratoren können Membern über benutzerdefinierte Rollen Berechtigungen erteilen. Dieselben Berechtigungen für Code-Scans gelten auch für die Code-Scans-API (API-Aufrufe erfordern keine zusätzliche Sitzungsberechtigung; lediglich das Hochladen von Scanner-Berichten für Ingestion-Scans erfolgt über die Attachments API, die Devin-Sitzungen verwenden erfordert). Service-Benutzer oder Personal Access Tokens mit Code-Scans verwenden können Scans starten, Ingestion-Scans starten und Befunde beheben; Code-Scans anzeigen umfasst das Auflisten von Scans, Profilen und deren Anleitungen, Befunden und Metriken. Den vollständigen Ablauf finden Sie unter Code-Scans über die Devin API auslösen.

Vergleichen Sie Security Swarm mit einem anderen Scanner

Für einen aussagekräftigen Vergleich sollten Sie beiden Scannern denselben Geltungsbereich, dasselbe Bedrohungsmodell, dieselben Schweregradkriterien und dieselben Validierungserwartungen vorgeben. Unterschiede in der Konfiguration können sonst Unterschiede in der zugrunde liegenden Leistungsfähigkeit verdecken. Verwenden Sie Profile, um die Vergleichskriterien festzulegen, den interaktiven Modus, um das generierte Bedrohungsmodell zu bestätigen, und die Sandbox-Validierung, um auf gemeldete Befunde denselben Nachweisstandard anzuwenden.

FAQ

Wie reduziert Security Swarm Fehlalarme?

Security Swarm untersucht potenzielle Schwachstellen im Kontext Ihres Repositorys, statt riskante Muster isoliert zu melden. Devin verfolgt relevante Datenflüsse, prüft Validierungs- und Autorisierungskontrollen und bewertet, ob das Problem konkrete Sicherheitsauswirkungen hat.Jeder Befund enthält ein Konfidenzniveau und unterstützende Belege. Prüfen Sie diese Belege, bevor Sie Maßnahmen ergreifen, insbesondere wenn ein Befund nicht in einer Sandbox validiert wurde.

Welche Belege sollte ich bei einem Befund prüfen?

Prüfen Sie den betroffenen Code, den Einstiegspunkt, den Datenfluss, vorhandene Gegenmaßnahmen, die angegebene Auswirkung, das Konfidenzniveau und die Ausnutzbarkeit. Wenn die Sandbox-Validierung aktiviert ist, prüfen Sie außerdem das Validierungsergebnis und die dazugehörigen Artefakte.Wenn die Belege eine Kontrolle übersehen oder eine nicht belegte Auswirkung behaupten, verwenden Sie Feedback, um den fehlenden Kontext für zukünftige Scans bereitzustellen.

Was bringt die Sandbox-Validierung zusätzlich?

Die Sandbox-Validierung versucht, einen Befund zu reproduzieren, indem die Anwendung in einer isolierten Umgebung erstellt und ausgeführt wird. Eine erfolgreiche Validierung liefert stärkere Belege für die Ausnutzbarkeit, während eine erfolglose Validierung Annahmen oder Umgebungsbeschränkungen aufzeigen kann, die weiter geprüft werden sollten.Die Sandbox-Validierung ist optional und erfordert ausreichend Validierungshinweise, damit Devin die Anwendung sicher erstellen, ausführen, mit Daten befüllen und sich daran authentifizieren kann.

Wie findet Security Swarm Schwachstellen, die sich über mehrere Dateien erstrecken?

Security Swarm analysiert Teile des Repositorys parallel und kombiniert die Ergebnisse zu einer repositoryweiten Gesamtansicht. Dadurch kann es Beziehungen zwischen Komponenten erkennen, etwa wenn ein Endpunkt eine Kennung offenlegt, die erforderlich ist, um einen anderen Endpunkt auszunutzen.Jeder daraus entstehende verkettete Befund sollte dennoch die relevanten Codepfade aufzeigen und erklären, wie die einzelnen Bedingungen zusammen zu einer konkreten Auswirkung führen.

Warum können die Ergebnisse zwischen Scans variieren?

Security Swarm setzt auf agentische Analyse, daher liefern separate Scans möglicherweise nicht dieselben Befunde oder Formulierungen. Ein klar eingegrenzter Geltungsbereich, ein explizites Bedrohungsmodell, klare Schweregradkriterien und spezifische Hinweise für die Untersuchung helfen, die Abdeckung konsistent zu halten.Halten Sie diese Anforderungen in einem wiederverwendbaren Scan-Profil fest, verwenden Sie den interaktiven Modus, um das vorgeschlagene Bedrohungsmodell zu prüfen, und geben Sie Feedback, wenn einem Ergebnis wichtiger Kontext fehlt.

Bedeutet ein abgeschlossener Scan, dass das Repository keine weiteren Schwachstellen hat?

Kein Sicherheitsscanner kann vollständige Abdeckung garantieren. Die Ergebnisse hängen vom ausgewählten Geltungsbereich, den Profilhinweisen, dem verfügbaren Repository-Kontext und davon ab, ob Befunde in der konfigurierten Umgebung validiert werden können.Führen Sie separate Scans für unterschiedliche Angreifermodelle oder Bedrohungskategorien durch, halten Sie Profile bei Änderungen an der Anwendung aktuell, und verwenden Sie Security Swarm ergänzend zu Ihren bestehenden Sicherheitsprüfungen und Testverfahren.

​Führen Sie Ihren ersten Scan aus

​Befunde überprüfen und darauf reagieren

​Was ein Befund enthält

​Auf einen Befund reagieren

​Scan-Profile

​Ein Profil erstellen

​Grundlegende Informationen

​Bedrohungsmodell

​Hinweise zur Untersuchung

​Triage-Leitfaden

​Sandbox-Validierung

​Bericht

​Hinweise zur Fehlerbehebung

​Erweiterte Optionen

​Ingestion-Profile

​Organisations- und Enterprise-Profile

​Interaktiver Modus

​Sandbox-Validierung konfigurieren

​Scanning skalieren

​Einen Scan-Modus wählen

​Scan-Aufwand

​Massenscan einer Organisation

​Vorhandene Befunde einlesen

​Auto Scan

​Neue Commits scannen

​Scans über Automatisierungen starten

​Scans verwalten und überwachen

​Scan-Verlauf

​Profil eines Scans ändern

​Security-Dashboard

​Zugriff und Berechtigungen

​Vergleichen Sie Security Swarm mit einem anderen Scanner

​FAQ

Führen Sie Ihren ersten Scan aus

Befunde überprüfen und darauf reagieren

Was ein Befund enthält

Auf einen Befund reagieren

Scan-Profile

Ein Profil erstellen

Grundlegende Informationen

Bedrohungsmodell

Hinweise zur Untersuchung

Triage-Leitfaden

Sandbox-Validierung

Bericht

Hinweise zur Fehlerbehebung

Erweiterte Optionen

Ingestion-Profile

Organisations- und Enterprise-Profile

Interaktiver Modus

Sandbox-Validierung konfigurieren

Scanning skalieren

Einen Scan-Modus wählen

Scan-Aufwand

Massenscan einer Organisation

Vorhandene Befunde einlesen

Auto Scan

Neue Commits scannen

Scans über Automatisierungen starten

Scans verwalten und überwachen

Scan-Verlauf

Profil eines Scans ändern

Security-Dashboard

Zugriff und Berechtigungen

Vergleichen Sie Security Swarm mit einem anderen Scanner

FAQ