You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 14, 2020. It is now read-only.
Asciidoc uses a different syntax for code or monospaced
blocks.
Also remove leading white spaces.
Signed-off-by: Sven Strittmatter <sven.strittmatter@iteratec.com>
Sven Strittmatter <Sven.Strittmatter@iteratec.com>
20
21
|====
21
22
22
23
== Context
23
24
24
25
=== Status Quo
25
26
26
27
One major challenge implementing the _secureCodeBox_ is to provide a flexible and modular architecture, which enables the open source community to easily understand the concepts and especially to extend the _secureCodeBox_ with individual features. Therefore we decided to seperate the process stages of a single security scan (instance of scanType CRD) in 3 major phases:
By now the "Persisting Phase 3" was implemented by so called _persistenceProviders_ e.g the *persistence-elastic* provider which is responsible for persisting all findings in a given elasticsearch database. The _secureCodeBox_ Operator is aware of this 3 phases and is responsible for the state model and execution of each security scan (instance of scanType CRD).
34
37
35
38
=== Problem and Question
36
39
37
-
We identified different additional UseCases with a more _data proccessing oriented_ pattern than the implemented _persisting phase3_ indicates. For example, we implemented a so called "MetaDataProvider" feature, which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be also persisted.
40
+
We identified different additional UseCases with a more _data proccessing oriented_ pattern than the implemented _persisting phase3_ indicates. For example, we implemented a so called "MetaDataProvider" feature, which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be also persisted.
38
41
39
42
40
43
To find a proper solution, we splitted the topic into the follwong two questions:
@@ -43,6 +46,7 @@ To find a proper solution, we splitted the topic into the follwong two questions
43
46
* Question 2: How should the execution model look like for each concept?
44
47
45
48
==== Question 1: Should we unify the concepts MetaDataProvider and PersistenceProvider?
49
+
46
50
==== Solution approach 1: Unify
47
51
48
52
Both "modules" are "processing" the security findings, which are generated in the parsing phase.
@@ -68,7 +72,8 @@ These could be implemented with a `type` attribute, which declares if they are `
68
72
69
73
The operator would process all these resources in the namespace and execute the `ReadAndWrite` ones first (in serial: one at a time to avoid write conflicts) and then the `ReadOnly` ones (in parallel).
@@ -180,17 +185,17 @@ Https server receiving findings and returning results.
180
185
181
186
Regarding the Question 1 it seems that both solution approaches are resulting in the same execution model. We descided to implement solution approach 1 and unify both concepts into a more general concept with the name _"hook concept"_. Therefore we exchange the existing name `persistenceProvider` for phase 3 in the excecution model with a more general term `DataProcessing`:
0 commit comments