secureCodeBox is a docker based, modularized toolchain for continuous security scans of your software project. Its goal is to orchestrate and easily automate a bunch of security-testing tools out of the box.
For additional documentation aspects please have a look at our:
The typical way to ensure application security is to hire a security specialist (aka penetration tester) at some point in your project to check the application for security bugs and vulnerabilities. Usually, this check is done at a later stage of the project and has two major drawbacks:
- Nowadays, a lot of projects do continuous delivery, which means the developers deploy new versions multiple times each day. The penetration tester is only able to check a single snapshot, but some further commits could introduce new security issues. To ensure ongoing application security, the penetration tester should also continuously test the application. Unfortunately, such an approach is rarely financially feasible.
- Due to a typically time boxed analysis, the penetration tester has to focus on trivial security issues (low-hangig fruits) and therefore will not address the serious, non-obvious ones.
With the secureCodeBox we provide a toolchain for continuous scanning of applications to find the low-hanging fruit issues early in the development process and free the resources of the penetration tester to concentrate on the major security issues.
The purpose of secureCodeBox is not to replace the penetration testers or make them obsolete. We strongly recommend to run extensive tests by experienced penetration testers on all your applications.
Important note: The secureCodeBox is no simple one-button-click-solution! You must have a deep understanding of security and how to configure the scanners. Furthermore, an understanding of the scan results and how to interpret them is also necessary.
There is a german article about Security DevOps – Angreifern (immer) einen Schritt voraus in the software engineering journal OBJEKTSpektrum.
- Minimal Docker version 18.03.0 is required
- Docker-Compose is required.
- Your docker host will need at least 4GB virtual memory to run the complete stack. If you want to scale out the scanner you will need more...
For a quick start checkout this repository and start the complete secureCodeBox stack with docker-compose:
git clone https://github.com/secureCodeBox/secureCodeBox
cd secureCodeBoxThe docker-compose.yml file can be used to launch a secureCodeBox instance. To start the secureCodeBox and some demo targets run the following:
docker-compose -f docker-compose.yml -f docker-compose.demo.yml upRunning docker-compose up uses the default credentials specified in the .env file. You can override these by changing the file or setting the environment variables on your system. Before running the SecureCodeBox outside a testing environment you should at least change the following variables:
CAMUNDADB_ROOT_PWMySQL root passwordCAMUNDADB_USERMySQL username used by the Camunda EngineCAMUNDADB_PWMySQL password also used by the Camunda EngineENGINE_SCANNERSERVICES_USERTechnical user for the scanner services to access the engines APIENGINE_SCANNERSERVICES_PASSWORDTechnical users password for the scanner services to access the engines API
There are several ways to start a security scan with the secureCodeBox. One way is to use the WebUI of the engine and start the scan manually.
Access the WebUI via: http://your-docker-host:8080/
- Create a local user account
- Click on the user name -> my profile
- Open the "Tasklist"
- Click on "start process" in the upper menu
- Select one of the implemented scan processes (e.g. NMAP)
- Configure the scanner and hit "complete" / "start" (depending on the process)
- Wait for the result and have fun
Hint: If you wan't to use ZAP you might should increase the spider depth from 1 to minimum 3 (advanced configuration). If you use Arachni increase DOM depth, path depth and page limit (scan scope).
The core of the secureCodeBox is a process engine (based on the Camunda BPMN plattform), which allows the user to define the whole scan process. The following image shows an example of a scan process:
The scan itself may be triggered via the WebUI, a REST-API call or via webhooks. The system allows continuous integration software such as Jenkins, Travis CI, Bamboo etc. to trigger a scan automatically. The scans will be executed by the specified scanners and the results will be aggregated for review in the control center or the CI environment. For a more detailed description of the components and how they interact see the architecture section.
The base architecture is a Docker based Microservices Architecture as shown in the picture below.
The most important goal of the architecture is to build the whole toolchain highly modularized, extensible, and scalable. Therefore, we decided to provision the various parts in a microservice architecture style combined with Docker as infrastructure. This design enables the extension of new components by adding a new container as an independent microservice and integrating it with the core engine via a well defined REST interface.
The main component of the secureCodeBox is the Camunda BPMN engine, which allows the engineer to build the whole scan process as a BPMN model. This component also provides the main web UI: The secureCodeBox control center. In this UI you can see the available scan process definitions as BPMN diagrams, start them (Tasklist), and manually review the results. Furthermore, the core is able to listen on webhooks and integrate the exposed process API. This provides the capability to trigger the scan processes by a continuous integration component, such as Jenkins in our example, or any other continuous integration component capable of dealing with webhooks.
The scanners are individual tools like Nmap, Nikto, Arachni and such. Every scanner tool runs in its own Docker container. This has two main reasons:
- You can easily add and integrate a new tool as a scanner, based on a language or technology of your choice, given that it can run inside Docker.
- You can scale up the numbers of running scanners for massive parallel scanning
Each scanner requires a small adapter, usually written in Java, Ruby, Python, or JavaScript. The adapter fulfills two needs. Firstly it translates the configuration data, defining what to do, from the engine format into a usable format for the particular scanning tool. Secondly, it transforms the results of the scan into a usable format by the data collection component.
The scanners also have to check whether the engine has a job to fulfill using the external service task pattern. Requests from scanners were chosen over pushes from the engine due to an easier and more fail tolerant implementation. Otherwise the engine had to monitor the current progress of each scanner instance and whether it is still alive. Thanks to the current implementation a scanner might die and just sends a request after a restart.
The following scanners are currently available out of the box:
- Nmap for IP and port scans
- Nikto for web server scans
- SSLyze for SSL/TLS scans
- Arachni web vulnerability scans
- Amass for subdomain scans
- WPScan black box WordPress vulnerability scans
- SSH Scan checking ssh servers for known vulnarabilities
In the works (coming soon)
- SQLMap for SQL Injection scans
Enabled by the architecture you can also add your own non-free or commercial tools, like
- Burp Suite web vulnerability scanner.
The scanner results are collected by an ELK stack (Elasticsearch, Kibana, and Logstash).
For demonstration purposes, we added some example targets to scan:
Elasticsearch container fails to start: "max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]"
On the host machine run sysctl -w vm.max_map_count=262144 as root. To make the change persistent add the line vm.max_map_count=262144 to /etc/sysctl.conf.
While it is possible to access for example the camunda engine from outside, it is not possible to perform scans outside of SecureCodeBox containers. firewalld blocks traffic from containers to outside, please configure firewalld.
At the moment, the secureCodeBox is in a stable beta state. We are working hard on polishing, documenting and integrating new security scanners.
Code of secureCodeBox is licensed under the Apache License 2.0.
You are welcome, please join us on... 👋
secureCodeBox is an official OWASP project.
Contributions are welcome and extremely helpful 🙌
Sponsored by iteratec GmbH - secureCodeBox.io