Skip to content
This repository was archived by the owner on Oct 14, 2020. It is now read-only.
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 10 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,11 +16,17 @@

<!-- toc -->

- [Overview](#overview)
- [Purpose of this Project](#purpose-of-this-project)
- [Quickstart](#quickstart)
- [How Does it Work?](#how-does-it-work)
- [Prerequisites](#prerequisites)
- [Deployment](#deployment)
- [How does it work?](#how-does-it-work)
- [Architecture](#architecture)
- [Roadmap](#roadmap)
- [License](#license)
- [Community](#community)
- [Contributing](#contributing)
- [Author Information](#author-information)

For additional documentation aspects please have a look at our:

Expand All @@ -34,7 +40,7 @@ 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:

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-hangig fruits) and therefore will not address the serious, non-obvious ones.
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.

Expand Down Expand Up @@ -72,7 +78,7 @@ helm install zap ./integrations/zap/
# Now everything is installed. You can try deploying scans from the `operator/config/samples/` directory

# E.g. www.securecodebox.io sslyze scan
kubectl apply apply -f operator/config/samples/execution_v1_scan/sslyze_securecodebox_io.yaml
kubectl apply -f operator/config/samples/execution_v1_scan/sslyze_securecodebox_io.yaml
# Then get the current State of the Scan by running:
kubectl get scans
```
Expand Down