Dradis CE turns a pile of scanner output into a shared report workspace

A shared workspace, not a scanner

Dradis is an open source collaboration framework and penetration testing report generator for InfoSec teams, and the README's own subtitle calls it an automated pentest reporting tool. The important thing to understand is what it is not. It does not scan, it does not exploit and it does not find vulnerabilities.

What it does is collect the output of the tools your team already runs, normalise it, and give the people on the engagement a single place to write notes, attach evidence and track issues. The README names Burp Suite, Nessus and Nmap as examples of what it imports, and the integration list is longer than that, with Brakeman, MediaWiki, Metasploit, NeXpose, Nikto, OpenVAS, Qualys, SAINT and Zed Attack Proxy all listed, plus a link to the full list on the project site.

The stated goals are worth reading, because they explain the design. The first is to share information effectively. The second is to be easy to use and easy to adopt, with the explicit argument that otherwise it would present little benefit over other systems. The third is flexibility through a powerful and simple extensions interface. The fourth is small and portable, with the reasoning that you should be able to use it while on site with no outside connectivity, and that it should be OS independent because no two testers use the same operating system.

That fourth point is a real design constraint rather than a slogan. A reporting tool that needs a round trip to a vendor's servers is useless on a client network with no egress, so the Docker image, the local database and the pluggable importers all follow from it.

The importer list is the actual feature set

For a team choosing between collaboration tools, the integrations are the deciding factor, because a tool only helps if the data arrives in it without hand conversion.

Each integration in the README is a separate document on the project site, and the set covers a wide range of how testers work. The web application scanners are represented by Burp Suite and Zed Attack Proxy. The network scanners are represented by Nmap, Nessus, NeXpose, OpenVAS and Qualys. Metasploit and Nikto cover the exploitation and web scanning side, Brakeman covers Rails applications, and MediaWiki is there for pushing results into a wiki.

The repository layout backs this up. The app/ directory holds the Rails application, and there is an engines/ directory, which is the Rails mechanism for mounting pieces of an application as pluggable components. The Docker build copies the engines directory and the version file specifically so that bundler can resolve the built-in engines and their versions, which tells you the importers are engines rather than hardcoded parser code.

There is also a sandbox concept. The Dockerfile has an ARG BUNDLE_GEMFILE that can be overridden to build the sandbox image, and the repository carries Gemfile.sandbox alongside Gemfile.sandbox.lock, plus a Gemfile.plugins.template for plugin gems. A plugin is the extension mechanism the goals section refers to.

Note what is not in the list. There is no mention of import from a generic report format such as SARIF or CSV in the integrations section, though the community project list includes a CSV import tool built by a third party.

The open core is GPLv2, and Pro is the commercial half

There are two editions, and the README is direct about the split.

Dradis Framework Community Edition is open source and free under the GPLv2 licence. Dradis Framework Professional Edition is a commercial licence and is described as offering report automation, collaboration and client communication tools for teams that need more advanced features. The licence section restates the arrangement: CE under the GNU General Public License version 2.0, Pro under a commercial licence.

That split matters when you evaluate the free edition, because the headline feature of the project, the report generation, is where the two editions differ. A team that mainly wants a shared workspace for findings will find the CE sufficient. A team that wants reports produced automatically for multiple engagements will be looking at the Pro feature list.

The GPLv2 terms on the CE are worth a moment's thought for a consultancy, because the licence governs distribution of the software, not the reports you produce with it. Read the licence text rather than relying on the summary, and take your own advice on what a hosted instance of a modified copy implies.

The repository itself carries a LICENSE.txt file and a COPYING-style layout typical of GPL projects, and the history section of the README notes that Dradis has been around since 2007, and with a 2016 history cleanup that left much of the earlier SVN and Git history out of the current repository.

Running it: one Docker image and a compose file

The quickest path is the published image. You pull it and run a container.

docker image pull dradis/dradis-ce:latest

docker run -it -p 3000:80 dradis/dradis-ce

The second command maps the container's port 80 to port 3000 on the host, which is the quickest way to open the interface on a laptop.

For a real deployment there is a compose file in the repository, and it is short enough to read in full. The single web service runs the same image, persists the database in a named volume mounted at /dradis/storage, publishes 80 and 443, and optionally loads a .env file.

services:
  web:
    image: dradis/dradis-ce:latest
    volumes:
      # Persist the database
      - dradis-ce-storage:/dradis/storage
    ports:
      - 443:443
      - 80:80

The health check is the detail to note, because it will not behave as you might expect on a plain setup.

    healthcheck:
      test: [
        "CMD-SHELL",
        "if [ \"$TLS_DOMAIN\" ]; then curl -f -k http://$TLS_DOMAIN/up; else curl -f http://localhost/up; fi"
      ]
      timeout: 15s
      retries: 3

