Repository navigation
Configure Hooks to run per scan #728
Description
➹ New Feature implementation request
It would be extremely helpful if you can decide on a per-scan basis which hooks to run.
Example use case
Installed hooks: Cascading Scans, DefectDojo persistence provider
Started scan:
apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
name: "nmap-open-ports"
spec:
scanType: "nmap"
parameters:
- "-p-"
# Against Host
- "example.com"The initial scan would create this finding:
{
"name":"Open Port: 443 (http)",
"category":"Open Port",
"attributes":{
"port":443,
"state":"open",
"service":"http",
"serviceProduct":"nginx",
"serviceVersion":null,
"tunnel":"ssl"
},
},Cascading Rule:
apiVersion: "cascading.securecodebox.io/v1"
kind: CascadingRule
metadata:
name: "nmap-service-detection"
spec:
matches:
anyOf:
- category: "Open Port"
attributes:
state: open
scanSpec:
scanType: "nmap"
parameters:
- "-p{{attributes.port}}"
- "-sV"
- "--service-all"
# Against Host
- "{{$.hostOrIP}}"When triggered, the Cascading Scan would create the following finding with more service information:
{
"name":"Open Port: 443 (http)",
"category":"Open Port",
"attributes":{
"port":443,
"state":"open",
"service":"http",
"serviceProduct":"nginx",
"serviceVersion":"1.20.1",
"tunnel":"ssl"
},
},In this case, I would like to not import the initial scan results into DefectDojo but still run the Cascading Scan hook.
Describe the solution you'd like
Once #695 is merged, we could use Hook Priorities to solve this problem. One could deploy Cascading Scans with a priority of 1 and DefectDojo with 0. Then on a per-scan basis one may define what hook ranges to execute.
apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
name: "nmap-open-ports"
spec:
hookRanges:
- "1"
scanType: "nmap"
parameters:
- "-p-"
# Against Host
- "example.com"hookRanges would be a list of ranges to execute. A range could have the following formats:
0-1: Execute hooks with priority between0and1(inclusive)0: Execute hooks with priority0.
The orderedHookStatusses status field would still include the skipped hooks but marks them with state Skipped.
Describe alternatives you've considered
Proposed workarounds involved setting up multiple namespaces with different hooks installed and then running the scan in that namespace.
Activity
J12934 commentedon Oct 15, 2021
I like the idea of beeing able to select / filter out certain hooks in a namespace.
I would suggest to use labels and labelSelectors to select which hooks should be run instead of hook prios.
EndPositive commentedon Oct 19, 2021
Hi @J12934, that seems reasonable considering that we have the same mechanism for selecting cascading rules.
I would like to work on this. Could you provide a sample spec here?
J12934 commentedon Oct 19, 2021
Would expect it to look something like the to following (to support both both matchLabels & matchExpressions)
with
matchExpressions:malexmave commentedon Oct 22, 2021
Another case where this is helpful is for scan types that aren't supported in DefectDojo. For example, at the moment, Git-repo-scanner is not supported, and the DD import is affected by #746, making most of the findings disappear before the cascadingScans hook is even triggered. This means that they never get the chance to run on most of the findings of the repo scanner. Given that the fix for the DD issue seems to require changing the default behavior of the DD importer (in the DD instance), it may in some cases be easier to just disable the DD hook for the repo-scanner and only import the results of the cascadingScan.