Ferramenta de auditoria de segurança de código aberto, multiplataforma e multipropósito
Nota: O DevAudit utiliza a base de dados OSS Index, que possui alguns limites de taxa. Se notar que está a atingir o limite, por favor, abra uma issue. Utilizadores autenticados têm um limite mais alto, e estamos a implementar a autenticação no DevAudit em breve. A maioria dos utilizadores não autenticados provavelmente não notará o limite para muitos casos de uso. Geralmente, só se aplica em projetos muito grandes ou com volumes elevados.
Obtenha a versão mais recente na página de releases.
O DevAudit é uma ferramenta de auditoria de segurança open-source, multiplataforma e multi-propósito, direcionada a programadores e equipas que adotam DevOps e DevSecOps, que deteta vulnerabilidades de segurança em vários níveis da pilha de soluções. O DevAudit fornece uma vasta gama de capacidades de auditoria que automatizam práticas de segurança e a implementação de auditorias de segurança no ciclo de vida de desenvolvimento de software. O DevAudit pode analisar as dependências de pacotes do sistema operativo e da aplicação, as configurações da aplicação e do servidor de aplicações, e o código da aplicação, em busca de potenciais vulnerabilidades com base em dados agregados por fornecedores como OSS Index e Vulners a partir de uma ampla variedade de fontes e feeds de dados, como o feed de dados CVE da National Vulnerability Database (NVD), o feed de dados do Debian Security Advisories, o Drupal Security Advisories, entre muitos outros.
O DevAudit ajuda os programadores a abordar pelo menos 4 dos riscos OWASP Top 10 no desenvolvimento de aplicações web:
assim como riscos classificados pela MITRE no dicionário CWE, como CWE-2 Ambiente e CWE-200 Divulgação de Informação
À medida que o desenvolvimento avança e as suas capacidades amadurecem, o DevAudit conseguirá abordar os outros riscos das listas OWASP Top 10 e CWE, como Injeção e XSS. Com o foco em aplicações web, cloud e multiutilizador distribuídas, o desenvolvimento de software hoje é cada vez mais complexo, com problemas de segurança e potenciais vulnerabilidades a surgir em todos os níveis da pilha em que os programadores confiam para entregar aplicações. O objetivo do DevAudit é fornecer uma plataforma para automatizar a implementação de revisões de segurança de desenvolvimento e melhores práticas em todos os níveis da pilha de soluções, desde dependências de pacotes de bibliotecas até à configuração de aplicações e servidores, passando pelo código-fonte.
Multiplataforma com uma imagem Docker também disponível. O DevAudit funciona no Windows e Linux, com suporte planeado para *BSD, Mac e ARM Linux. Apenas é necessária uma versão atualizada do .NET ou Mono para executar o DevAudit. Uma imagem Docker do DevAudit pode também ser obtida do Docker Hub e executada sem necessidade de instalar o Mono.
Interface CLI. O DevAudit tem uma interface CLI com uma opção para saída não interativa, podendo ser facilmente integrado em pipelines de CI ou como tarefas de linha de comandos pós-compilação em IDEs de programadores. O trabalho de integração da biblioteca principal de auditoria em GUIs de IDE já começou com a extensão Audit.Net para Visual Studio.
Dados de vulnerabilidades continuamente atualizados. O DevAudit utiliza fornecedores de dados backend como OSS Index e Vulners que fornecem dados de vulnerabilidades continuamente atualizados, compilados a partir de uma ampla gama de feeds e fontes de dados de segurança, como os feeds CVE da NVD, Drupal Security Advisories, entre outros. Será adicionado suporte para fornecedores adicionais de vulnerabilidades e dados de pacotes, como vFeed e Libraries.io.
Auditar dependências de pacotes do sistema operativo e de desenvolvimento. O DevAudit audita as aplicações e pacotes Windows instalados via Windows MSI, Chocolatey e OneGet, bem como pacotes Linux Debian, Ubuntu e CentOS instalados via Dpkg, RPM e YUM, à procura de vulnerabilidades reportadas para versões específicas das aplicações e pacotes. Para dependências de pacotes de desenvolvimento e bibliotecas, o DevAudit audita dependências NuGet v2 para .NET, dependências Yarn/NPM e Bower para Node.js, e dependências de pacotes Composer para PHP. O suporte para outros gestores de pacotes para diferentes linguagens é adicionado regularmente.
Auditar configurações de servidores de aplicações. O DevAudit audita a versão do servidor e a configuração do servidor para os servidores OpenSSH sshd, Apache httpd, MySQL/MariaDB, PostgreSQL e Nginx, com muitos mais a caminho. A auditoria de configuração é baseada na biblioteca Alpheus e é feita utilizando análise sintática completa dos ficheiros de configuração do servidor. As regras de configuração do servidor são armazenadas em ficheiros de texto YAML e podem ser personalizadas de acordo com as necessidades dos programadores. O suporte para muito mais servidores e aplicações, bem como tipos de análise como auditoria de bases de dados, é adicionado regularmente.
Auditar configurações de aplicações. O DevAudit audita aplicações Microsoft ASP.NET e deteta vulnerabilidades presentes na configuração da aplicação. As regras de configuração da aplicação são armazenadas em ficheiros de texto YAML e podem ser personalizadas de acordo com as necessidades dos programadores. A auditoria de configuração de aplicações para aplicações como Drupal, WordPress e DNN CMS está a caminho.
Auditar código da aplicação por análise estática. O DevAudit atualmente suporta análise estática de bytecode CIL .NET. Os analisadores residem em ficheiros de script externos e podem ser totalmente personalizados com base nas necessidades do programador. O suporte para análise de código-fonte C# via Roslyn, código-fonte PHP7 e muitas outras linguagens e ferramentas externas de análise de código estático está a caminho.
Auditoria remota sem agente. O DevAudit pode conectar-se a anfitriões remotos via SSH, com funcionalidades de auditoria idênticas disponíveis em ambientes remotos como em ambientes locais. Apenas é necessário um login SSH válido para auditar anfitriões remotos, e o DevAudit em execução no Windows pode conectar-se e auditar anfitriões Linux via SSH. No Windows, o DevAudit também pode conectar-se remotamente e auditar outras máquinas Windows usando WinRM.
Auditoria de contentores Docker sem agente. O DevAudit pode auditar contentores Docker em execução a partir do anfitrião Docker, com funcionalidades idênticas disponíveis em ambientes de contentores como em ambientes locais.
Auditoria de repositórios GitHub. O DevAudit pode conectar-se diretamente a um repositório de projeto alojado no GitHub e realizar auditoria de fonte de pacotes e configuração de aplicações.
Suporte PowerShell. O DevAudit também pode ser executado dentro do ambiente de administração de sistemas PowerShell como cmdlets. O trabalho no suporte PowerShell está atualmente pausado, mas será retomado num futuro próximo com suporte para PowerShell multiplataforma tanto no Windows como no Linux.
O DevAudit é uma aplicação .NET 4.6. Para instalar localmente na sua máquina, necessitará do runtime Microsoft .NET Framework 4.6 no Windows, ou Mono 4.4+ no Linux. O .NET 4.6 já deve estar instalado na maioria das versões recentes do Windows; se não estiver, está disponível como uma funcionalidade do Windows que pode ser ativada ou instalada a partir do applet Programas e Funcionalidades no Painel de Controlo no Windows para consumidores, ou a partir da opção Adicionar Funções e Funcionalidades no Gestor do Servidor em versões Windows Server. Para versões mais antigas do Windows, o instalador do .NET 4.6 da Microsoft pode ser encontrado aqui.
No Linux, a versão mínima suportada do Mono é a 4.4. Embora o DevAudit funcione no Mono 4 (com um problema conhecido), recomenda-se a instalação do Mono 5. O Mono 5 traz muitas melhorias nos componentes de compilação e runtime do Mono que beneficiam o DevAudit.
Os pacotes Mono existentes fornecidos pela sua distribuição provavelmente ainda não são Mono 5, por isso terá de instalar manualmente os pacotes Mono para poder usar o Mono 5. As instruções de instalação para os pacotes mais recentes fornecidos pelo projeto Mono para várias distribuições Linux importantes estão aqui. Recomenda-se que tenha o pacote mono-devel instalado, pois isso reduzirá a probabilidade de faltarem assemblies.
Alternativamente, no Linux, pode usar a imagem Docker do DevAudit se não desejar instalar o Mono e já tiver o Docker instalado na sua máquina.
O DevAudit pode ser instalado pelos seguintes métodos:
Pré-requisitos: Mono 4.4+ (Mono 5 recomendado) e o pacote mono-devel, que fornece o compilador e outras ferramentas necessárias para compilar aplicações Mono. A sua distribuição deve ter pacotes para pelo menos Mono versão 4.4 ou superior; caso contrário, as instruções de instalação manual para os pacotes mais recentes fornecidos pelo projeto Mono para várias distribuições Linux importantes estão aqui.
Clone o repositório DevAudit de https://github.com/OSSIndex/DevAudit.git
Execute o script build.sh no diretório raiz do DevAudit. O DevAudit deve compilar sem erros.
Execute ./devaudit --help e deverá ver a versão do DevAudit e o ecrã de ajuda.
Note que o NuGet no Linux pode ocasionalmente sair com Error: NameResolutionFailure, o que parece ser um problema transitório ao contactar os servidores que contêm os pacotes NuGet. Basta executar novamente o ./build.sh até a compilação ser concluída normalmente.
Pré-requisitos: Deve ter um dos seguintes:
Clone o repositório DevAudit de https://github.com/OSSIndex/DevAudit.git
A partir de um Visual Studio 2015 ou .NET, execute o script build.cmd no diretório raiz do DevAudit. O DevAudit deve compilar sem erros.
Execute ./devaudit --help e deverá ver a versão do DevAudit e o ecrã de ajuda.
Pré-requisitos: Deve ter Mono 4.4+ no Linux ou .NET 4.6 no Windows.
Descarregue o ficheiro de arquivo de lançamento mais recente para Windows ou Linux na página de releases do projeto. Descompacte este ficheiro para um diretório.
A partir do diretório onde descompactou o arquivo de lançamento, execute devaudit --help no Windows ou ./devaudit --help no Linux. Deverá ver a versão e o ecrã de ajuda.
(Opcional) Adicione o diretório de instalação do DevAudit à variável de ambiente PATH.
O instalador MSI para um lançamento pode ser encontrado na página de releases do Github.
O DevAudit também está disponível no Chocolatey.
choco install devauditObtenha a imagem DevAudit do Docker Hub: docker pull ossindex/devaudit. A imagem com a tag ossindex/devaudit:latest (que é a imagem predefinida descarregada) é compilada a partir do lançamento mais recente, enquanto ossindex/devaudit:unstable é compilada a partir do branch master do código-fonte e contém as adições mais recentes, embora com menos testes.
Representa um grupo lógico de funções de auditoria. O DevAudit atualmente suporta os seguintes alvos de auditoria:
Representa um ambiente lógico onde as auditorias contra alvos de auditoria são executadas. Os ambientes de auditoria abstraem as operações de I/O e execução de comandos necessárias para uma auditoria e permitem que funções idênticas sejam executadas contra alvos de auditoria, independentemente da localização física ou de rede dos ficheiros e executáveis do alvo. Os seguintes ambientes são atualmente suportados:
São diferentes opções que podem ser ativadas para a auditoria. Pode especificar opções que se aplicam ao programa DevAudit, por exemplo, para executar em modo não interativo, bem como opções que se aplicam ao alvo, por exemplo, se definir a opção AppDevMode para auditoria de aplicações ASP.NET como verdadeira, então certas regras de auditoria não serão ativadas.
A CLI é a interface principal para o programa DevAudit e é adequada tanto para uso interativo como para uso não interativo em tarefas agendadas, scripts de shell, pipelines de CI e tarefas pós-compilação em IDEs de programadores. A sintaxe básica da CLI do DevAudit é:
devaudit TARGET [ENVIRONMENT] | [OPTIONS]
onde TARGET especifica o alvo de auditoria, ENVIRONMENT especifica o ambiente de auditoria e OPTIONS especifica as opções para o alvo e ambiente de auditoria. Existem 2 formas de especificar opções: opções do programa e opções gerais de auditoria que se aplicam a mais de um alvo podem ser especificadas diretamente na linha de comandos como parâmetros. Opções específicas do alvo podem ser especificadas com a opção -o, usando o formato: -o OPTION1=VALUE1,OPTION2=VALUE2,.... com vírgulas a delimitar cada par chave-valor da opção.
Se estiver a canalizar ou redirecionar a saída do programa para um ficheiro, deve sempre usar a opção -n --non-interactive para desativar quaisquer funcionalidades de interface de utilizador interativas e animações.
Ao especificar caminhos de ficheiros, um prefixo @ antes de um caminho indica ao DevAudit que este caminho é relativo ao diretório raiz do alvo de auditoria. Por exemplo, se especificar:
-r c:\myproject -b @bin\Debug\app2.exe
O DevAudit considera o caminho para o ficheiro binário como c:\myproject\bin\Debug\app2.exe.
msi Realizar uma auditoria de pacotes da fonte de pacotes Windows Installer MSI em máquinas Windows.
npm Realizar uma auditoria de pacotes do package.json do NPM.
choco Realizar uma auditoria de pacotes instalados pelo gestor de pacotes Choco.
oneget Realizar uma auditoria de pacotes da fonte de pacotes OneGet do sistema no Windows.
nuget Realizar uma auditoria de pacotes de uma fonte de pacotes NuGet v2. Deve especificar a localização do ficheiro packages.config do NuGet que pretende auditar usando a opção -f ou --file; caso contrário, o diretório atual será pesquisado por este ficheiro.
bower Realizar uma auditoria de pacotes de uma fonte de pacotes Bower. Deve especificar a localização do ficheiro packages.json do Bower que pretende auditar usando a opção -f ou --file; caso contrário, o diretório atual será pesquisado por este ficheiro.- composer Realize uma auditoria de pacotes de uma fonte de pacotes Composer. Deve especificar a localização do ficheiro composer.json do Composer que pretende auditar usando a opção -f ou --file, caso contrário, o diretório atual será pesquisado por este ficheiro.
dpkg Realize uma auditoria de pacotes da fonte de pacotes dpkg do sistema em Debian Linux e derivados.
rpm Realize uma auditoria de pacotes da fonte de pacotes RPM do sistema em RedHat Linux e derivados.
yum Realize uma auditoria de pacotes da fonte de pacotes Yum do sistema em RedHat Linux e derivados.
Para cada fonte de pacotes, as seguintes opções de auditoria gerais podem ser usadas:
-f --file Especifica a localização do ficheiro de configuração do gestor de pacotes, se necessário. As fontes de pacotes NuGet, Bower e Composer requerem esta opção.
--list-packages Apenas lista os pacotes na fonte de pacotes analisada pelo DevAudit.
--list-artifacts Apenas lista os artefactos encontrados no OSS Index para os pacotes analisados pelo DevAudit.
As fontes de pacotes marcadas como [Experimental] estão disponíveis apenas no branch master do código-fonte e podem ter suporte limitado ao OSS Index de backend. No entanto, pode sempre listar os pacotes analisados e os artefactos disponíveis no OSS Index usando as opções list-packages e list-artifacts.
aspnet Realize uma auditoria de aplicação numa aplicação ASP.NET. As opções relevantes são:
-r --root-directory Especifica o diretório raiz da aplicação. Este é apenas o diretório de topo da aplicação que contém ficheiros como Global.asax e Web.config.-b --application-binary Especifica o binário da aplicação. Este é o assembly .NET que contém o bytecode .NET da aplicação. Este ficheiro é geralmente um .DLL e está localizado na sub-pasta bin do diretório raiz da aplicação ASP.NET.--config-file ou -o AppConfig=ficheiro-de-configuração Especifica o ficheiro de configuração da aplicação ASP.NET. Este ficheiro é geralmente chamado Web.config e está localizado no diretório raiz da aplicação. Pode substituir o valor predefinido @Web.config com esta opção.-o AppDevMode=ativado Especifica que o modo de desenvolvimento da aplicação deve ser ativado para a auditoria. Este modo pode ser usado ao auditar uma aplicação que está em desenvolvimento. Certas regras de configuração marcadas como desativadas para AppDevMode (por exemplo, executar a aplicação em modo de depuração ASP.NET) não serão ativadas durante a auditoria.netfx Realize uma auditoria de aplicação numa aplicação .NET. As opções relevantes são:
-r --root-directory Especifica o diretório raiz da aplicação. Este é apenas o diretório de topo da aplicação que contém ficheiros como App.config.-b --application-binary Especifica o binário da aplicação. Este é o assembly .NET que contém o bytecode .NET da aplicação. Este ficheiro é geralmente um .DLL e está localizado na sub-pasta bin do diretório raiz da aplicação ASP.NET.--config-file ou -o AppConfig=ficheiro-de-configuração Especifica o ficheiro de configuração da aplicação .NET. Este ficheiro é geralmente chamado App.config e está localizado no diretório raiz da aplicação. Pode substituir o valor predefinido @App.config com esta opção.-o GendarmeRules=BibliotecaDeRegras Especifica que o analisador estático Gendarme deve ser ativado para a auditoria com regras da biblioteca de regras especificada. Por exemplo:
devaudit netfx -r /home/allisterb/vbot-debian/vbot.core -b @bin/Debug/vbot.core.dll --skip-packages-audit -o GendarmeRules=Gendarme.Rules.Naming
executará o analisador estático Gendarme no assembly vbot.core.dll usando regras da biblioteca Gendarme.Rules.Naming. A lista completa de bibliotecas de regras é (retirada da wiki do Gendarme):drupal7 Realize uma auditoria de aplicação numa aplicação Drupal 7.
-r --root-directory Especifica o diretório raiz da aplicação. Este é apenas o diretório de topo da sua instalação Drupal 7.drupal8 Realize uma auditoria de aplicação numa aplicação Drupal 8.
-r --root-directory Especifica o diretório raiz da aplicação. Este é apenas o diretório de topo da sua instalação Drupal 8.Todas as aplicações também suportam as seguintes opções comuns para auditar os módulos ou plugins da aplicação:
--list-packages Apenas lista os plugins ou módulos da aplicação analisados pelo DevAudit.
--list-artifacts Apenas lista os artefactos encontrados no OSS Index para plugins e módulos da aplicação analisados pelo DevAudit.
--skip-packages-audit Apenas realiza uma auditoria de configuração ou análise de código da aplicação e salta a auditoria de pacotes.
sshd Realize uma auditoria de servidor de aplicação num servidor compatível com OpenSSH sshd.
httpd Realize uma auditoria de servidor de aplicação num servidor compatível com Apache httpd.
mysql Realize uma auditoria de servidor de aplicação num servidor compatível com MySQL (como MariaDB ou Oracle MySQL.)
nginx Realize uma auditoria de servidor de aplicação num servidor Nginx.
pgsql Realize uma auditoria de servidor de aplicação num servidor PostgreSQL.
Este é um exemplo de linha de comando para uma auditoria de servidor de aplicação:
./devaudit httpd -i httpd-2.2 -r /usr/local/apache2/ --config-file @conf/httpd.conf -b @bin/httpd
que audita um servidor Apache Httpd a correr num contentor Docker chamado httpd-2.2.
As seguintes são opções de auditoria comuns a todos os servidores de aplicação:
-r --root-directory Especifica o diretório raiz do servidor. Este é apenas o topo do sistema de ficheiros do servidor e o padrão é / a menos que queira uma raiz de servidor diferente.--config-file Especifica o ficheiro de configuração do servidor. Por exemplo, na auditoria acima, o ficheiro de configuração do Apache está localizado em /usr/local/apache2/conf/httpd.conf. Se não especificar o ficheiro de configuração, o DevAudit tentará detetar automaticamente o ficheiro de configuração para o servidor selecionado.-b --application-binary Especifica o binário do servidor. Por exemplo, na auditoria acima, o binário do Apache está localizado em /usr/local/apache2/bin/httpd. Se não especificar o caminho do binário, o DevAudit tentará detetar automaticamente o binário do servidor para o servidor selecionado.Os servidores de aplicação também suportam as seguintes opções comuns para auditar os módulos ou plugins do servidor:
--list-packages Apenas lista os plugins ou módulos do servidor analisados pelo DevAudit.
--list-artifacts Apenas lista os artefactos encontrados no OSS Index para plugins e módulos do servidor analisados pelo DevAudit.
--skip-packages-audit Apenas realiza uma auditoria de configuração do servidor e salta a auditoria de pacotes.
Atualmente existem 5 ambientes de auditoria suportados: local, anfitriões remotos via SSH, anfitriões remotos via WinRM, contentores Docker e GitHub. Os ambientes locais são usados por omissão quando nenhuma outra opção de ambiente é especificada.
O ambiente SSH permite que as auditorias sejam realizadas em qualquer anfitrião remoto acessível via SSH sem necessidade de instalar o DevAudit no anfitrião remoto. Os ambientes SSH são multiplataforma: pode ligar-se a um anfitrião remoto Linux a partir de uma máquina Windows a executar o DevAudit. Um ambiente SSH é criado pelas seguintes opções:-s SERVIDOR [--ssh-port PORTA] -u UTILIZADOR [-k FICHEIRO_CHAVE] [-p | --password-text PALAVRA_PASSE]
-s SERVIDOR Especifica o anfitrião remoto ou IP ao qual ligar via SSH.
-u UTILIZADOR Especifica o utilizador para iniciar sessão no servidor.
--ssh-port PORTA Especifica a porta no anfitrião remoto à qual ligar. O padrão é 22.
-k FICHEIRO_CHAVE Especifica o ficheiro de chave privada compatível com OpenSSH a usar para se ligar ao servidor remoto. Atualmente, apenas são suportadas chaves RSA ou DSA em ficheiros no formato PEM.
-p Fornece um aviso com eco local desativado para entrada interativa da palavra-passe do servidor ou frase secreta do ficheiro de chave.
--password-text PALAVRA_PASSE Especifica a palavra-passe do utilizador ou frase secreta do ficheiro de chave como texto simples na linha de comando. Note que no Linux, quando a sua palavra-passe contém caracteres especiais, deve envolver o texto na linha de comando usando plicas como 'MyPa<ss' para evitar que a shell interprete os caracteres especiais.
O ambiente WinRM permite que as auditorias sejam realizadas em qualquer anfitrião Windows remoto acessível via WinRM sem necessidade de instalar o DevAudit no anfitrião remoto. Os ambientes WinRM estão atualmente disponíveis apenas em máquinas Windows a executar o DevAudit. Um ambiente WinRM é criado pelas seguintes opções:-w IP -u UTILIZADOR [-p | --password-text PALAVRA_PASSE]
-w IP Especifica o IP remoto ao qual ligar via WinRM.
-u UTILIZADOR Especifica o utilizador para iniciar sessão no servidor.
-p Fornece um aviso com eco local desativado para entrada interativa da palavra-passe do servidor ou frase secreta do ficheiro de chave.
--password-text PALAVRA_PASSE Especifica a palavra-passe do servidor ou frase secreta do ficheiro de chave como texto simples na linha de comando.
Esta secção discute como auditar imagens Docker usando o DevAudit instalado na máquina local. Para executar o DevAudit como uma aplicação Docker contentorizada, veja a secção abaixo sobre Utilização do Docker.
Um ambiente de auditoria Docker é especificado pela seguinte opção: -i NOME_DO_CONTENTOR | -i ID_DO_CONTENTOR
CONTENTOR_(NOME|ID) Especifica o nome ou id de um contentor Docker em execução ao qual ligar. O contentor deve já estar em execução, pois o DevAudit não sabe como iniciar o contentor com o nome ou estado que necessita.
O ambiente de auditoria GitHub permite que as auditorias sejam realizadas diretamente num repositório de projeto GitHub. Um ambiente GitHub é criado pela opção -g: -g "Owner=PROPRIETÁRIO,Name=NOME,Branch=BRANCH"
PROPRIETÁRIO Especifica o proprietário do projeto
NOME Especifica o nome do projeto
CAMINHO Especifica o branch do projeto ao qual ligar
Pode usar as opções -r, --config-file e -f como de costume para especificar o caminho para ficheiros e diretórios do sistema de ficheiros necessários para a auditoria. Por exemplo, o seguinte comando:
devaudit aspnet -g "Owner=Dnnsoftware,Name=Dnn.Platforn,Branch=Release/9.0.2" -r /Website --config-file @web.config
fará uma auditoria ASP.NET neste repositório https://github.com/dnnsoftware/Dnn.Platform/ usando a pasta de origem /Website como diretório raiz e o ficheiro web.config como ficheiro de configuração ASP.NET. Note que os nomes de ficheiros são sensíveis a maiúsculas/minúsculas na maioria dos ambientes.
-n --non-interactive Executa o DevAudit em modo não interativo com todas as funcionalidades interativas e animações da CLI desativadas. Este modo é necessário para executar o DevAudit em scripts de shell, por exemplo, caso contrário, ocorrerão erros quando o DevAudit tentar usar funcionalidades interativas da consola.
-d --debug Executa o DevAudit em modo de depuração. Isto imprimirá uma variedade de mensagens informativas e de diagnóstico. Este modo é usado para resolver erros e bugs do DevAudit.
O DevAudit também é distribuído como uma aplicação contentorizada Docker que permite aos utilizadores no Linux executar o DevAudit sem a necessidade de instalar o Mono e compilar a partir do código-fonte. Para puxar a imagem Docker do DevAudit do Docker Hub:
docker pull ossindex/devaudit[:etiqueta]
As imagens atuais têm cerca de 131 MB comprimidas. Por padrão, a imagem etiquetada como latest é puxada, que é a versão mais recente do programa. Uma imagem unstable também está disponível, que segue o branch master do código-fonte. Para executar o DevAudit como uma aplicação contentorizada:
docker run -i -t ossindex/devaudit ALVO [AMBIENTE] | [OPÇÕES]
As opções Docker -i e -t são necessárias para executar o DevAudit interativamente. Se não especificar estas opções, então deve executar o DevAudit em modo não interativo usando a opção DevAudit -n.
Deve montar quaisquer diretórios na máquina anfitriã Docker que o DevAudit precise de aceder no contentor Docker do DevAudit usando a opção Docker -v. Se montar o seu diretório raiz local num ponto de montagem chamado /hostroot na imagem Docker, então o DevAudit pode aceder a ficheiros e diretórios na sua máquina local usando os mesmos caminhos locais. Por exemplo:
docker run -i -t -v /:/hostroot:ro ossindex/devaudit netfx -r /home/allisterb/vbot-debian/vbot.core
permitirá que o contentor Docker do DevAudit audite o diretório local /home/allisterb/vbot-debian/vbot.core. Deve montar a sua raiz local desta forma para auditar outros contentores Docker a partir do contentor DevAudit, por exemplo:
docker run -i -t -v /:/hostroot:ro ossindex/devaudit mysql -i myapp1 -r / --config-file /etc/my.cnf --skip-packages-audit
executará uma auditoria MySQL num contentor Docker chamado myapp1 a partir do contentor ossindex/devaudit.
Se não precisar de montar todo o seu diretório raiz, então pode montar apenas o diretório necessário para a auditoria. Por exemplo:
docker run -i -t -v /home/allisterb/vbot-debian/vbot.core:/vbot:ro ossindex/devaudit netfx -r /vbot -b @bin/Debug/vbot.core.dll
montará o diretório /home/allisterb/vbot-debian/vbot.core como /vbot no contentor DevAudit, permitindo que o DevAudit o aceda como diretório raiz da auditoria para uma auditoria de aplicação netfx em /vbot.
Se desejar usar ficheiros de chave privada no anfitrião Docker local para uma auditoria via SSH, pode montar o seu diretório que contém o ficheiro de chave necessário e depois informar o DevAudit para usar esse caminho de ficheiro, por exemplo:
docker -i -t -v /home/allisterb/.ssh:/ssh:ro run ossindex/devaudit dpkg -s localhost -u allisterb -p -k /ssh/mykey.key
montará o diretório que contém os ficheiros de chave em /ssh e permitirá que o contentor DevAudit os utilize.
Note que atualmente não é possível que o contentor Docker audite fontes de pacotes do sistema operativo como dpkg ou rpm ou servidores de aplicação como OpenSSH sshd no anfitrião Docker local sem montar o seu diretório raiz local em /hostroot conforme descrito acima. O DevAudit deve fazer chroot no seu diretório raiz local a partir do contentor Docker ao executar executáveis como dpkg ou binários de servidor como sshd e httpd. Também deve montar a sua raiz local conforme descrito acima para auditar outros contentores Docker a partir do contentor DevAudit, pois o DevAudit também precisa de fazer chroot na sua raiz local para executar comandos Docker locais para comunicar com os seus outros contentores.
Para executar auditorias via SSH a partir do contentor DevAudit, não é necessário montar a raiz local em /hostroot.
Se encontrar um bug ou outro problema com o DevAudit, há algumas coisas que pode ativar para nos ajudar a resolvê-lo:
-n --non-interactive ao redirecionar a saída do programa para um ficheiro, caso contrário, ocorrerá uma falha. Este comportamento pode ser alterado no futuro para tornar o modo não interativo como padrão.