If TLS_DOMAIN is set the check goes to that domain over HTTP with certificate verification disabled, and otherwise it falls back to localhost. So the container expects to sit behind a name and a certificate in a real deployment, and the compose file is the place to set that.

There is a third route for contributors, a development container. The repository ships the files needed for a Development Container, either through the VS Code extension or by pointing Docker Compose at the file in the .devcontainers directory.

docker compose -f .devcontainer/compose.yaml up --build -d

A Rails app with a plugin surface and a sandbox

The stack is Ruby on Rails, and the Dockerfile gives the shape of it. The build stage uses ruby:3.4.6-slim, installs build-essential, pkg-config and libyaml-dev for the gems, then runs bundle install and precompiles bootsnap. The final image keeps curl, git, libjemalloc2, libvips, redis-server and sqlite3, and the build copies a sample database configuration into place.

Two runtime dependencies stand out. sqlite3 is the default database, which is the right choice for a single-node self-hosted instance and the reason the storage volume is mounted at a single path. redis-server is installed and available, which is what a Rails application uses for background jobs and caching, so long imports run in the background rather than blocking a request.

The environment settings are tuned for a production image. RAILS_ENV is production, BUNDLE_DEPLOYMENT is on so the bundle is installed from the lockfile, BUNDLE_WITHOUT excludes the development and test groups, and RAILS_SERVE_STATIC_FILES is enabled because the image does not sit behind Nginx and serves its own assets.

The build is deliberately two-stage to keep the final image small, and it stages the gem install separately so that the cache is not carried into the runtime layer. The comment in the Dockerfile notes that engines/ is needed to resolve built-in engines and that version.rb is needed for the engine versions in their gemspecs, which is a small but telling detail about how tightly the plugin system is wired into the build.

develop is the default branch, and the changelog is generated

The branching model is documented, which matters more than usual for a project people self-host.

The repository follows the model popularised by Vincent Driessen, with master, develop, release- and hotfix- branches, and the default branch here is develop. The README describes the contributor flow: fork the repository, work on your own copy, get the change checked, then merge it to develop and back to the origin's develop branch.

The practical consequence for a self-hoster is that the branch you pull is the integration branch, not a released one. The README also mentions a Heroku deploy button and a DigitalOcean app button, both pointed at the develop branch, which tells you the maintainers themselves treat develop as the deployable state of the community edition.

Release notes are templated. The repository has a CHANGELOG file and a CHANGELOG.template, which is the convention for a changelog generated from commit messages rather than written by hand. There is no GitHub release published for this repository, so the changelog in the tree is the record of what changed.

The repository also carries a .rubocop.yml and a .rubocop_todo.yml, an .rspec file for RSpec, a Procfile, an app.json for Heroku, a Thorfile, a Rakefile, a package.json with no dependencies at all, and a yarn.lock, which shows a Rails application that keeps its JavaScript surface empty.

For support, the README lists a support site, community forums, a Slack channel, and an IRC channel on irc.freenode.org, which is a good illustration of the ageing corners of a project with this history.

When Dradis CE is the wrong choice

Three situations are worth ruling out before you deploy it.

The first is a solo tester. If one person runs one scanner and writes the findings into a document, the value of Dradis is the collaboration layer, and there is nobody to collaborate with. The overhead of a Rails application, a database and a container is not repaid.

The second is a team that wants reports generated for you. The README places report automation, collaboration and client communication in the Pro edition, so if your evaluation question is can this produce the client deliverable, the answer for the free edition is that it is not what CE is for. Community projects may fill gaps, such as the CSV import tool and the Python wrapper for the REST API listed in the README, but those are third party.

The third is an environment where running a long-lived Rails service is a problem. The image is built for a server, and the compose file expects TLS and a persistent volume. If your team's model is a laptop with a tool run per engagement, the setup cost per engagement is higher than it is with a file based workflow.

What the CE does buy you is a single, self-hosted place where the output of a dozen tools becomes a shared set of issues, nodes, evidence and notes, with a plugin interface for the tools that are missing. For a team that has already outgrown spreadsheets, that is the thing to evaluate.

Editorial conclusion

Dradis CE fits a security team that runs several scanners, needs one shared place for findings, notes and evidence, and wants that workspace to live on its own infrastructure, because the importer list covers the common toolset and the app runs unattended on site. It is not the right choice for a solo tester who only ever runs one tool, since the coordination benefit is the product, and it is not the place to look for automated report generation, which the README places in the commercial Pro edition. Before deploying it, read the compose file, because the health check expects TLS_DOMAIN to be set, keep the dradis-ce-storage volume in mind since it holds the database, and remember that the default branch is develop rather than a release branch.

Frequently asked questions

Official sources

1. dradis/dradis-ce on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README