Outil d'audit de sécurité open source, multi-plateforme et polyvalent
Note : DevAudit utilise la base de données OSS Index, qui a certaines limites de débit. Si vous remarquez que vous atteignez la limite, veuillez signaler le problème. Les utilisateurs authentifiés bénéficient d'une limite plus élevée, et nous mettons en place l'authentification dans DevAudit prochainement. La plupart des utilisateurs non authentifiés ne remarqueront probablement pas la limite pour la plupart des cas d'utilisation. Elle ne s'applique généralement que dans les projets beaucoup plus importants ou avec des volumes de projets élevés.
Obtenez la dernière version depuis la page des versions.
DevAudit est un outil d'audit de sécurité open-source, multiplateforme et polyvalent destiné aux développeurs et aux équipes adoptant les pratiques DevOps et DevSecOps. Il détecte les vulnérabilités de sécurité à plusieurs niveaux de la pile de solution. DevAudit offre un large éventail de capacités d'audit qui automatisent les pratiques de sécurité et la mise en œuvre d'audits de sécurité dans le cycle de vie du développement logiciel. DevAudit peut analyser votre système d'exploitation et vos dépendances de paquets d'application, les configurations d'application et de serveur d'application, ainsi que le code d'application, à la recherche de vulnérabilités potentielles basées sur les données agrégées par des fournisseurs comme OSS Index et Vulners provenant d'un large éventail de sources et de flux de données tels que le flux de données CVE de la National Vulnerability Database (NVD), le flux de données des avis de sécurité Debian, les avis de sécurité Drupal, et bien d'autres.
DevAudit aide les développeurs à traiter au moins 4 des risques OWASP Top 10 pour le développement d'applications web :
ainsi que les risques classifiés par MITRE dans le dictionnaire CWE tels que CWE-2 Environment et CWE-200 Information Disclosure
Au fur et à mesure que le développement progresse et que ses capacités mûrissent, DevAudit sera en mesure de traiter les autres risques des listes OWASP Top 10 et CWE comme les injections et les XSS. Avec l'accent mis sur le web, le cloud et les applications multi-utilisateurs distribuées, le développement logiciel aujourd'hui est de plus en plus complexe, avec des problèmes de sécurité et des vulnérabilités potentielles apparaissant à tous les niveaux de la pile sur laquelle les développeurs s'appuient pour fournir des applications. L'objectif de DevAudit est de fournir une plateforme pour automatiser la mise en œuvre de revues de sécurité de développement et de meilleures pratiques à tous les niveaux de la pile de solution, des dépendances de paquets de bibliothèques à la configuration des applications et des serveurs, en passant par le code source.
Multiplateforme avec une image Docker également disponible. DevAudit fonctionne sous Windows et Linux, avec la prise en charge prévue de *BSD, Mac et ARM Linux. Seule une version à jour de .NET ou Mono est requise pour exécuter DevAudit. Une image Docker DevAudit peut également être extraite de Docker Hub et exécutée sans avoir à installer Mono.
Interface CLI. DevAudit dispose d'une interface CLI avec une option pour une sortie non interactive et peut être facilement intégré dans les pipelines de build CI ou comme tâches en ligne de commande post-build dans les IDE des développeurs. Le travail d'intégration de la bibliothèque d'audit principale dans les GUI IDE a déjà commencé avec l'extension Visual Studio Audit.Net.
Données de vulnérabilités mises à jour en continu. DevAudit utilise des fournisseurs de données backend comme OSS Index et Vulners qui fournissent des données de vulnérabilités mises à jour en continu, compilées à partir d'un large éventail de flux et sources de données de sécurité tels que les flux CVE de la NVD, les avis de sécurité Drupal, etc. La prise en charge de fournisseurs supplémentaires de données de vulnérabilités et de paquets comme vFeed et Libraries.io sera ajoutée.
Auditer le système d'exploitation et les dépendances de paquets de développement. DevAudit audite les applications Windows et les paquets installés via Windows MSI, Chocolatey et OneGet, ainsi que les paquets Linux Debian, Ubuntu et CentOS installés via Dpkg, RPM et YUM, pour détecter les vulnérabilités signalées pour des versions spécifiques des applications et des paquets. Pour les dépendances de paquets et bibliothèques de développement, DevAudit audite les dépendances NuGet v2 pour .NET, les dépendances Yarn/NPM et Bower pour nodejs, et les dépendances Composer pour PHP. La prise en charge d'autres gestionnaires de paquets pour différents langages est ajoutée régulièrement.
Auditer les configurations de serveurs d'application. DevAudit audite la version du serveur et la configuration du serveur pour les serveurs OpenSSH sshd, Apache httpd, MySQL/MariaDB, PostgreSQL et Nginx, avec beaucoup d'autres à venir. L'audit de configuration est basé sur la bibliothèque Alpheus et est effectué en utilisant une analyse syntaxique complète des fichiers de configuration du serveur. Les règles de configuration du serveur sont stockées dans des fichiers texte YAML et peuvent être personnalisées selon les besoins des développeurs. La prise en charge de beaucoup plus de serveurs et applications et de types d'analyse comme l'audit de base de données est ajoutée régulièrement.
Auditer les configurations d'application. DevAudit audite les applications Microsoft ASP.NET et détecte les vulnérabilités présentes dans la configuration de l'application. Les règles de configuration d'application sont stockées dans des fichiers texte YAML et peuvent être personnalisées selon les besoins des développeurs. L'audit de configuration d'application pour des applications comme Drupal, WordPress et DNN CMS est à venir.
Auditer le code d'application par analyse statique. DevAudit prend actuellement en charge l'analyse statique du bytecode .NET CIL. Les analyseurs résident dans des fichiers de script externes et peuvent être entièrement personnalisés en fonction des besoins du développeur. La prise en charge de l'analyse de code source C# via Roslyn, du code source PHP7 et de nombreux autres langages et outils d'analyse de code statique externes est à venir.
Audit à distance sans agent. DevAudit peut se connecter à des hôtes distants via SSH avec des fonctionnalités d'audit identiques disponibles dans les environnements distants comme dans les environnements locaux. Une connexion SSH valide est la seule exigence pour auditer des hôtes distants, et DevAudit fonctionnant sous Windows peut se connecter et auditer des hôtes Linux via SSH. Sous Windows, DevAudit peut également se connecter à distance et auditer d'autres machines Windows en utilisant WinRM.
Audit de conteneurs Docker sans agent. DevAudit peut auditer des conteneurs Docker en cours d'exécution à partir de l'hôte Docker avec des fonctionnalités identiques disponibles dans les environnements conteneurisés comme dans les environnements locaux.
Audit de dépôts GitHub. DevAudit peut se connecter directement à un dépôt de projet hébergé sur GitHub et effectuer un audit de source de paquets et de configuration d'application.
Prise en charge de PowerShell. DevAudit peut également être exécuté dans l'environnement d'administration système PowerShell en tant que cmdlets. Le travail sur la prise en charge de PowerShell est actuellement en pause, mais reprendra dans un avenir proche avec la prise en charge de PowerShell multiplateforme à la fois sur Windows et Linux.
DevAudit est une application .NET 4.6. Pour l'installer localement sur votre machine, vous aurez besoin soit du runtime Microsoft .NET Framework 4.6 sous Windows, soit de Mono 4.4+ sous Linux. .NET 4.6 devrait déjà être installé sur la plupart des versions récentes de Windows ; sinon, il est disponible en tant que fonctionnalité Windows qui peut être activée ou installée à partir de l'applet du Panneau de configuration Programmes et fonctionnalités sur les versions grand public de Windows, ou à partir de l'option Ajouter des rôles et fonctionnalités dans le Gestionnaire de serveur sur les versions serveur de Windows. Pour les versions plus anciennes de Windows, le programme d'installation .NET 4.6 de Microsoft peut être trouvé ici.
Sous Linux, la version minimale de Mono prise en charge est 4.4. Bien que DevAudit fonctionne sur Mono 4 (avec un problème connu), il est recommandé d'installer Mono 5. Mono 5 apporte de nombreuses améliorations aux composants de build et d'exécution de Mono qui profitent à DevAudit.
Les paquets Mono existants fournis par votre distribution ne sont probablement pas encore Mono 5, vous devrez donc installer les paquets Mono manuellement pour pouvoir utiliser Mono 5. Les instructions d'installation pour les paquets les plus récents fournis par le projet Mono pour plusieurs distributions Linux majeures sont ici. Il est recommandé d'installer le paquet mono-devel car cela réduira les risques d'assemblages manquants.
Sinon, sous Linux, vous pouvez utiliser l'image Docker DevAudit si vous ne souhaitez pas installer Mono et avez déjà Docker installé sur votre machine.
DevAudit peut être installé par les méthodes suivantes :
Prérequis : Mono 4.4+ (Mono 5 recommandé) et le paquet mono-devel qui fournit le compilateur et d'autres outils nécessaires à la compilation des applications Mono. Votre distribution devrait avoir des paquets pour au moins Mono version 4.4 et supérieure, sinon les instructions d'installation manuelle pour les paquets les plus récents fournis par le projet Mono pour plusieurs distributions Linux majeures sont ici
Clonez le dépôt DevAudit depuis https://github.com/OSSIndex/DevAudit.git
Exécutez le script build.sh dans le répertoire racine de DevAudit. DevAudit devrait se compiler sans erreurs.
Exécutez ./devaudit --help et vous devriez voir la version de DevAudit et l'écran d'aide s'afficher.
Notez que NuGet sur Linux peut parfois se terminer avec Error: NameResolutionFailure, ce qui semble être un problème transitoire de connexion aux serveurs contenant les paquets NuGet. Vous devez simplement réexécuter ./build.sh jusqu'à ce que la compilation se termine normalement.
Prérequis : Vous devez avoir l'un des éléments suivants :
Clonez le dépôt DevAudit depuis https://github.com/OSSIndex/DevAudit.git
Depuis un Visual Studio 2015 ou .NET, exécutez le script build.cmd dans le répertoire racine de DevAudit. DevAudit devrait se compiler sans erreurs.
Exécutez ./devaudit --help et vous devriez voir la version de DevAudit et l'écran d'aide s'afficher.
Prérequis : Vous devez avoir Mono 4.4+ sur Linux ou .NET 4.6 sur Windows.
Téléchargez le dernier fichier d'archive de version pour Windows ou Linux depuis la page des versions du projet. Décompressez ce fichier dans un répertoire.
Depuis le répertoire où vous avez décompressé l'archive de version, exécutez devaudit --help sur Windows ou ./devaudit --help sur Linux. Vous devriez voir la version et l'écran d'aide s'afficher.
(Facultatif) Ajoutez le répertoire d'installation de DevAudit à votre variable d'environnement PATH
Le programme d'installation MSI pour une version se trouve sur la page des versions Github.
DevAudit est également disponible sur Chocolatey.
choco install devauditExtrayez l'image Devaudit depuis Docker Hub : docker pull ossindex/devaudit. L'image taguée ossindex/devaudit:latest (qui est l'image par défaut téléchargée) est construite à partir de la version la plus récente tandis que ossindex/devaudit:unstable est construite sur la branche master du code source et contient les ajouts les plus récents, bien qu'avec moins de tests.
Représente un groupe logique de fonctions d'audit. DevAudit prend actuellement en charge les cibles d'audit suivantes :
Représente un environnement logique où les audits contre les cibles d'audit sont exécutés. Les environnements d'audit abstraient les E/S et les exécutions de commandes nécessaires pour un audit et permettent d'effectuer des fonctions identiques contre des cibles d'audit sur tout emplacement physique ou réseau où les fichiers et exécutables de la cible se trouvent. Les environnements suivants sont actuellement pris en charge :
Ce sont différentes options qui peuvent être activées pour l'audit. Vous pouvez spécifier des options qui s'appliquent au programme DevAudit, par exemple, pour fonctionner en mode non interactif, ainsi que des options qui s'appliquent à la cible, par exemple si vous définissez l'option AppDevMode pour l'audit d'applications ASP.NET sur true, certaines règles d'audit ne seront pas activées.
L'interface CLI est l'interface principale du programme DevAudit et convient à la fois pour une utilisation interactive et non interactive dans des tâches planifiées, des scripts shell, des pipelines de build CI et des tâches post-build dans les IDE des développeurs. La syntaxe de base de la CLI DevAudit est :
devaudit TARGET [ENVIRONMENT] | [OPTIONS]
où TARGET spécifie la cible d'audit, ENVIRONMENT spécifie l'environnement d'audit et OPTIONS spécifie les options pour la cible d'audit et l'environnement. Il y a 2 façons de spécifier les options : les options du programme et les options générales d'audit qui s'appliquent à plus d'une cible peuvent être spécifiées directement sur la ligne de commande en tant que paramètres. Les options spécifiques à la cible peuvent être spécifiées avec l'option -o en utilisant le format : -o OPTION1=VALEUR1,OPTION2=VALEUR2,.... avec des virgules délimitant chaque paire clé-valeur d'option.
Si vous redirigez la sortie du programme vers un fichier, vous devez toujours utiliser l'option -n --non-interactive pour désactiver toutes les fonctionnalités d'interface utilisateur interactives et les animations.
Lors de la spécification de chemins de fichiers, un préfixe @ avant un chemin indique à DevAudit que ce chemin est relatif au répertoire racine de la cible d'audit. Par exemple, si vous spécifiez :
-r c:\monprojet -b @bin\Debug\app2.exe
DevAudit considère le chemin du fichier binaire comme c:\monprojet\bin\Debug\app2.exe.
msi Effectuer un audit de paquets de la source de paquets Windows Installer MSI sur les machines Windows.
npm Effectuer un audit de paquets du package.json NPM.
choco Effectuer un audit de paquets installés par le gestionnaire de paquets Choco.
oneget Effectuer un audit de paquets de la source de paquets OneGet système sur Windows.
nuget Effectuer un audit de paquets d'une source de paquets NuGet v2. Vous devez spécifier l'emplacement du fichier packages.config NuGet que vous souhaitez auditer à l'aide de l'option -f ou --file, sinon le répertoire courant sera recherché pour ce fichier.
bower Effectuer un audit de paquets d'une source de paquets Bower. Vous devez spécifier l'emplacement du fichier packages.json Bower que vous souhaitez auditer à l'aide de l'option -f ou --file, sinon le répertoire courant sera recherché pour ce fichier.- composer Effectuer un audit de paquets d'une source de paquets Composer. Vous devez spécifier l'emplacement du fichier composer.json de Composer que vous souhaitez auditer à l'aide de l'option -f ou --file, sinon le répertoire courant sera recherché pour ce fichier.
dpkg Effectuer un audit de paquets de la source de paquets système dpkg sur Debian Linux et ses dérivés.
rpm Effectuer un audit de paquets de la source de paquets système RPM sur RedHat Linux et ses dérivés.
yum Effectuer un audit de paquets de la source de paquets système Yum sur RedHat Linux et ses dérivés.
Pour chaque source de paquets, les options d'audit générales suivantes peuvent être utilisées :
-f --file Spécifie l'emplacement du fichier de configuration du gestionnaire de paquets si nécessaire. Les sources de paquets NuGet, Bower et Composer nécessitent cette option.
--list-packages Lister uniquement les paquets dans la source de paquets scannée par DevAudit.
--list-artifacts Lister uniquement les artefacts trouvés sur OSS Index pour les paquets scannés par DevAudit.
Les sources de paquets marquées [Expérimental] ne sont disponibles que dans la branche master du code source et peuvent avoir un support limité du back-end OSS Index. Cependant, vous pouvez toujours lister les paquets scannés et les artefacts disponibles sur OSS Index en utilisant les options list-packages et list-artifacts.
aspnet Effectuer un audit d'application sur une application ASP.NET. Les options pertinentes sont :
-r --root-directory Spécifie le répertoire racine de l'application. C'est simplement le répertoire de plus haut niveau de l'application qui contient des fichiers comme Global.asax et Web.config.-b --application-binary Spécifie le binaire de l'application. Il s'agit de l'assembly .NET qui contient le bytecode .NET de l'application. Ce fichier est généralement un .DLL et se trouve dans le sous-dossier bin du répertoire racine de l'application ASP.NET.--config-file ou -o AppConfig=fichier-de-configuration Spécifie le fichier de configuration de l'application ASP.NET. Ce fichier est généralement nommé Web.config et se trouve dans le répertoire racine de l'application. Vous pouvez remplacer la valeur par défaut @Web.config avec cette option.-o AppDevMode=enabled Spécifie que le mode de développement de l'application doit être activé pour l'audit. Ce mode peut être utilisé lors de l'audit d'une application en développement. Certaines règles de configuration qui sont marquées comme désactivées pour AppDevMode (par exemple, exécuter l'application en mode débogage ASP.NET) ne seront pas activées pendant l'audit.netfx Effectuer un audit d'application sur une application .NET. Les options pertinentes sont :
-r --root-directory Spécifie le répertoire racine de l'application. C'est simplement le répertoire de plus haut niveau de l'application qui contient des fichiers comme App.config.-b --application-binary Spécifie le binaire de l'application. Il s'agit de l'assembly .NET qui contient le bytecode .NET de l'application. Ce fichier est généralement un .DLL et se trouve dans le sous-dossier bin du répertoire racine de l'application ASP.NET.--config-file ou -o AppConfig=fichier-de-configuration Spécifie le fichier de configuration de l'application .NET. Ce fichier est généralement nommé App.config et se trouve dans le répertoire racine de l'application. Vous pouvez remplacer la valeur par défaut @App.config avec cette option.-o GendarmeRules=RuleLibrary Spécifie que l'analyseur statique Gendarme doit être activé pour l'audit avec les règles de la bibliothèque de règles spécifiée. Par exemple :
devaudit netfx -r /home/allisterb/vbot-debian/vbot.core -b @bin/Debug/vbot.core.dll --skip-packages-audit -o GendarmeRules=Gendarme.Rules.Naming
exécutera l'analyseur statique Gendarme sur l'assembly vbot.core.dll en utilisant les règles de la bibliothèque Gendarme.Rules.Naming. La liste complète des bibliothèques de règles est (tirée du wiki Gendarme) :drupal7 Effectuer un audit d'application sur une application Drupal 7.
-r --root-directory Spécifie le répertoire racine de l'application. C'est simplement le répertoire de plus haut niveau de votre installation Drupal 7.drupal8 Effectuer un audit d'application sur une application Drupal 8.
-r --root-directory Spécifie le répertoire racine de l'application. C'est simplement le répertoire de plus haut niveau de votre installation Drupal 8.Toutes les applications supportent également les options communes suivantes pour auditer les modules ou plugins de l'application :
--list-packages Lister uniquement les plugins ou modules d'application scannés par DevAudit.
--list-artifacts Lister uniquement les artefacts trouvés sur OSS Index pour les plugins et modules d'application scannés par DevAudit.
--skip-packages-audit Effectuer uniquement un audit de configuration ou d'analyse de code de l'application et ignorer l'audit des paquets.
sshd Effectuer un audit de serveur d'applications sur un serveur compatible OpenSSH sshd.
httpd Effectuer un audit de serveur d'applications sur un serveur compatible Apache httpd.
mysql Effectuer un audit de serveur d'applications sur un serveur compatible MySQL (comme MariaDB ou Oracle MySQL.)
nginx Effectuer un audit de serveur d'applications sur un serveur Nginx.
pgsql Effectuer un audit de serveur d'applications sur un serveur PostgreSQL.
Voici un exemple de ligne de commande pour un audit de serveur d'applications :
./devaudit httpd -i httpd-2.2 -r /usr/local/apache2/ --config-file @conf/httpd.conf -b @bin/httpd
qui audite un serveur Apache Httpd s'exécutant sur un conteneur Docker nommé httpd-2.2.
Les options d'audit suivantes sont communes à tous les serveurs d'applications :
-r --root-directory Spécifie le répertoire racine du serveur. C'est simplement le plus haut niveau de votre système de fichiers serveur et par défaut / sauf si vous souhaitez une racine de serveur différente.--config-file Spécifie le fichier de configuration du serveur. Par exemple, dans l'audit ci-dessus, le fichier de configuration Apache se trouve à /usr/local/apache2/conf/httpd.conf. Si vous ne spécifiez pas le fichier de configuration, DevAudit tentera de le détecter automatiquement pour le serveur sélectionné.-b --application-binary Spécifie le binaire du serveur. Par exemple, dans l'audit ci-dessus, le binaire Apache se trouve à /usr/local/apache2/bin/httpd. Si vous ne spécifiez pas le chemin du binaire, DevAudit tentera de le détecter automatiquement pour le serveur sélectionné.Les serveurs d'applications supportent également les options communes suivantes pour auditer les modules ou plugins du serveur :
--list-packages Lister uniquement les plugins ou modules d'application scannés par DevAudit.
--list-artifacts Lister uniquement les artefacts trouvés sur OSS Index pour les plugins et modules d'application scannés par DevAudit.
--skip-packages-audit Effectuer uniquement un audit de configuration du serveur et ignorer l'audit des paquets.
Il y a actuellement 5 environnements d'audit supportés : local, hôtes distants via SSH, hôtes distants via WinRM, conteneurs Docker et GitHub. Les environnements locaux sont utilisés par défaut lorsqu'aucune autre option d'environnement n'est spécifiée.
L'environnement SSH permet d'effectuer des audits sur n'importe quel hôte distant accessible via SSH sans nécessiter l'installation de DevAudit sur l'hôte distant. Les environnements SSH sont multiplateformes : vous pouvez vous connecter à un hôte distant Linux à partir d'une machine Windows exécutant DevAudit. Un environnement SSH est créé par les options suivantes :-s SERVER [--ssh-port PORT] -u USER [-k KEYFILE] [-p | --password-text PASSWORD]
-s SERVER Spécifie l'hôte distant ou l'IP auquel se connecter via SSH.
-u USER Spécifie l'utilisateur avec lequel se connecter au serveur.
--ssh-port PORT Spécifie le port sur l'hôte distant auquel se connecter. La valeur par défaut est 22.
-k KEYFILE Spécifie le fichier de clé privée compatible OpenSSH à utiliser pour se connecter au serveur distant. Actuellement, seules les clés RSA ou DSA dans des fichiers au format PEM sont supportées.
-p Fournit une invite avec écho local désactivé pour la saisie interactive du mot de passe du serveur ou de la phrase de passe du fichier de clé.
--password-text PASSWORD Spécifie le mot de passe utilisateur ou la phrase de passe du fichier de clé en texte clair sur la ligne de commande. Notez que sous Linux, lorsque votre mot de passe contient des caractères spéciaux, vous devez entourer le texte sur la ligne de commande avec des guillemets simples comme 'MyPa<ss' pour éviter que le shell n'interprète les caractères spéciaux.
L'environnement WinRM permet d'effectuer des audits sur n'importe quel hôte distant Windows accessible via WinRM sans nécessiter l'installation de DevAudit sur l'hôte distant. Les environnements WinRM ne sont actuellement disponibles que sur les machines Windows exécutant DevAudit. Un environnement WinRM est créé par les options suivantes :-w IP -u USER [-p | --password-text PASSWORD]
-w IP Spécifie l'IP distante à laquelle se connecter via WinRM.
-u USER Spécifie l'utilisateur avec lequel se connecter au serveur.
-p Fournit une invite avec écho local désactivé pour la saisie interactive du mot de passe du serveur ou de la phrase de passe du fichier de clé.
--password-text PASSWORD Spécifie le mot de passe du serveur ou la phrase de passe du fichier de clé en texte clair sur la ligne de commande.
Cette section explique comment auditer des images Docker à l'aide de DevAudit installé sur la machine locale. Pour exécuter DevAudit en tant qu'application Docker conteneurisée, voir la section ci-dessous sur l'utilisation de Docker.
Un environnement d'audit Docker est spécifié par l'option suivante : -i CONTAINER_NAME | -i CONTAINER_ID
CONTAINER_(NAME|ID) Spécifie le nom ou l'ID d'un conteneur Docker en cours d'exécution auquel se connecter. Le conteneur doit déjà être en cours d'exécution car DevAudit ne sait pas comment démarrer le conteneur avec le nom ou l'état que vous souhaitez.
L'environnement d'audit GitHub permet d'effectuer des audits directement sur un dépôt de projet GitHub. Un environnement GitHub est créé par l'option -g : -g "Owner=PROPRIÉTAIRE,Name=NOM,Branch=BRANCHE"
OWNER Spécifie le propriétaire du projet
NAME Spécifie le nom du projet
PATH Spécifie la branche du projet à laquelle se connecter
Vous pouvez utiliser les options -r, --config-file et -f comme d'habitude pour spécifier le chemin des fichiers et répertoires du système de fichiers nécessaires à l'audit. Par exemple, la commande suivante :
devaudit aspnet -g "Owner=Dnnsoftware,Name=Dnn.Platforn,Branch=Release/9.0.2" -r /Website --config-file @web.config
effectuera un audit ASP.NET sur ce dépôt https://github.com/dnnsoftware/Dnn.Platform/ en utilisant le dossier source /Website comme répertoire racine et le fichier web.config comme fichier de configuration ASP.NET. Notez que les noms de fichiers sont sensibles à la casse dans la plupart des environnements.
-n --non-interactive Exécute DevAudit en mode non interactif avec toutes les fonctionnalités interactives et animations de la CLI désactivées. Ce mode est nécessaire pour exécuter DevAudit dans des scripts shell par exemple, sinon des erreurs se produiront lorsque DevAudit tentera d'utiliser des fonctionnalités interactives de la console.
-d --debug Exécute DevAudit en mode débogage. Cela affichera une variété de messages informatifs et de diagnostic. Ce mode est utilisé pour résoudre les erreurs et bogues de DevAudit.
DevAudit est également fourni en tant qu'application Docker conteneurisée, ce qui permet aux utilisateurs sous Linux d'exécuter DevAudit sans avoir à installer Mono et à construire à partir des sources. Pour tirer l'image Docker DevAudit depuis Docker Hub :
docker pull ossindex/devaudit[:label]
Les images actuelles font environ 131 Mo compressées. Par défaut, l'image étiquetée latest est tirée, qui est la version la plus récente du programme. Une image unstable est également disponible, qui suit la branche master du code source. Pour exécuter DevAudit en tant qu'application conteneurisée :
docker run -i -t ossindex/devaudit TARGET [ENVIRONMENT] | [OPTIONS]
Les options Docker -i et -t sont nécessaires pour exécuter DevAudit de manière interactive. Si vous ne spécifiez pas ces options, vous devez exécuter DevAudit en mode non interactif en utilisant l'option DevAudit -n.
Vous devez monter tous les répertoires sur la machine hôte Docker auxquels DevAudit a besoin d'accéder sur le conteneur Docker DevAudit à l'aide de l'option Docker -v. Si vous montez votre répertoire racine local à un point de montage nommé /hostroot sur l'image Docker, alors DevAudit peut accéder aux fichiers et répertoires de votre machine locale en utilisant les mêmes chemins locaux. Par exemple :
docker run -i -t -v /:/hostroot:ro ossindex/devaudit netfx -r /home/allisterb/vbot-debian/vbot.core
permettra au conteneur Docker DevAudit d'auditer le répertoire local /home/allisterb/vbot-debian/vbot.core. Vous devez monter votre racine locale de cette manière pour auditer d'autres conteneurs Docker à partir du conteneur DevAudit, par exemple :
docker run -i -t -v /:/hostroot:ro ossindex/devaudit mysql -i myapp1 -r / --config-file /etc/my.cnf --skip-packages-audit
exécutera un audit MySQL sur un conteneur Docker nommé myapp1 à partir du conteneur ossindex/devaudit.
Si vous n'avez pas besoin de monter tout votre répertoire racine, vous pouvez monter uniquement le répertoire nécessaire à l'audit. Par exemple :
docker run -i -t -v /home/allisterb/vbot-debian/vbot.core:/vbot:ro ossindex/devaudit netfx -r /vbot -b @bin/Debug/vbot.core.dll
montera en lecture seule le répertoire /home/allisterb/vbot-debian/vbot.core en tant que /vbot sur le conteneur DevAudit, ce qui permet à DevAudit d'y accéder comme répertoire racine d'audit pour un audit d'application netfx à /vbot.
Si vous souhaitez utiliser des fichiers de clé privée sur l'hôte Docker local pour un audit via SSH, vous pouvez monter votre répertoire contenant le fichier de clé nécessaire, puis indiquer à DevAudit d'utiliser ce chemin de fichier, par exemple :
docker -i -t -v /home/allisterb/.ssh:/ssh:ro run ossindex/devaudit dpkg -s localhost -u allisterb -p -k /ssh/mykey.key
montera le répertoire contenant les fichiers de clé à /ssh et permettra au conteneur DevAudit de les utiliser.
Notez qu'il n'est actuellement pas possible pour le conteneur Docker d'auditer les sources de paquets du système d'exploitation comme dpkg ou rpm ou les serveurs d'applications comme OpenSSH sshd sur l'hôte Docker local sans monter votre répertoire racine local à /hostroot comme décrit ci-dessus. DevAudit doit chrooter dans votre répertoire racine local à partir du conteneur Docker lors de l'exécution d'exécutables comme dpkg ou de binaires de serveur comme sshd et httpd. Vous devez également monter votre racine locale comme décrit ci-dessus pour auditer d'autres conteneurs Docker à partir du conteneur DevAudit, car DevAudit a également besoin de chrooter dans votre racine locale pour exécuter des commandes Docker locales afin de communiquer avec vos autres conteneurs.
Pour exécuter des audits via SSH à partir du conteneur DevAudit, il n'est pas nécessaire de monter la racine locale à /hostroot.
Si vous rencontrez un bogue ou un autre problème avec DevAudit, vous pouvez activer certaines choses pour nous aider à le résoudre :
-n --non-interactive lorsque vous redirigez la sortie du programme vers un fichier, sinon un plantage se produira. Ce comportement pourrait être modifié à l'avenir pour faire du mode non interactif le mode par défaut.