secureCodeBox v2.1 releases: automate a bunch of security-testing tools out of the box
Continuous Secure Delivery – Out of the Box
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.
Purpose of this Project
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-hanging 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 running 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.
How Does it Work?
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 to see the architecture section.
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.
Process Engine – the Core
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 to 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.
- 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
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
In the works (coming soon)
- SQLMap for SQL Injection scans
- WPScan black box WordPress vulnerability scans
- SSH Scan checking ssh servers for known vulnerabilities
Enabled by the architecture you can also add your own non-free or commercial tools, like
- Burp Suite web vulnerability scanner.
- Add new Kubernetes specific scanner “Kubeaudit” @SebieF (#162)
- Add additional Cascading Rules for Ncrack to bruteforce passwords for FTP, MySQL, PSQL, LDAP and more services. @rseedorff (#160)
- Update outdated link pointing to the old website in docs, readme and Helm post-install notes @J12934 (#158)
🐛 Bug Fixes
Copyright (C) 2018 secureCodeBox