➹ New Feature request
Is your feature request related to a problem?
As a secureCodeBox user i would like to use the cascading rules in combination with the DefectDojo-Persistence Hook to examine all results efficiently in OWASP DefectDojo (DD).
Imagine a SCB NMAP scheduledScan setup for a company with a large network in combination with cascading rules. This results in hundreds or even thousands of subsequent scans started by the cascading scans hook.
apiVersion: execution.securecodebox.io/v1
kind: ScheduledScan
metadata:
name: nmap-large-network-scan
namespace: demo-scans
labels:
organization: "OWASP"
location: barcelona
vlan: lan
spec:
interval: 24h
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
scanSpec:
scanType: "nmap"
parameters:
- "-T4"
- "-sV"
- "--version-intensity"
- "4"
- "192.168.0.1/24"
cascades:
matchLabels:
# Uses all CascadingRules in the namespace which are labelled as "non-invasive" and a intensiveness level of "light"
securecodebox.io/invasive: non-invasive
securecodebox.io/intensive: lightThis works really nicely in combination with an elasticsearch backend.
But trying to do something similar in OWASP DefectDojo would result in hundreds or even thousands DefectDojo products for each successful subsequent scan. The name of each imported DefectDojo Product would be the generated scan name like ssh-scan-demo-lan-1616202292-ssh-scan-tc754. To prevent this it is necessary to add some DefectDojo-Hook specific annotation to each subsequent scan to relate them to the correct DefectDojo Product or Engagement name.
Problem is 🧐: currently this is not possible to configure within the cascading rules or a scan. But it would be very helpful 😆
There is already a function implemented in the cascading hook which ensures that all parent scan labels are copied to all subsequent scans:
|
metadata: { |
|
generateName: `${name}-`, |
|
labels: { |
|
...parentScan.metadata.labels |
|
}, |
|
annotations: { |
|
"securecodebox.io/hook": "declarative-subsequent-scans", |
|
"cascading.securecodebox.io/parent-scan": parentScan.metadata.name, |
|
"cascading.securecodebox.io/chain": [ |
|
...cascadingChain, |
|
generatedBy |
|
].join(",") |
Describe the solution you'd like
It should be possible to define and copy custom labels and annotations for each subsequent scan. There are different scenarios to take into account:
- Copy all
labels and annotations from the parent scan to every subsequent scan
- Generate new labels and annotations based on a lightweight template syntax and the given
parent scan or findings data.
Examples
ScheduledScan NMAP Definition Example:
apiVersion: execution.securecodebox.io/v1
kind: ScheduledScan
metadata:
name: nmap-large-network-scan
namespace: demo-scans
annotations:
defectdojo.securecodebox.io/product-name: "barcelona-network-scan"
defectdojo.securecodebox.io/product-type-name: "OWASP"
defectdojo.securecodebox.io/product-tags: vulnerable,appsec,network
defectdojo.securecodebox.io/engagement-name: "scb-automated-scan"
defectdojo.securecodebox.io/engagement-tags: "automated,daily"
labels:
organization: "OWASP"
location: barcelona
vlan: lan
spec:
interval: 24h
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
scanSpec:
scanType: "nmap"
parameters:
- "-T4"
- "-sV"
- "192.168.0.1/24"
cascades:
# True if all scan (parent) labels are copied to each subsequent scan (child), otherwise false. Default: true
inheritLabels: true
# True if all scan (parent) annotations are copied to each subsequent scan (child), otherwise false. Default: true
inheritAnnotations: true
# Uses all CascadingRules in the namespace which are labelled as "non-invasive" and a intensiveness level of "light"
matchLabels:
securecodebox.io/invasive: non-invasive
securecodebox.io/intensive: lightOWASP ZAP Cascading Rule Example
apiVersion: "cascading.securecodebox.io/v1"
kind: CascadingRule
metadata:
name: "zap-http"
labels:
securecodebox.io/invasive: non-invasive
securecodebox.io/intensive: medium
spec:
matches:
anyOf:
- category: "Open Port"
attributes:
service: http
state: open
- category: "Open Port"
attributes:
service: https
state: open
# Configures additional label added to each subsequent scan (child)
scanLabels:
mynewlabel: {{$.metadata.name}}
# Configures additional annotation added to each subsequent scan (child)
scanAnnotations:
defectdojo.securecodebox.io/product-name: "{{$.hostOrIP}}"
defectdojo.securecodebox.io/product-type-name: "{{$.metadata.labels.organization}}"
defectdojo.securecodebox.io/product-tags: vulnerable,appsec,owasp-top-ten,vulnapp
defectdojo.securecodebox.io/engagement-name: "{{$.hostOrIP}}"
scanSpec:
scanType: "zap-baseline"
parameters: ["-t", "{{attributes.service}}://{{$.hostOrIP}}"]Describe alternatives you've considered
Additional context
➹ New Feature request
Is your feature request related to a problem?
As a secureCodeBox user i would like to use the cascading rules in combination with the DefectDojo-Persistence Hook to examine all results efficiently in OWASP DefectDojo (DD).
Imagine a SCB NMAP
scheduledScansetup for a company with a large network in combination with cascading rules. This results in hundreds or even thousands of subsequent scans started by the cascading scans hook.This works really nicely in combination with an elasticsearch backend.
But trying to do something similar in OWASP DefectDojo would result in hundreds or even thousands DefectDojo products for each successful subsequent scan. The name of each imported DefectDojo
Productwould be the generatedscanname likessh-scan-demo-lan-1616202292-ssh-scan-tc754. To prevent this it is necessary to add some DefectDojo-Hook specific annotation to each subsequent scan to relate them to the correct DefectDojoProductorEngagementname.Problem is 🧐: currently this is not possible to configure within the
cascading rulesor ascan. But it would be very helpful 😆There is already a function implemented in the cascading hook which ensures that all
parent scanlabels are copied to all subsequent scans:secureCodeBox/hooks/declarative-subsequent-scans/scan-helpers.ts
Lines 79 to 90 in 0257dda
Describe the solution you'd like
It should be possible to define and copy custom labels and annotations for each subsequent scan. There are different scenarios to take into account:
labelsandannotationsfrom theparent scanto everysubsequent scanparent scanorfindingsdata.Examples
ScheduledScanNMAP Definition Example:OWASP ZAP Cascading Rule Example
Describe alternatives you've considered
Additional context