Deployment View
This section describes the deployment of secureCodeBox. We do not cover all possible deployments, and instead concentrate on the most common scenarios.
Cluster Internal Central Scans
Cluster internal security scans with one dedicated namespace. The whole secureCodeBox with all Scan Types are deployed in the same namespace.
Overview Diagram
The S3 Bucket, the optional build pipline (Jenkins is just an example, may be any other CI/CD tool), and the vulnerability management system (DefectDojo is just an example, it may be any other VMS) are deployd on different nodes in the diagram above. It is also possible to deploy them in the same cluster, on a different cluster, pr on a bare-metal machine or somewhere in the cloud.
Motivation
The motivation behind this scenario is to have one central point to accumulate all findings of all scanned namespaces. Typically, this scenario is for a team which wants to monitor a whole landscape of applications and services (e.g. a security operations (SOC) team).
Cluster/Namespace Internal
Cluster internal security scans directly in the business service's namespace. Only the engine (operator, lurker, hooks) are deployed in a central dedicated namespace. The Scan Types are deployed into the namespaces of the scanned application.
Overview Diagram
The S3 Bucket, the optional build pipline (Jenkins is just an example, may be any other CI/CD tool), and the vulnerability management system (DefectDojo is just an example, it may be any other VMS) are deployd on different nodes in the diagram above. It is also possible to deploy them in the same cluster, on a different cluster, pr on a bare-metal machine or somewhere in the cloud.
Motivation
The motivation behind this scenario is to provide each development team its own instance of secureCodeBox. The common parts like operator is shared, but each team deploys its own scans inside their namespace. Typically, you will use this scenario if you do not want to allow teams to see the findings of other teams.