Project: secureCodeBox (Provisioning / Security & Compliance)
File: UPGRADING.md

<!-- SPDX-FileCopyrightText: the secureCodeBox authors SPDX-License-Identifier: Apache-2.0 --> The CRD's are now using `apiextensions.k8s.io/v1` instead of `apiextensions.k8s.io/v1beta1` which requries at least Kubernetes Version 1.16 or higher. The Operator now uses the new kubebuilder v3 command line flag for enabling leader election and setting the metrics port. If you are using the official secureCodeBox Helm Charts for your deployment this has been updated automatically. If you are using a custom deployment you have to change the `--enable-leader-election` flag to `--leader-elect` and `--metrics-addr` to `--metrics-bind-address`. For more context see: https://book.kubebuilder.io/migration/v2vsv3.html#tldr-of-the-new-gov3-plugin The secureCodeBox HelmCharts for hooks and scanners are following a new structure for all HelmChart Values: Instead of secureCodebox Version 2 example: ```yaml image: repository: owasp/zap2docker-stable tag: null parserImage: repository: docker.io/securecodebox/parser-zap tag: null parseJob: ttlSecondsAfterFinished: null scannerJob: ttlSecondsAfterFinished: null backoffLimit: 3 ``` The new HelmChart Values structure in secureCodebox Version 3 looks like: ```yaml parser: image: repository: docker.io/securecodebox/parser-zap tag: null ttlSecondsAfterFinished: null backoffLimit: 3 scanner: image: repository: owasp/zap2docker-stable tag: null ttlSecondsAfterFinished: null backoffLimit: 3 ``` Using {{ .Release.name }} in the `nmap` HelmChart Name for `scanTypes` causes issues when using this chart as a dependency of another chart. All scanners HelmCharts already used a fixed name for the `scanType` they introduce, with one exception: the `nmap` scanner HelmChart. The nmap exception was originally introduced to make it possible configure yourself an `nmap-privilidged` scanType, which is capable of running operating system scans which requires some higher privileges: https://www.securecodebox.io/docs/scanners/nmap#operating-system-scans This idea for extending the name of a scanType is now in Version 3 general available for all HelmCharts. The solution was to add a new HelmChart Value `scanner.appendName` for appending a suffix to the already defined scanType name. Example: the `scanner.nameAppend: -privileged` for the ZAP scanner will create `zap-baseline-scan-privileged`, `zap-api-scan-privileged`, `zap-full-scan-privileged` as new scanTypes instead of `zap-baseline-scan`, `zap-api-scan`, `zap-full-scan`. The provided vulnerable demos are renamed from `demo-apps` to `demo-targets`, this includes the namespace and the folder of the . The hook responsible for cascading scans is renamed from `declarative-subsequent-scans` to `cascading-scans`. For the docker images for scanners and parsers we already had the naming convention of prefixing these images with `scanner-` or `parser-`. Hook images however were named inconsistently (some prefixed with `hook-` some unprefixed). To introduce more consistency we renamed all hook images and prefix them with `hook-` like we did with parser and scanner images. Please beware of this if you are referencing some of our hook images in your own HelmCharts or custom implementations. In the 3.0 release, we corrected the misspelling in

