Sicherheitslücken in Ihren Repositories finden, triagieren und beheben
Security Swarm ist Devins Produkt für Sicherheitsscans und Fehlerbehebung. Es erstellt ein auf Ihren Code zugeschnittenes Bedrohungsmodell, untersucht und validiert potenzielle Sicherheitslücken und hilft Ihnen, Befunde mithilfe von Pull Requests zu beheben. Es kann Sicherheitslücken wie Remote Code Execution (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 Sicherheitslücken 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.
Ö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.
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.
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.
Ö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.
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 Laufzeitvalidierung, 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.
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.
Sendet Kontext an eine Feedback-Sitzung, die das Scan-Profil für künftige Scans verfeinert. zum Beispiel können Sie erläutern, dass ein gemeldeter Datenfluss durch ein internes Gateway geschützt ist, damit künftige Scans diese Schutzmaßnahme berücksichtigen können.
Überschreibt den Schweregrad des Befunds, optional mit Kontext für Devin. zum Beispiel können Sie den Schweregrad herabsetzen, wenn eine Ausnutzung privilegierten internen Zugriff erfordert, und diese Einschränkung als Kontext angeben.
Markiert den Befund als Open, Reviewed oder Dismissed. Lassen Sie einen Befund auf Open, solange Maßnahmen erforderlich sind, markieren Sie ihn nach der Triage als Reviewed oder verwerfen Sie ihn, wenn es sich um einen Fehlalarm oder ein Duplikat handelt.
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.
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.
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.
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 Aktionenund Zugriffe auf Tenant-eigene Daten. Betrachten Sie interne Entwicklungsskripte und rein lokaleTools als außerhalb des Geltungsbereichs. Priorisieren Sie Authentifizierungs-Bypasses, mandantenübergreifende Zugriffe, Token-Leakage,Injection und SSRF.
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 zursensiblen Operation. Überprüfe Authentifizierung, Autorisierung, Tenant-Scoping, Validierungund Escaping an jeder Grenze. Identifiziere den genauen erreichbaren Pfad und nenne die relevantenDateien und Zeilen. Melde kein theoretisches Problem, wenn eine wirksame Gegenmaßnahme denPfad blockiert.
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.
Aktivieren Sie die Laufzeitvalidierung, 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.
Verwende das im Repo dokumentierte Entwicklungs-Setup. Starte die API und erstelle zweiNicht-Produktiv-Tenants mit je einem Test-Nutzer. Sende den vermuteten Request alsNutzer 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 Laufzeitvalidierung startet für jeden Befund eine separate Devin-Sitzung. Hinweise zur Umgebung finden Sie unter Laufzeitvalidierung konfigurieren.
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.
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 einenRegressionstest hinzu, der vor dem Fix fehlschlägt und danach erfolgreich ist. Führe die Lint- und Testbefehle des betroffenen Paketsaus. Vermeide größere Dependency-Upgrades, es sei denn, die Schwachstelle lässt sich ohne ein solches nicht sicher beheben.
Ö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.
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.
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.
Die Laufzeitvalidierung wird nur ausgeführt, wenn für das ausgewählte Profil die Laufzeitvalidierung 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.
Verwenden Sie im Dialog Neuer Scan den Tab Alle Repos, um Scans für eine Organisation 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.
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, deaktivieren oder sofort ausführen.
Auto Scan wird mithilfe einer Automatisierung umgesetzt. Für die Konfiguration sind sowohl Code-Scans verwalten als auch die Berechtigung zum Verwalten von Automatisierungen erforderlich. Die Zeitangaben im Zeitplan werden in Ihrer lokalen Zeitzone angezeigt.
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.
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.
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 aus dem Archiv holen 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.
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 Laufzeitvalidierung, um auf gemeldete Befunde denselben Nachweisstandard anzuwenden.
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 zur Laufzeit 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 Laufzeitvalidierung 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 Laufzeitvalidierung zusätzlich?
Die Laufzeitvalidierung 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 Laufzeitvalidierung 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.
