Skip to main content


The values.yaml is also created by helm create new-scanner. Most of these generated fields are not necessary for the secureCodeBox. In the following we will describe the important fields. The final values.yaml will look something like this:

image:  repository:  tag: null
parserImage:  repository:  tag: null
scannerJob:  ttlSecondsAfterFinished: null
  resources: {}     resources:       requests:         memory: "256Mi"         cpu: "250m"       limits:         memory: "512Mi"         cpu: "500m"
  env: []
  extraVolumes: []
  extraVolumeMounts: []
  extraContainers: []
  securityContext:    runAsNonRoot: true    readOnlyRootFilesystem: true    allowPrivilegeEscalation: false    privileged: false    capabilities:      drop:        - all


The image field contains the container image and tag used for the scanner. This could be the official image of the scanner but in some cases a custom image is needed. Usually the tag of the image is null and will default to the charts appVersion. See below how to use a local docker image. For WPScan the official image can be used so the image field looks like this:

image:  repository: wpscanteam/wpscan  tag: null


The parserImage field specifies the container image with the parser for the scanner. This will always be a custom image containing the Parser SDK and the parser (see Parser SDK). Like in image the tag will default to the charts appVersion and should be null in values.yaml. For WPScan parserImage looks like this:

parserImage:  repository:  tag: null


scannerJob defines multiple properties for the Scan Job including resources, environment variables, volumes and security context. A basic scannerJob could look like the following.

scannerJob:  ttlSecondsAfterFinished: null  resources: {}  env: []  extraVolumes: []  extraVolumeMounts: []  extraContainers: []  securityContext: {}


Defines how long the scanner job after finishing will be available (see: TTL Controller for Finished Resources | Kubernetes).


The resources field can limit or request resources for the scan job (see: Managing Resources For Containers | Kubernetes). A basic example could be the following:

resources:  requests:    memory: "256Mi"    cpu: "250m"  limits:    memory: "512Mi"    cpu: "500m"


Optional environment variables mapped into each scanJob (see: Define Environment Variables for a Container | Kubernetes).


Optional Volumes mapped into each scanJob (see: Volumes | Kubernetes).


Optional VolumeMounts mapped into each scanJob (see: Volumes | Kubernetes).


Optional additional Containers started with each scanJob (see: Init Containers | Kubernetes).


Optional securityContext set on scanner container (see: Configure a Security Context for a Pod or Container | Kubernetes).

Using local images#

If you are integrating a new scanner and want to test your scanner and parser image from a local build, you can follow these steps:

  1. Create your parser and scanner Dockerfiles
  2. Change the tags in values.yaml file like this:
parser:  image:    repository: your-custom-parser    pullPolicy: IfNotPresentscanner:  image:    repository: your-custom-scanner    pullPolicy: IfNotPresent
  1. Build your parser, using the version from Chart.yaml (e.g. v3.1.0-alpha1):
cd your-custom-scanner/parser/docker build --tag your-custom-parser:(version) . 
  1. Build your scanner, using the appVersion from Chart.yaml (e.g. 1.0.0):
cd your-custom-scanner/scanner/docker build --tag your-custom-scanner:(appVersion) . 
  1. Load both images into your cluster, e.g. using kind:
kind load docker-image your-custom-parser:(version)kind load docker-image your-custom-scanner:(appVersion)

Check images in cluster:

docker exec -it kind-control-plane crictl images
  1. When all files are ready, install via helm:
cd securecodebox/helm upgrade --install your-custom-scanner scanners/your-custom-scanner