To remove the remains after upgrade, delete the old service accounts and roles from the namespaces where you have executed scans in the past: ```bash kubectl get serviceaccounts --all-namespaces | grep lurcher kubectl --namespace <NAMESPACE> delete serviceaccount lurcher kubectl --namespace <NAMESPACE> delete rolebindings lurcher kubectl --namespace <NAMESPACE> delete role lurcher ``` We implemented a more general which can be used to notify different systems like and and also based in a more flexible way with . With this new hook in place it is not nessesary to maintain the preexisting MS Teams Hook any longer and therefore we removed it. The docker images for the custom demo targets built by secureCodeBox include a "demo-target-" prefix i.e: securecodebox/old-typo3 --> securecodebox/demo-target*-old-typo3 securecodebox/old-joomla --> securecodebox/demo-target*-old-joomla securecodebox/old-wordpress --> securecodebox/demo-target*-old-wordpress These images are usually used for testing and demo purposes. If you use these images, you would have to rename them appropriately. Previously scheduled scans generated by the container autodiscovery are named in the format `scan-imagename-at-imagehash`. The resulting scan pod will be called `scan-scan-imagename-at-imagehash`. To avoid the duplicate scan-scan, the scheduled scans from the container autodiscovery are renamed. As a result, the container autodiscovery will no longer correctly recognize the old scans anymore. It will instead create new scans according to the new naming scheme. The old scheduled scans must be deleted manually. Having the Cascading rules enabled by default on scanner helm install, has led to some confusion on the users side as mentioned in issue . As a result Cascading rules will have to be explicitly enabled by setting the `cascadingRules.enabled` value to `true`. For example as so: ```yaml helm upgrade --install nmap secureCodeBox/nmap --set=cascadingRules.enabled=true ``` Old versions of the operator did not set `app.kubernetes.io/managed-by` label. Starting with V4 the service autodiscovery will assume every scheduled scan created by the autodiscovery will have this label. This means that older scheduled scans without the label will not be detected by the service autodiscovery and new duplicate scheduled scans will be created. Old scheduled scans without the `app.kubernetes.io/managed-by` label must be deleted manually. The `zap` and `zap-advanced` parsers where changed to increase the consistency between the different SCB scanners. The `zap` and `zap-advanced` findings will now report `host` as `hostname`. The container autodiscovery will now be enabled by default. Additionally the container autodiscovery will now check if the configured scantype is installed in the namespace before it creates a scheduled scan (just like the service autodiscovery). The format for have been updated. With it some attributes have been moved / renamed to more closely match the nuclei format and to be able to support most / all information contained from the findings. One of the optional attributes in the finding format of Amass has been renamed from Amass attributes.name to attributes.hostname. If you are parsing this attribute in your application. Renaming it on your end is required The integration for the AngularCSTI scanner has been removed and will no longer be officially supported. Demand for the scanner was low and AngularJS (1.x) has been officially . Using AngularJS in 2023 is therefore a security liability, even when the specific site is not vulnerable to

We added a new attribute to the finding format called `mitigation` which is used to store information about how to mitigate the finding/issue. The `hint` attribute of the findings of the scanners `ssh-scan` and `sslyze` has been renamed to `mitigation` to be more consistent with the other scanners. The AutoDiscovery now takes a list of scans in its configuration. Each configured scan needs a unique name so that the AutoDiscovery is able to distinguish between scans. Because of this it is possible to configure multiple scans with the same scan type. To upgrade wrap your existing scanConfig into a list and rename `scanConfig` to `scanConfigs`, see the default as reference. Example config: ```yaml scanConfigs: scanType: trivy-image name: "my-trivy-scan" parameters: "{{ .ImageID }}" repeatInterval: "168h" scanType: trivy-image name: "second-trivy-scan" parameters: "{{ .ImageID }}" repeatInterval: "168h" ``` In v3 and previous version there was no standardized format for ip address. Depending on the scanner the in attribute fields with different names and generally was only limited to a single address and to ipv4 only. The `hostOrIP` helper for CascadingRule has been updated to use the new standardized field. If a finding has multiple ip addresses and no hostname the `hostOrIP` helper sorts the list of ips alphabetically and picks the first one. With v4 the following changes were made to scanner formats to standardize the ip addresses information: amass: added `ip_addresses` field to attributes. The addresses still remains as is contains additional information like the CIDR & ASN doggo: added `ip_addresses` field to attributes. Only set for A & AAAA records ncrack: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses nikto: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses nuclei: renamed `ip` field to `ip_addresses` and changed format to a list to support multiple addresses ssh-audit: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses sslyze: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses test-scan: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses whatweb: renamed `ipAddress` field to `ip_addresses` and changed format to a list to support multiple addresses wpscan: renamed `ipaddress` field to `ipaddresses` and changed format to a list to support multiple addresses As a example the findings for nmap has been changed like the following: ```diff { "name": "Host: juice-shop.demo-targets.svc.cluster.local", "category": "Host", "description": "Found a host", "location": "juice-shop.demo-targets.svc.cluster.local", "severity": "INFORMATIONAL", "osi_layer": "NETWORK", "attributes": { "ip_address": "10.102.186.25", "ip_addresses": ["10.102.186.25"], "hostname": "juice-shop.demo-targets.svc.cluster.local", "operating_system": null } } ``` Reference: #1701, #1748 SSH-Scan (Mozilla ssh_scan) is now considered deprecated as the tool is no longer maintained by mozilla. As a replacement we've added integration for as a replacement. The ssh-scan integration is still in this release but will be removed in a upcoming (feature) release. @Reet00 & @sofi0071