Initially, the goal of secureCodeBox was to provide a tool for easy integrating security test tools into your CI/CD pipeline to run against your web project. Some years ago we asked ourselves: Why only scan a single project? So a great idea was born: Consider the whole company as a project. Additionally, secureCodeBox can aid penetration testers in the recon and discovery phase of a security assessment. 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.
The following goals have been established for this project:
| Priority | |
|---|
| 1 | The project shall be enhanced by features that are suitable to keep. |
| 2 | The project is scalable and resource efficient (FaaS). |
| 3 | The project implements additional scanners that are a useful addition for the current suite, limiting redundancy. |
| 4 | The findings are displayed in a navigable way with least amount of duplication. |
| 5 | SecureCodeBox starts new relevant scans in an agile way, based on previous findings. |
Requirements Overview​
| Id | Requirement | Explanation |
|---|
| UC1 | Initiate scans | Initiating scans in parallel and orchestrating them. |
| UC1.1 | Initiating subsequent scans | Initiate scans based on previous results, through cascading rules. |
| UC2 | Parse findings | Parse findings in a human readable and friendly way. |
Quality Goals​
Below, the most important qualities are described that this project strives for. The qualities are categorized using the ISO 25010 standard. Most of these qualities are derived from blog post The Architecture of secureCodeBox v2. For the entire list of quality-goals see Quality Requirements.
| Category | Quality | Description | Scenario |
|---|
| Maintainability | Modular | All components should be loosely coupled to easily swap them | |
| Ease of integration | It should be possible to easily integrate new scanners | |
| Ease of Contributing | SCB should be well documented | |
| Ease of updating | Third-party software should be carefully chosen, for maintainability | SC1 |
| Portability | Adaptable | SCB Should run everywhere (local, VMs, Cloud, etc.) | SC2 |
| Performance Efficiency | Resource Efficient | SCB should scale to the available resources | SC3 |
| Time Efficient | Tasks should run parallel to optimize the use of resources | |
| Usability | Ease of Integration | The definition and implementation of a scan process should be easy | SC4 |
Scenarios​
| Id | Scenario |
|---|
| SC1 | A third-party updates their software with a breaking change. Effort to support this update is minimal |
| SC2 | A company is running SCB in the cloud, due to limited resources on premise |
| SC3 | SCB is out of resources and a new scan is initiated. The scan is queued until resources are available |
| SC4 | A scan is easily created and started by writing and loading a config file |
Stakeholders​