Repository navigation
Add matchedRule to cascading scans #493
Description
➹ New Feature implementation request
Is your feature request related to a problem?
As a secureCodeBox user, with cascading scans enabled, I would like to know on what CascadingRule a scan has been triggered.
Current situation
Cascading scans are triggered by checking if a CascadingRule matches one of the findings:
secureCodeBox/hooks/declarative-subsequent-scans/hook.ts
Lines 94 to 103 in 89570b3
An example CascadingRule:
secureCodeBox/scanners/nmap/cascading-rules/hostscan.yaml
Lines 6 to 16 in 89570b3
The generated scan only contains ownerReferences, but no information on why it was triggered.
Describe the solution you'd like
We could copy the match onto the cascading scan's metadata:
apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
name: "amass-example.com-nmap-hostscan"
labels: [...]
annotations: [...]
ownerReferences: [...]
matchedRule:
category: "Subdomain"
osi_layer: "NETWORK"
spec:
scanType: "nmap"
parameters:
# Treat all hosts as online -- skip host discovery
- "-Pn"
# Target Port of the finding
- "example.com"
cascades: trueDescribe alternatives you've considered
We could also move the metadata.matchedRule to spec.matchedRule. Probably easier to implement with the types.
Additional context
Should be pretty simple to implement. If you like the format I can create a PR myself. Main or V3 as a base?
Activity
[-]Add scan.[/-][+]Add matchedRule to cascading scans[/+]rfelber commentedon Jun 16, 2021
Thanks for your proposal and spec! It would be helpful if you can add some additional context about the problem context you have. Is it more about better debugging possibilities or is the “matchedRule” information helpful for other features you have in mind?
J12934 commentedon Jun 16, 2021
It's not possible to set "custom keys" in the metadata field, these are the same for all Kuberntes resources.
It's already possible to find out which "CascadingRule" matched, by looking at the
cascading.securecodebox.io/chainannotation of the created scan. This contains a comma separated list of all CascadingRules triggered which lead to the scan to be created. The last entry in the list is the CascadingRule used to create the scan.Note: this only contains the name of the CascadingRule, and doesn't state which "MatchingRule" was used. Including these might be a big more difficult than in the example, as we expect that we need to support other types than the
anyOfwhich is currently currently supported. E.g. supportingnoneOf,allOfetc.The suggested structure would not allow this to be accurately described. I think it might be more helpful to include the id of the finding which triggered the scan. With that it would be easier you could compare the finding with the CascadingRule to figure out why it was triggered.
EndPositive commentedon Jun 17, 2021
Thanks for the thorough answers! Here's some more context to my issue: I was working on a simple graph to visualize cascading scans. As you can see, Amass scan started an nmap scan.
The information for the graph is gathered using the
ownerReferencesfield in a similar manner as kubectl-tree.On the links between nodes, we would love to give some more information on why nmap was started as a result of amass.
@J12934 The addition of
noneOfwould indeed make things more complicated. As you said, it might be more useful to include the finding ID in the scan metadata as it gives the most flexibility in our implementation and won't require changes in secureCodeBox along the road when you want to implementnoneOf, andallOf.