Open-Source, plattformübergreifendes, Mehrzweck-Sicherheitsaudit-Tool
**Hinweis**: DevAudit verwendet die OSS Index-Datenbank, die eine gewisse Ratenbegrenzung aufweist. Falls Ihnen auffällt, dass Sie die Grenze erreichen, melden Sie bitte ein Issue. Authentifizierte Benutzer erhalten eine höhere Grenze, und wir arbeiten daran, die Authentifizierung in DevAudit bald zu implementieren. Die meisten nicht authentifizierten Benutzer werden die Grenze wahrscheinlich für viele Anwendungsfälle nicht bemerken. Sie tritt normalerweise nur bei deutlich größeren Projekten oder höheren Projektvolumina in Kraft.
# DevAudit: Entwicklungssicherheitsüberprüfung
Holen Sie sich die neueste Version von der [Releases](https://github.com/OSSIndex/DevAudit/releases) Seite.
## Inhaltsverzeichnis
* [Über](https://github.com/OSSIndex/DevAudit/wiki#about)
* [Funktionen](https://github.com/OSSIndex/DevAudit/wiki#features)
* [Anforderungen](https://github.com/OSSIndex/DevAudit/wiki#requirements)
* [Installation](https://github.com/OSSIndex/DevAudit/wiki#installation)
* [Konzepte](https://github.com/OSSIndex/DevAudit/wiki#concepts)
* [Grundlegende Nutzung](https://github.com/OSSIndex/DevAudit/wiki#basic-usage)
* [Audit-Ziele](https://github.com/OSSIndex/DevAudit/wiki#audit-targets)
* [Umgebungen](https://github.com/OSSIndex/DevAudit/wiki#environments)
* [Programmoptionen](https://github.com/OSSIndex/DevAudit/wiki#program-options)
* [Docker-Nutzung](https://github.com/OSSIndex/DevAudit/wiki#docker-usage)
* [Fehlerbehebung](https://github.com/OSSIndex/DevAudit/wiki#troubleshooting)
* [Bekannte Probleme](https://github.com/OSSIndex/DevAudit/wiki#known-issues)
## Über
DevAudit ist ein quelloffenes, plattformübergreifendes, vielseitiges Sicherheitsaudit-Tool, das sich an Entwickler und Teams richtet, die DevOps und DevSecOps einführen, und Sicherheitslücken auf mehreren Ebenen des Lösungsstacks erkennt. DevAudit bietet eine breite Palette von Audit-Funktionen, die Sicherheitspraktiken und die Implementierung von Sicherheitsaudits im Softwareentwicklungslebenszyklus automatisieren. DevAudit kann Ihre Betriebssystem- und Anwendungspaketabhängigkeiten, Anwendungs- und Anwendungsserverkonfigurationen sowie Anwendungscode auf potenzielle Schwachstellen scannen, basierend auf Daten, die von Anbietern wie [OSS Index](https://ossindex.net/) und [Vulners](https://vulners.com) aus einer Vielzahl von Quellen und Datenfeeds wie dem National Vulnerability Database (NVD) CVE-Datenfeed, dem Debian Security Advisories-Datenfeed, Drupal Security Advisories und vielen anderen aggregiert werden.
DevAudit hilft Entwicklern, mindestens 4 der [OWASP Top 10](https://www.owasp.org/index.php/Top_10_2013) Risiken für die Webanwendungsentwicklung zu adressieren:
* [A9 Verwendung von Komponenten mit bekannten Schwachstellen](https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities)
* [A5 Sicherheitsfehlkonfiguration](https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration)
* [A6 Offenlegung sensibler Daten](https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure)
* [A2 Defekte Authentifizierung und Session-Management](https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management)
sowie Risiken, die von MITRE im CWE-Wörterbuch klassifiziert wurden, wie [CWE-2 Environment](http://cwe.mitre.org/data/definitions/2.html) und [CWE-200 Information Disclosure](http://cwe.mitre.org/data/definitions/200.html)
Mit fortschreitender Entwicklung und zunehmender Reife der Fähigkeiten wird DevAudit in der Lage sein, die anderen Risiken der OWASP Top 10 und CWE-Listen wie Injection und XSS zu adressieren. Angesichts des Fokus auf Web-, Cloud- und verteilte Multi-User-Anwendungen ist die Softwareentwicklung heute zunehmend komplex, wobei Sicherheitsprobleme und potenzielle Schwachstellen auf allen Ebenen des Stacks auftreten, auf die Entwickler angewiesen sind, um Anwendungen bereitzustellen. Das Ziel von DevAudit ist es, eine Plattform zur Automatisierung der Implementierung von Sicherheitsüberprüfungen und Best Practices auf allen Ebenen des Lösungsstacks zu bieten – von Bibliothekspaketabhängigkeiten über Anwendungs- und Serverkonfiguration bis hin zum Quellcode.
## Funktionen
* **Plattformübergreifend mit ebenfalls verfügbarem Docker-Image.** DevAudit läuft unter Windows und Linux, mit geplanter Unterstützung für *BSD, Mac und ARM Linux. Für den Betrieb von DevAudit ist lediglich eine aktuelle Version von .NET oder Mono erforderlich. Ein [DevAudit Docker-Image](https://hub.docker.com/r/ossindex/devaudit/) kann auch von Docker Hub bezogen und ohne Installation von Mono ausgeführt werden.
* **CLI-Schnittstelle.** DevAudit verfügt über eine CLI-Schnittstelle mit einer Option für nicht-interaktive Ausgabe und kann problemlos in CI-Build-Pipelines oder als Post-Build-Befehlszeilenaufgaben in Entwickler-IDEs integriert werden. Die Arbeit an der Integration der Kern-Audit-Bibliothek in IDE-GUIs hat bereits mit der [Audit.Net](https://visualstudiogallery.msdn.microsoft.com/73493090-b219-452a-989e-e3d228023927?SRC=Home) Visual Studio-Erweiterung begonnen.
* **Kontinuierlich aktualisierte Schwachstellendaten.** DevAudit verwendet Backend-Datenanbieter wie [OSS Index](https://ossindex.net/) und [Vulners](https://vulners.com/#stats), die kontinuierlich aktualisierte Schwachstellendaten aus einem [breiten Spektrum](https://vulners.com/stats) von Sicherheitsdatenfeeds und -quellen wie den NVD CVE-Feeds, Drupal Security Advisories usw. bereitstellen. Die Unterstützung für zusätzliche Schwachstellen- und Paketdatenanbieter wie [vFeed](https://vfeed.io) und [Libraries.io](https://libraries.io) wird hinzugefügt.
* **Audit von Betriebssystem- und Entwicklungspaketabhängigkeiten.** DevAudit auditiert Windows-Anwendungen und -Pakete, die über Windows MSI, Chocolatey und OneGet installiert wurden, sowie Debian-, Ubuntu- und CentOS-Linux-Pakete, die über Dpkg, RPM und YUM installiert wurden, auf Schwachstellen, die für bestimmte Versionen der Anwendungen und Pakete gemeldet wurden. Für Entwicklungspaketabhängigkeiten und -bibliotheken auditiert DevAudit NuGet v2-Abhängigkeiten für .NET, Yarn/NPM- und Bower-Abhängigkeiten für nodejs und Composer-Paketabhängigkeiten für PHP. Die Unterstützung für andere Paketmanager für verschiedene Sprachen wird regelmäßig erweitert.
* **Audit von Anwendungsserverkonfigurationen.** DevAudit auditiert die Serverversion und die Serverkonfiguration für die Server OpenSSH sshd, Apache httpd, MySQL/MariaDB, PostgreSQL und Nginx, viele weitere folgen. Die Konfigurationsaudits basieren auf der [Alpheus](https://github.com/allisterb/Alpheus)-Bibliothek und erfolgen mittels vollständiger syntaktischer Analyse der Serverkonfigurationsdateien. Die Regeln für die Serverkonfiguration sind in YAML-Textdateien gespeichert und können an die Bedürfnisse von Entwicklern angepasst werden. Die Unterstützung für viele weitere Server und Anwendungen sowie Analysetypen wie Datenbankaudits wird regelmäßig erweitert.
* **Audit von Anwendungskonfigurationen.** DevAudit auditiert Microsoft ASP.NET-Anwendungen und erkennt Schwachstellen in der Anwendungskonfiguration. Die Regeln für die Anwendungskonfiguration sind in YAML-Textdateien gespeichert und können an die Bedürfnisse von Entwicklern angepasst werden. Das Audit von Anwendungskonfigurationen für Anwendungen wie Drupal, WordPress und DNN CMS ist in Vorbereitung.
* **Audit von Anwendungscode durch statische Analyse.** DevAudit unterstützt derzeit die statische Analyse von .NET CIL-Bytecode. Analysatoren befinden sich in externen Skriptdateien und können basierend auf den Bedürfnissen des Entwicklers vollständig angepasst werden. Die Unterstützung für C#-Quellcodeanalyse über Roslyn, PHP7-Quellcode und viele weitere Sprachen sowie externe statische Code-Analyse-Tools ist in Vorbereitung.
* **Remote-Agentless-Auditing.** DevAudit kann über SSH eine Verbindung zu entfernten Hosts herstellen, wobei in entfernten Umgebungen identische Audit-Funktionen wie in lokalen Umgebungen zur Verfügung stehen. Für das Auditieren entfernter Hosts ist lediglich ein gültiger SSH-Login erforderlich. DevAudit, das unter Windows läuft, kann über SSH eine Verbindung zu Linux-Hosts herstellen und diese auditieren. Unter Windows kann DevAudit auch über WinRM eine Verbindung zu anderen Windows-Maschinen herstellen und diese auditieren.
* **Agentless Docker-Container-Auditing.** DevAudit kann laufende Docker-Container vom Docker-Host aus auditieren, wobei in Container-Umgebungen identische Funktionen wie in lokalen Umgebungen zur Verfügung stehen.
* **GitHub-Repository-Auditing.** DevAudit kann direkt eine Verbindung zu einem auf GitHub gehosteten Projekt-Repository herstellen und Paketquellen- und Anwendungskonfigurationsaudits durchführen.
* **PowerShell-Unterstützung.** DevAudit kann auch innerhalb der PowerShell-Systemverwaltungsumgebung als Cmdlets ausgeführt werden. Die Arbeit an der PowerShell-Unterstützung ist derzeit pausiert, wird aber in naher Zukunft mit Unterstützung für plattformübergreifende PowerShell sowohl unter Windows als auch Linux wieder aufgenommen.
## Anforderungen
DevAudit ist eine .NET 4.6-Anwendung. Für die lokale Installation auf Ihrem Rechner benötigen Sie entweder die Microsoft .NET Framework 4.6-Laufzeit unter Windows oder Mono 4.4+ unter Linux. .NET 4.6 sollte auf den meisten aktuellen Windows-Versionen bereits installiert sein; falls nicht, ist es als Windows-Funktion verfügbar, die entweder über die Systemsteuerung „Programme und Funktionen“ unter Consumer-Windows oder über die Option „Rollen und Features hinzufügen“ im Server-Manager unter Serverversionen von Windows aktiviert oder installiert werden kann. Für ältere Windows-Versionen ist das .NET 4.6-Installationsprogramm von Microsoft [hier](https://www.microsoft.com/en-us/download/details.aspx?id=48130) zu finden.
Unter Linux wird mindestens Mono 4.4 unterstützt. Obwohl DevAudit unter Mono 4 läuft ([mit einem bekannten Problem](https://github.com/OSSIndex/DevAudit/issues/78)), wird die Installation von Mono 5 empfohlen. Mono 5 bringt viele [Verbesserungen](http://www.mono-project.com/news/2017/05/15/mono-5-0-is-out/) für die Build- und Laufzeitkomponenten von Mono, die DevAudit zugutekommen.
Die vorhandenen Mono-Pakete, die von Ihrer Distribution bereitgestellt werden, sind wahrscheinlich noch nicht Mono 5, daher müssen Sie Mono-Pakete manuell installieren, um Mono 5 nutzen zu können. Installationsanweisungen für die aktuellsten Pakete des Mono-Projekts für mehrere wichtige Linux-Distributionen finden Sie [hier](http://www.mono-project.com/docs/getting-started/install/linux/). Es wird empfohlen, das Paket mono-devel zu installieren, da dies die Wahrscheinlichkeit fehlender Assemblys verringert.
Alternativ können Sie unter Linux das DevAudit Docker-Image verwenden, wenn Sie Mono nicht installieren möchten und bereits Docker auf Ihrem Rechner installiert haben.
## Installation
DevAudit kann auf folgende Weise installiert werden:
- Aus dem Quellcode erstellen.
- Verwendung einer Binär-Release-Archivdatei, die von Github für Windows oder Linux heruntergeladen wurde.
- Verwendung des MSI-Installers für Releases, der von Github für Windows heruntergeladen wurde.
- Verwendung des Chocolatey-Paketmanagers unter Windows.
- Herunterladen des Images ossindex/devaudit von Docker Hub unter Linux.
### Aus dem Quellcode unter Linux erstellen
1. Voraussetzungen: Mono 4.4+ (Mono 5 empfohlen) und das Paket mono-devel, das den Compiler und andere Werkzeuge zum Erstellen von Mono-Anwendungen bereitstellt. Ihre Distribution sollte Pakete für mindestens Mono Version 4.4 und höher haben, ansonsten finden Sie hier manuelle Installationsanweisungen für die aktuellsten Pakete des Mono-Projekts für mehrere wichtige Linux-Distributionen: [hier](http://www.mono-project.com/docs/getting-started/install/linux/)
2. Klonen Sie das DevAudit-Repository von https://github.com/OSSIndex/DevAudit.git
3. Führen Sie das Skript `build.sh` im Stammverzeichnis von DevAudit aus. DevAudit sollte ohne Fehler kompilieren.
4. Führen Sie `./devaudit --help` aus. Sie sollten die DevAudit-Version und den Hilfebildschirm sehen.
Beachten Sie, dass NuGet unter Linux gelegentlich mit `Error: NameResolutionFailure` beendet wird, was anscheinend ein vorübergehendes Problem beim Kontaktieren der Server ist, die die NuGet-Pakete enthalten. Führen Sie einfach ./build.sh erneut aus, bis der Build normal abgeschlossen wird.
### Aus dem Quellcode unter Windows erstellen
1. Voraussetzungen: Sie müssen eines der folgenden haben:
* Ein [.NET Framework 4.6](http://getdotnet.azurewebsites.net/target-dotnet-platforms.html) SDK oder Developer Pack.
* Visual Studio 2015.
2. Klonen Sie das DevAudit-Repository von https://github.com/OSSIndex/DevAudit.git
3. Führen Sie das Skript `build.cmd` im Stammverzeichnis von DevAudit aus. DevAudit sollte ohne Fehler kompilieren.
4. Führen Sie `./devaudit --help` aus. Sie sollten die DevAudit-Version und den Hilfebildschirm sehen.
### Installation aus den Release-Archivdateien unter Windows und Linux
1. Voraussetzungen: Sie müssen Mono 4.4+ unter Linux oder .NET 4.6 unter Windows haben.
2. Laden Sie die neueste Release-Archivdatei für Windows oder Linux von der Projekt-[Releases](https://github.com/OSSIndex/DevAudit/releases)-Seite herunter. Entpacken Sie diese Datei in ein Verzeichnis.
2. Führen Sie aus dem Verzeichnis, in das Sie das Release-Archiv entpackt haben, unter Windows `devaudit --help` oder unter Linux `./devaudit --help` aus. Sie sollten die Version und den Hilfebildschirm sehen.
3. (Optional) Fügen Sie das DevAudit-Installationsverzeichnis zu Ihrer PATH-Umgebungsvariable hinzu
### Installation mit dem MSI-Installer unter Windows
Der MSI-Installer für ein Release befindet sich auf der Github-Releases-Seite.
1. Klicken Sie auf den [Releases](https://github.com/OSSIndex/DevAudit/releases)-Link oben auf der Seite.
2. Identifizieren Sie das Release, das Sie installieren möchten.
3. Für jedes Release, das einen vorgefertigten Installer hat, sollte ein „DevAudit.exe“-Link sichtbar sein.
4. Laden Sie die Datei herunter und führen Sie den Installer aus. Sie werden durch eine einfache Installation geführt.
6. Öffnen Sie ein *neues* Eingabeaufforderungs- oder PowerShell-Fenster, damit DevAudit im Pfad verfügbar ist.
7. Führen Sie DevAudit aus.
### Installation mit Chocolatey unter Windows
DevAudit ist auch auf [Chocolatey](https://chocolatey.org/packages/devaudit/2.0.0.40-beta) verfügbar.
1. Installieren Sie [Chocolatey](https://chocolatey.org).
2. Öffnen Sie eine Administratorkonsole oder ein PowerShell-Fenster.
3. Geben Sie `choco install devaudit` ein.
4. Führen Sie DevAudit aus.
### Installation mit Docker unter Linux
Holen Sie sich das DevAudit-Image von Docker Hub: `docker pull ossindex/devaudit`. Das mit `ossindex/devaudit:latest` (das ist das Standard-Image, das heruntergeladen wird) getaggte Image wird aus dem aktuellsten Release erstellt, während `ossindex/devaudit:unstable` auf dem Master-Zweig des Quellcodes basiert und die neuesten Ergänzungen enthält, wenn auch mit weniger Tests.
Konzepte
---
#### Audit-Ziel
Stellt eine logische Gruppe von Audit-Funktionen dar. DevAudit unterstützt derzeit die folgenden Audit-Ziele:
- **Paketquelle**. Eine Paketquelle verwaltet Anwendungs- und Bibliotheksabhängigkeiten mithilfe eines Paketmanagers. Paketmanager installieren, entfernen oder aktualisieren Anwendungen und Bibliotheksabhängigkeiten für ein Betriebssystem wie Debian Linux oder für eine Entwicklungssprache oder ein Framework wie .NET oder nodejs. Beispiele für Paketquellen sind dpkg, yum, Chocolatey, Composer und Bower. DevAudit auditiert die Namen und Versionen installierter Pakete auf Schwachstellen, die für bestimmte Versionen dieser Pakete gemeldet wurden.
- **Anwendung**. Eine Anwendung wie Drupal oder eine benutzerdefinierte Anwendung, die mit einem Framework wie ASP.NET erstellt wurde. DevAudit auditiert Anwendungen und Anwendungsmodule und -Plugins auf Schwachstellen, die für bestimmte Versionen von Anwendungsbinärdateien, Modulen und Plugins gemeldet wurden. DevAudit kann auch Anwendungskonfigurationen auf bekannte Schwachstellen auditieren und statische Analysen des Anwendungscodes durchführen, um bekannte Schwachstellen zu finden.
- **Anwendungsserver**. Anwendungsserver stellen kontinuierlich laufende Dienste oder Daemons wie einen Web- oder Datenbankserver für andere Anwendungen zur Verfügung oder ermöglichen Benutzern den Zugriff auf Dienste wie Authentifizierung. Beispiele für Anwendungsserver sind der OpenSSH sshd- und Apache httpd-Server. DevAudit kann Anwendungsserver-Binärdateien, Module und Plugins auf Schwachstellen auditieren, die für bestimmte Versionen gemeldet wurden, sowie Serverkonfigurationen auf bekannte Serverkonfigurations-Schwachstellen und -Schwächen auditieren.
#### Audit-Umgebung
Stellt eine logische Umgebung dar, in der Audits gegen Audit-Ziele ausgeführt werden. Audit-Umgebungen abstrahieren die E/A und Befehlsausführungen, die für ein Audit erforderlich sind, und ermöglichen identische Funktionen gegen Audit-Ziele unabhängig vom physischen oder Netzwerk-Standort der Dateien und ausführbaren Dateien des Ziels. Derzeit werden folgende Umgebungen unterstützt:
- **Lokal**. Dies ist die Standard-Audit-Umgebung, in der Audits auf dem lokalen Rechner ausgeführt werden.
- **SSH**. Audits werden auf einem entfernten Host ausgeführt, der über SSH verbunden ist. Es ist nicht erforderlich, DevAudit auf dem entfernten Host zu installieren.
- **WinRM**. Audits werden auf einem entfernten Windows-Host ausgeführt, der über WinRM verbunden ist. Es ist nicht erforderlich, DevAudit auf dem entfernten Host zu installieren.
- **Docker**. Audits werden in einem laufenden Docker-Container ausgeführt. Es ist nicht erforderlich, DevAudit auf dem Container-Image zu installieren.
- **GitHub**. Audits werden direkt im Dateisystem eines GitHub-Projekt-Repositorys ausgeführt. Es ist nicht erforderlich, das Projekt lokal auszuchecken oder herunterzuladen, um das Audit durchzuführen.
#### Audit-Optionen
Dies sind verschiedene Optionen, die für das Audit aktiviert werden können. Sie können Optionen angeben, die für das DevAudit-Programm gelten, z. B. den nicht-interaktiven Modus, sowie Optionen, die für das Ziel gelten, z. B. wenn Sie die Option AppDevMode für das Auditieren von ASP.NET-Anwendungen auf „true“ setzen, werden bestimmte Audit-Regeln nicht aktiviert.
Grundlegende Nutzung
---
Die CLI ist die primäre Schnittstelle zum DevAudit-Programm und eignet sich sowohl für die interaktive Nutzung als auch für die nicht-interaktive Nutzung in geplanten Aufgaben, Shell-Skripten, CI-Build-Pipelines und Post-Build-Aufgaben in Entwickler-IDEs. Die grundlegende DevAudit-CLI-Syntax lautet:
devaudit TARGET [ENVIRONMENT] | [OPTIONS]
wobei `TARGET` das Audit-Ziel angibt, `ENVIRONMENT` die Audit-Umgebung und `OPTIONS` die Optionen für das Audit-Ziel und die Umgebung. Es gibt zwei Möglichkeiten, Optionen anzugeben: Programmoptionen und allgemeine Audit-Optionen, die für mehr als ein Ziel gelten, können direkt auf der Befehlszeile als Parameter angegeben werden. Zielspezifische Optionen können mit der Option `-o` im Format `-o OPTION1=WERT1,OPTION2=WERT2,....` angegeben werden, wobei Kommas die einzelnen Options-Schlüssel-Wert-Paare trennen.
Wenn Sie die Programmausgabe in eine Datei umleiten oder pipen, sollten Sie immer die Option `-n --non-interactive` verwenden, um interaktive Benutzeroberflächenfunktionen und Animationen zu deaktivieren.
Bei der Angabe von Dateipfaden gibt ein @-Präfix vor einem Pfad für DevAudit an, dass dieser Pfad relativ zum Stammverzeichnis des Audit-Ziels ist. Z. B. wenn Sie angeben:
`-r c:\meinprojekt -b @bin\Debug\app2.exe`
Betrachtet DevAudit den Pfad zur Binärdatei als c:\meinprojekt\bin\Debug\app2.exe.
Audit-Ziele
---
#### Paketquellen
- `msi` Führen Sie ein Paketaudit der Windows Installer MSI-Paketquelle auf Windows-Rechnern durch.
- `npm` Führen Sie ein Paketaudit der NPM package.json durch.
- `choco` Führen Sie ein Paketaudit von Paketen durch, die mit dem Choco-Paketmanager installiert wurden.
- `oneget` Führen Sie ein Paketaudit der systemweiten OneGet-Paketquelle unter Windows durch.
- `nuget` Führen Sie ein Paketaudit einer NuGet v2-Paketquelle durch. Sie müssen den Speicherort der NuGet-Datei `packages.config`, die Sie auditieren möchten, mit der Option `-f` oder `--file` angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.
- `bower` Führen Sie ein Paketaudit einer Bower-Paketquelle durch. Sie müssen den Speicherort der Bower-Datei `packages.json`, die Sie auditieren möchten, mit der Option `-f` oder `--file` angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.- `composer` Führen Sie ein Paket-Audit einer Composer-Paketquelle durch. Sie müssen den Speicherort der `composer.json`-Datei mit der Option `-f` oder `--file` angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.
- `dpkg` Führen Sie ein Paket-Audit der System-Dpkg-Paketquelle auf Debian Linux und Derivaten durch.
- `rpm` Führen Sie ein Paket-Audit der System-RPM-Paketquelle auf RedHat Linux und Derivaten durch.
- `yum` Führen Sie ein Paket-Audit der System-Yum-Paketquelle auf RedHat Linux und Derivaten durch.
Für jede Paketquelle können die folgenden allgemeinen Audit-Optionen verwendet werden:
- `-f --file` Geben Sie den Speicherort der Konfigurationsdatei des Paketmanagers an, falls erforderlich. Die Paketquellen NuGet, Bower und Composer erfordern diese Option.
- `--list-packages` Nur die Pakete auflisten, die von DevAudit in der gescannten Paketquelle gefunden wurden.
- `--list-artifacts` Nur die Artefakte auflisten, die auf OSS Index für die von DevAudit gescannten Pakete gefunden wurden.
Paketquellen mit dem Tag [Experimental] sind nur im Master-Branch des Quellcodes verfügbar und haben möglicherweise eingeschränkte OSS-Index-Unterstützung im Backend. Sie können jedoch jederzeit die gescannten Pakete und die auf OSS Index verfügbaren Artefakte mit den Optionen `list-packages` und `list-artifacts` auflisten.
#### Anwendungen
- `aspnet` Führen Sie ein Anwendungs-Audit einer ASP.NET-Anwendung durch. Die relevanten Optionen sind:
- `-r --root-directory` Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Anwendungsverzeichnis, das Dateien wie Global.asax und Web.config enthält.
- `-b --application-binary` Geben Sie die Anwendungsbinärdatei an. Dies ist die .NET-Assembly, die den .NET-Bytecode der Anwendung enthält. Diese Datei ist normalerweise eine .DLL und befindet sich im Unterordner bin des Stammverzeichnisses der ASP.NET-Anwendung.
- `--config-file` oder `-o AppConfig=configuration-file` Gibt die ASP.NET-Anwendungskonfigurationsdatei an. Diese Datei heißt normalerweise Web.config und befindet sich im Stammverzeichnis der Anwendung. Sie können den Standardwert @Web.config mit dieser Option überschreiben.
- `-o AppDevMode=enabled` Gibt an, dass der Anwendungsentwicklungsmodus für das Audit aktiviert sein soll. Dieser Modus kann verwendet werden, wenn eine Anwendung auditiert wird, die sich in der Entwicklung befindet. Bestimmte Konfigurationsregeln, die für den AppDevMode als deaktiviert markiert sind (z. B. Ausführen der Anwendung im ASP.NET-Debug-Modus), werden während des Audits nicht aktiviert.
- `netfx` Führen Sie ein Anwendungs-Audit einer .NET-Anwendung durch. Die relevanten Optionen sind:
- `-r --root-directory` Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Anwendungsverzeichnis, das Dateien wie App.config enthält.
- `-b --application-binary` Geben Sie die Anwendungsbinärdatei an. Dies ist die .NET-Assembly, die den .NET-Bytecode der Anwendung enthält. Diese Datei ist normalerweise eine .DLL und befindet sich im Unterordner bin des Stammverzeichnisses der ASP.NET-Anwendung.
- `--config-file` oder `-o AppConfig=configuration-file` Gibt die .NET-Anwendungskonfigurationsdatei an. Diese Datei heißt normalerweise App.config und befindet sich im Stammverzeichnis der Anwendung. Sie können den Standardwert @App.config mit dieser Option überschreiben.
- `-o GendarmeRules=RuleLibrary` Gibt an, dass der [Gendarme](http://www.mono-project.com/docs/tools+libraries/tools/gendarme/)-Statikanalysator für das Audit mit Regeln aus der angegebenen Regelbibliothek aktiviert werden soll. Zum Beispiel:
`devaudit netfx -r /home/allisterb/vbot-debian/vbot.core -b @bin/Debug/vbot.core.dll --skip-packages-audit -o GendarmeRules=Gendarme.Rules.Naming`
führt den Gendarme-Statikanalysator auf der Assembly vbot.core.dll unter Verwendung von Regeln aus der Bibliothek Gendarme.Rules.Naming aus. Die vollständige Liste der Regelbibliotheken (entnommen aus dem Gendarme-Wiki):
* [Gendarme.Rules.BadPractice](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.BadPractice%28git%29)
* [Gendarme.Rules.Concurrency](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Concurrency%28git%29)
* [Gendarme.Rules.Correctness](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Correctness%28git%29)
* [Gendarme.Rules.Design](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Design%28git%29)
* [Gendarme.Rules.Design.Generic](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Design.Generic%28git%29)
* [Gendarme.Rules.Design.Linq](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Design.Linq%28git%29)
* [Gendarme.Rules.Exceptions](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Exceptions%28git%29)
* [Gendarme.Rules.Gendarme](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Gendarme%28git%29)
* [Gendarme.Rules.Globalization](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Globalization%28git%29)
* [Gendarme.Rules.Interoperability](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Interoperability%28git%29)
* [Gendarme.Rules.Interoperability.Com](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Interoperability.Com%28git%29)
* [Gendarme.Rules.Maintainability](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Maintainability%28git%29)
* [Gendarme.Rules.NUnit](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.NUnit%28git%29)
* [Gendarme.Rules.Naming](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Naming%28git%29)
* [Gendarme.Rules.Performance](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Performance%28git%29)
* [Gendarme.Rules.Portability](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Portability%28git%29)
* [Gendarme.Rules.Security](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Security%28git%29)
* [Gendarme.Rules.Security.Cas](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Security.Cas%28git%29)
* [Gendarme.Rules.Serialization](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Serialization%28git%29)
* [Gendarme.Rules.Smells](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Smells%28git%29)
* [Gendarme.Rules.Ui](https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Ui%28git%29)
- `drupal7` Führen Sie ein Anwendungs-Audit einer Drupal-7-Anwendung durch.
- `-r --root-directory` Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Verzeichnis Ihrer Drupal-7-Installation.
- `drupal8` Führen Sie ein Anwendungs-Audit einer Drupal-8-Anwendung durch.
- `-r --root-directory` Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Verzeichnis Ihrer Drupal-8-Installation.
Alle Anwendungen unterstützen außerdem die folgenden gemeinsamen Optionen zum Auditieren der Anwendungsmodule oder -Plugins:
- `--list-packages` Nur die von DevAudit gescannten Anwendungs-Plugins oder -Module auflisten.
- `--list-artifacts` Nur die auf OSS Index gefundenen Artefakte für gescannte Anwendungs-Plugins und -Module auflisten.
- `--skip-packages-audit` Nur ein Audit der Anwendungskonfiguration oder -Code-Analyse durchführen und das Paket-Audit überspringen.
#### Anwendungsserver
- `sshd` Führen Sie ein Anwendungsserver-Audit eines OpenSSH-sshd-kompatiblen Servers durch.
- `httpd` Führen Sie ein Anwendungsserver-Audit eines Apache-httpd-kompatiblen Servers durch.
- `mysql` Führen Sie ein Anwendungsserver-Audit eines MySQL-kompatiblen Servers (wie MariaDB oder Oracle MySQL) durch.
- `nginx` Führen Sie ein Anwendungsserver-Audit eines Nginx-Servers durch.
- `pgsql` Führen Sie ein Anwendungsserver-Audit eines PostgreSQL-Servers durch.
Dies ist ein Beispiel für eine Befehlszeile für ein Anwendungsserver-Audit:
`./devaudit httpd -i httpd-2.2 -r /usr/local/apache2/ --config-file @conf/httpd.conf -b @bin/httpd`
welches einen Apache-Httpd-Server auditiert, der auf einem Docker-Container mit dem Namen httpd-2.2 läuft.
Die folgenden Audit-Optionen sind für alle Anwendungsserver gemeinsam:
- `-r --root-directory` Gibt das Stammverzeichnis des Servers an. Dies ist die oberste Ebene Ihres Server-Dateisystems und standardmäßig `/`, es sei denn, Sie möchten ein anderes Server-Stammverzeichnis.
- `--config-file` Gibt die Server-Konfigurationsdatei an. Z. B. im obigen Audit befindet sich die Apache-Konfigurationsdatei unter `/usr/local/apache2/conf/httpd.conf`. Wenn Sie die Konfigurationsdatei nicht angeben, versucht DevAudit, die Konfigurationsdatei für den ausgewählten Server automatisch zu erkennen.
- `-b --application-binary` Gibt die Server-Binärdatei an. Z. B. im obigen Audit befindet sich die Apache-Binärdatei unter `/usr/local/apache2/bin/httpd`. Wenn Sie den Binärpfad nicht angeben, versucht DevAudit, die Server-Binärdatei für den ausgewählten Server automatisch zu erkennen.
Anwendungsserver unterstützen außerdem die folgenden gemeinsamen Optionen zum Auditieren der Server-Module oder -Plugins:
- `--list-packages` Nur die von DevAudit gescannten Anwendungs-Plugins oder -Module auflisten.
- `--list-artifacts` Nur die auf OSS Index gefundenen Artefakte für gescannte Anwendungs-Plugins und -Module auflisten.
- `--skip-packages-audit` Nur ein Server-Konfigurationsaudit durchführen und das Paket-Audit überspringen.
Umgebungen
---
Derzeit werden 5 Audit-Umgebungen unterstützt: lokal, entfernte Hosts über SSH, entfernte Hosts über WinRM, Docker-Container und GitHub. Lokale Umgebungen werden standardmäßig verwendet, wenn keine anderen Umgebungsoptionen angegeben werden.
#### SSH
Die SSH-Umgebung ermöglicht Audits auf jedem entfernten Host, der über SSH zugänglich ist, ohne dass DevAudit auf dem entfernten Host installiert sein muss. SSH-Umgebungen sind plattformübergreifend: Sie können von einem Windows-Rechner, auf dem DevAudit läuft, eine Verbindung zu einem Linux-Remote-Host herstellen. Eine SSH-Umgebung wird durch die folgenden Optionen erstellt:`-s SERVER [--ssh-port PORT] -u USER [-k KEYFILE] [-p | --password-text PASSWORD]`
`-s SERVER` Gibt den entfernten Host oder die IP an, mit der über SSH verbunden werden soll.
`-u USER` Gibt den Benutzer an, mit dem Sie sich auf dem Server anmelden möchten.
`--ssh-port PORT` Gibt den Port auf dem entfernten Host an, mit dem verbunden werden soll. Der Standardwert ist 22.
`-k KEYFILE` Gibt die OpenSSH-kompatible private Schlüsseldatei an, die zur Verbindung mit dem entfernten Server verwendet werden soll. Derzeit werden nur RSA- oder DSA-Schlüssel in Dateien im PEM-Format unterstützt.
`-p` Stellt eine Eingabeaufforderung mit deaktiviertem lokalem Echo für die interaktive Eingabe des Server-Passworts oder der Passphrase der Schlüsseldatei bereit.
`--password-text PASSWORD` Geben Sie das Benutzerpasswort oder die Passphrase der Schlüsseldatei als Klartext in der Befehlszeile an. Beachten Sie, dass Sie unter Linux bei Passwörtern mit Sonderzeichen den Text in der Befehlszeile mit einfachen Anführungszeichen wie `'MyPa<ss'` umschließen sollten, um zu verhindern, dass die Shell die Sonderzeichen interpretiert.
#### WinRM
Die WinRM-Umgebung ermöglicht Audits auf jedem entfernten Windows-Host, der über WinRM zugänglich ist, ohne dass DevAudit auf dem entfernten Host installiert sein muss. WinRM-Umgebungen sind derzeit nur auf Windows-Rechnern verfügbar, auf denen DevAudit läuft. Eine WinRM-Umgebung wird durch die folgenden Optionen erstellt:`-w IP -u USER [-p | --password-text PASSWORD]`
`-w IP` Gibt die entfernte IP an, mit der über WinRM verbunden werden soll.
`-u USER` Gibt den Benutzer an, mit dem Sie sich auf dem Server anmelden möchten.
`-p` Stellt eine Eingabeaufforderung mit deaktiviertem lokalem Echo für die interaktive Eingabe des Server-Passworts oder der Passphrase der Schlüsseldatei bereit.
`--password-text PASSWORD` Geben Sie das Server-Passwort oder die Passphrase der Schlüsseldatei als Klartext in der Befehlszeile an.
#### Docker
Dieser Abschnitt behandelt, wie Docker-Images mit DevAudit auditiert werden, das auf dem lokalen Rechner installiert ist. Informationen zur **Ausführung** von DevAudit als containerisierte Docker-App finden Sie im folgenden Abschnitt zur Docker-Nutzung.
Eine Docker-Audit-Umgebung wird durch die folgende Option angegeben: `-i CONTAINER_NAME | -i CONTAINER_ID`
`CONTAINER_(NAME|ID)` Gibt den Namen oder die ID eines laufenden Docker-Containers an, mit dem verbunden werden soll. Der Container muss bereits laufen, da DevAudit nicht weiß, wie der Container mit dem von Ihnen benötigten Namen oder Zustand gestartet werden kann.
#### GitHub
Die GitHub-Audit-Umgebung ermöglicht Audits direkt auf einem GitHub-Projekt-Repository. Eine GitHub-Umgebung wird mit der Option `-g` erstellt: `-g "Owner=OWNER,Name=NAME,Branch=BRANCH"`
`OWNER` Gibt den Besitzer des Projekts an
`NAME` Gibt den Namen des Projekts an
`PATH` Gibt den Branch des Projekts an, mit dem verbunden werden soll
Sie können die Optionen `-r`, `--config-file` und `-f` wie gewohnt verwenden, um die Pfade zu Dateisystem-Dateien und -Verzeichnissen anzugeben, die für das Audit erforderlich sind. Z. B. der folgende Befehl:
`devaudit aspnet -g "Owner=Dnnsoftware,Name=Dnn.Platforn,Branch=Release/9.0.2" -r /Website --config-file @web.config`
führt ein ASP.NET-Audit in diesem Repository https://github.com/dnnsoftware/Dnn.Platform/ durch, wobei der Quellordner `/Website` als Stammverzeichnis und die Datei `web.config` als ASP.NET-Konfigurationsdatei verwendet wird. Beachten Sie, dass Dateinamen in den meisten Umgebungen zwischen Groß- und Kleinschreibung unterscheiden.
Programmoptionen
---
`-n --non-interactive` Führen Sie DevAudit im nicht-interaktiven Modus aus, wobei alle interaktiven Funktionen und Animationen der CLI deaktiviert sind. Dieser Modus ist beispielsweise erforderlich, um DevAudit in Shell-Skripten auszuführen, da es sonst zu Fehlern kommt, wenn DevAudit versucht, interaktive Konsolenfunktionen zu verwenden.
`-d --debug` Führen Sie DevAudit im Debug-Modus aus. Dadurch werden verschiedene Informations- und Diagnosemeldungen ausgegeben. Dieser Modus wird zur Fehlerbehebung bei DevAudit-Fehlern und -Bugs verwendet.
Docker-Nutzung
---
DevAudit wird auch als Docker-Container-App ausgeliefert, sodass Linux-Benutzer DevAudit ausführen können, ohne Mono installieren und aus dem Quellcode erstellen zu müssen. So ziehen Sie das DevAudit-Docker-Image von Docker Hub:
`docker pull ossindex/devaudit[:label]`
Die aktuellen Images sind etwa 131 MB komprimiert. Standardmäßig wird das mit `latest` gekennzeichnete Image gezogen, das die aktuellste Version des Programms ist. Es ist auch ein `unstable`-Image verfügbar, das den Master-Branch des Quellcodes verfolgt. So führen Sie DevAudit als Container-App aus:
docker run -i -t ossindex/devaudit TARGET [ENVIRONMENT] | [OPTIONS]
Die Docker-Optionen -i und -t sind erforderlich, um DevAudit interaktiv auszuführen. Wenn Sie diese Optionen nicht angeben, müssen Sie DevAudit im nicht-interaktiven Modus mit der DevAudit-Option -n ausführen.
Sie müssen alle Verzeichnisse auf dem Docker-Host-Rechner, auf die DevAudit zugreifen muss, auf dem DevAudit-Docker-Container mit der Docker-Option -v einbinden. Wenn Sie Ihr lokales Stammverzeichnis unter einem Mount-Punkt namens /hostroot auf dem Docker-Image einhängen, kann DevAudit auf Dateien und Verzeichnisse auf Ihrem lokalen Rechner mit denselben lokalen Pfaden zugreifen. Zum Beispiel:
`docker run -i -t -v /:/hostroot:ro ossindex/devaudit netfx -r /home/allisterb/vbot-debian/vbot.core`
ermöglicht es dem DevAudit-Docker-Container, das lokale Verzeichnis /home/allisterb/vbot-debian/vbot.core zu auditieren. Sie _müssen_ Ihr lokales Stammverzeichnis auf diese Weise einhängen, um _andere_ Docker-Container vom DevAudit-Container aus zu auditieren, z. B.
`docker run -i -t -v /:/hostroot:ro ossindex/devaudit mysql -i myapp1 -r / --config-file /etc/my.cnf --skip-packages-audit`
führt ein MySQL-Audit auf einem Docker-Container namens `myapp1` vom `ossindex/devaudit`-Container aus durch.
Wenn Sie nicht Ihr gesamtes Stammverzeichnis einhängen müssen, können Sie nur das für das Audit benötigte Verzeichnis einhängen. Zum Beispiel:
`docker run -i -t -v /home/allisterb/vbot-debian/vbot.core:/vbot:ro ossindex/devaudit netfx -r /vbot -b @bin/Debug/vbot.core.dll`
hängt das Verzeichnis `/home/allisterb/vbot-debian/vbot.core` schreibgeschützt als `/vbot` auf dem DevAudit-Container ein, sodass DevAudit es als Audit-Stammverzeichnis für ein netfx-Anwendungsaudit unter `/vbot` verwenden kann.
Wenn Sie private Schlüsseldateien auf dem lokalen Docker-Host für ein Audit über SSH verwenden möchten, können Sie Ihr Verzeichnis, das die benötigte Schlüsseldatei enthält, einhängen und DevAudit anweisen, diesen Dateipfad zu verwenden, z. B.
`docker -i -t -v /home/allisterb/.ssh:/ssh:ro run ossindex/devaudit dpkg -s localhost -u allisterb -p -k /ssh/mykey.key`
hängt das Verzeichnis mit den Schlüsseldateien unter /ssh ein und ermöglicht dem DevAudit-Container deren Verwendung.
Beachten Sie, dass es dem Docker-Container derzeit nicht möglich ist, Betriebssystem-Paketquellen wie dpkg oder rpm oder Anwendungsserver wie OpenSSH sshd auf dem _lokalen_ Docker-Host zu auditieren, ohne Ihr lokales Stammverzeichnis wie oben beschrieben unter `/hostroot` einzuhängen. DevAudit muss vom Docker-Container aus in Ihr lokales Stammverzeichnis chrooten, wenn es ausführbare Dateien wie dpkg oder Server-Binärdateien wie sshd und httpd ausführt. Sie müssen Ihr lokales Stammverzeichnis auch wie oben beschrieben einhängen, um andere Docker-Container vom DevAudit-Container aus zu auditieren, da DevAudit auch in Ihr lokales Stammverzeichnis chrooten muss, um lokale Docker-Befehle zur Kommunikation mit Ihren anderen Containern auszuführen.
Für Audits über SSH vom DevAudit-Container aus ist es nicht erforderlich, das lokale Stammverzeichnis unter `/hostroot` einzuhängen.
Fehlerbehebung
---
Wenn Sie einen Fehler oder ein anderes Problem mit DevAudit feststellen, können Sie einige Dinge aktivieren, um uns bei der Lösung zu helfen:
- Verwenden Sie die Option -d, um die Debug-Ausgabe zu aktivieren. Während des Audits werden Diagnoseinformationen ausgegeben.
- Verwenden Sie unter Linux die Variable DEVAUDIT_TRACE, um die Programmausführung zu verfolgen. Der Wert dieser Variable muss dem Format für [Mono-Tracing](http://www.mono-project.com/docs/debug+profile/debug/#tracing-program-execution) entsprechen, z. B. können Sie DEVAUDIT_TRACE=N:DevAudit.AuditLibrary setzen, um alle Aufrufe an die Audit-Bibliothek während eines Audits zu verfolgen.
Bekannte Probleme
---
- Unter Windows _müssen_ Sie die Programmoption `-n --non-interactive` verwenden, wenn Sie die Programmausgabe in eine Datei umleiten, da es sonst zu einem Absturz kommt. Dieses Verhalten kann in Zukunft geändert werden, um den nicht-interaktiven Modus zum Standard zu machen.
- Es scheint ein Problem mit der Windows-Konsolen-App [ConEmu](https://conemu.github.io/) und den Cygwin-Builds des OpenSSH-Clients zu geben, wenn Sie per SSH in entfernte Linux-Hosts einloggen, um Mono-Apps auszuführen. Wenn Sie DevAudit auf diese Weise ausführen, bemerken Sie möglicherweise manchmal seltsame Sequenzen am Ende der Konsolenausgabe. Möglicherweise haben Sie auch Probleme bei der interaktiven Tastatureingabe, z. B. bei der Eingabe von Passwörtern für SSH-Audits, bei denen das falsche Passwort gesendet zu werden scheint. Wenn Sie Probleme bei der Eingabe von Passwörtern für SSH-Audits mit ConEmu bei Remote-Arbeiten haben, versuchen Sie, die Rücktaste ein bis zwei Sekunden lang gedrückt zu halten, um den Eingabepuffer zu leeren, bevor Sie Ihr Passwort eingeben.