> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Swarm
> 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](https://devin.ai/blog/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](https://devin.ai/blog/security-eval) anhand eines Ground-Truth-Datensatzes veröffentlichter Sicherheitslücken aus der GitHub Advisory Database.
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](#access-and-permissions).
## Führen Sie Ihren ersten Scan aus
1. Öffnen Sie **Security** in der linken Sidebar und klicken Sie auf **Scan starten**.
2. Wählen Sie unter **Einzelnes Repo** ein Repository aus, das gescannt werden soll.
3. Stellen Sie sicher, dass **Interaktiver Modus** aktiviert ist.
4. Klicken Sie auf **Scan ausführen**.
5. Wenn das vorgeschlagene [Bedrohungsmodell](#interactive-mode) bereit ist, überprüfen Sie es und klicken Sie entweder auf **Sieht gut aus – Scan starten** oder geben Sie Feedback.
6. Sobald Befunde erscheinen, prüfen Sie die Belege und [gehen Sie die Befunde an](#act-on-a-finding), 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.
## 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 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.
### Auf einen Befund reagieren
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.
## 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.
```text theme={null}
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.
```text theme={null}
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.
```text theme={null}
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.
```
### Laufzeitvalidierung
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.
```text theme={null}
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 Laufzeitvalidierung startet für jeden Befund eine separate Devin-Sitzung. Hinweise zur Umgebung finden Sie unter [Laufzeitvalidierung konfigurieren](#configure-runtime-validation).
### 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.
```text theme={null}
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.
```text theme={null}
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.
### 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.
### Laufzeitvalidierung konfigurieren
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](/de/onboard-devin/environment/blueprints) 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
### Mehrere Repositories scannen
Verwenden Sie im Dialog **Neuer Scan** den Tab **Alle Repos**, um Scans für eine Organisation in die Warteschlange zu stellen:
1. Geben Sie optional einen **Filter für Repository-Namen** ein.
2. Wählen Sie optional ein Scan-Profil aus.
3. Lassen Sie **Bereits gescannte Repos überspringen** aktiviert, um Repositories auszuschließen, die bereits mit dem ausgewählten Profil gescannt wurden.
4. Klicken Sie auf **Preview**.
5. 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
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](/de/product-guides/automations) 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.
### 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.
## 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.
* **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](/de/admin/billing/usage).
### 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 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](/de/enterprise/security-access/custom-roles) 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.
## FAQ
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.
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](#act-on-a-finding), um den fehlenden Kontext für zukünftige Scans bereitzustellen.
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](#configure-runtime-validation), damit Devin die Anwendung sicher erstellen, ausführen, mit Daten befüllen und sich daran authentifizieren kann.
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.
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](#scan-profiles) fest, verwenden Sie den [interaktiven Modus](#interactive-mode), um das vorgeschlagene Bedrohungsmodell zu prüfen, und geben Sie Feedback, wenn einem Ergebnis wichtiger Kontext fehlt.
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.