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:

1. 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.
2. 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 core of the secureCodeBox is a process engine (based on the Camunda BPMN platform), 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 to see the architecture section.

Architecture

The base architecture is a Docker-based Microservices Architecture as shown in the picture below.

Design Goal

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.

Components

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.

Scanners

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:

1. 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.
2. 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

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.

Data Collection

The scanner results are collected by an ELK stack (Elasticsearch, Kibana, and Logstash).

Changelog 4.1

🚀 Features

• Add trivy-k8s scan support (closes #1411) @fbelter-iteratec (#1694)
• Added a concurrency policy option for scheduledScan CRD @Ilyesbdlala (#1749)
• Added a crontab configuration option to scheduledScans @Ilyesbdlala (#1722)
• Allow to configure env and volumes in hooks @Zero3141 (#1881)
• Allowed Specifying Labels for Pods of Scans @Ilyesbdlala (#1899)
• DefectDojo Hook: Allow setting minimum severity on Import (closes #1700 ) @ManuelNeuer (#1775)
• Enable client/server mode for trivy by default to cache the vulnerability DB (closes #911) @o1oo11oo (#1760)
• Hardcode debian version in screenshooter Dockerfile @Zero3141 (#1829)
• Remove deprecated userId attribute for DefectDojo Hook @Zero3141 (#1861)
• Update JuiceShop Helm chart to use modern Ingress resource @maze88 (#1882)

🚓 Security Scanner

• Upgraded amass from v3.23.2 to v4.2.0 @Ilyesbdlala, @secureCodeBoxBot (#1773, #1821, #1825)
• Upgraded doggo from v0.5.5 to v0.5.7 @secureCodeBoxBot (#1824, #1955)
• Upgraded ffuf from v2.0.0 to v2.1.0 @secureCodeBoxBot (#1968)
• Upgraded gitleaks from v8.16.3 to v8.18.0 @secureCodeBoxBot (#1753, #1768, #1873)
• Upgraded nmap from 7.92-r2 to 7.93-r1 @Zero3141 (#1960)
• Upgraded nuclei from v2.9.6 to v2.9.14 @secureCodeBoxBot (#1865, #1872, #1880, #1898, #1778, #1788, #1823, #1843)
• Upgraded semgrep from 1.24.1 to 1.41.0 @secureCodeBoxBot (#1761, #1764, #1777, #1784, #1794, #1822, #1840, #1844, #1863, #1879, #1890, #1940, #1962)
• Upgraded ssh-audit from v2.9.0 to v3.0.0 @secureCodeBoxBot (#1939)
• Upgraded sslyze from 5.1.3 to 5.2.0 @secureCodeBoxBot (#1983)
• Upgraded trivy from 0.42.0 to 0.45.1 @secureCodeBoxBot (#1757, #1785, #1793, #1846, #1859, #1888, #1966)
• Upgraded typo3scan from v1.1.2 to v1.1.3 @secureCodeBoxBot (#1771)
• Upgraded wpscan from v3.8.22 to v3.8.24 @secureCodeBoxBot (#1762)
• Upgraded zap from 2.12.0 to 2.13.0 @secureCodeBoxBot (#1810)
• Upgraded zap-advanced from 2.12.0 to 2.13.0 @secureCodeBoxBot (#1809)

🐛 Bug Fixes

• Added sslyze parser check for successful ASN1 certificate parsing @Ilyesbdlala (#1856)
• Fix typo in trivy-rbac RoleBinding name @o1oo11oo (#1765)
• Fixed Bug ErrImagePull in SSH-audit parser @Reet00 (#1801)
• Implemented the failIfFoundUrlsLessThan and warnIfFoundUrlsLessthan settings in ZAP Advanced @Ilyesbdlala (#1791)

Install & Use

Copyright (C) 2018 secureCodeBox