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
A *build process* include more than just compiling your source code.
46
-
It also includes steps such as managing (third party) dependencies,
47
-
environment configuration, running the unit tests, etc.
48
-
49
-
A *defined build process* has automated these steps to ensure consistency.
45
+
A *build process* includes more than just compiling your source code. It also covers:
46
+
- Managing (third party) dependencies
47
+
- Environment configuration
48
+
- Running unit and integration tests
49
+
- Security scanning and compliance checks
50
+
- Artifact creation and storage
51
+
- Deployment preparation
50
52
51
-
This can be done with a Jenkinsfile, Maven, or similar tools.
53
+
Basing the build process on human memory may lead to inconsistencies and security misconfigurations.
54
+
55
+
A *defined build process* can automate these steps to ensure consistency, avoiding accidental omissions or misconfigurations. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process.
56
+
57
+
A simplified, but still a *defined build process*, may be a checklist of the steps to be performed.
52
58
risk:
53
-
Performing builds without a defined process is error prone; for example,
54
-
as a result of incorrect security related configuration.
59
+
Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations.
55
60
measure:
56
-
A well defined build process lowers the possibility of errors during
57
-
the build process.
61
+
Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
62
+
assessment: |
63
+
- Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
64
+
level: 1
58
65
difficultyOfImplementation:
59
66
knowledge: 2
60
67
time: 3
61
68
resources: 2
62
69
usefulness: 4
63
-
level: 1
64
-
assessment: |
65
-
- Show your build pipeline and an exemplary job (build + test).
Copy file name to clipboardExpand all lines: src/assets/YAML/default/BuildAndDeployment/Deployment.yaml
+53-14Lines changed: 53 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -69,23 +69,58 @@ Build and Deployment:
69
69
comments: ""
70
70
Defined deployment process:
71
71
uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a
72
+
description: |
73
+
A *defined deployment process* is a documented and standardized procedure for releasing software into production, ensuring consistency and reducing the risk of errors.
72
74
risk: >-
73
-
Deployment of insecure or malfunctioning artifacts.
75
+
Deployments relying on human memory are prone to errors, making experienced long-ter staff critical.
74
76
measure: >-
75
-
Defining a deployment process ensures that there are
76
-
established criteria in terms of functionalities,
77
-
security, compliance, and performance,
78
-
and that the artifacts meet them.
77
+
Establish a written deployment process documented in README files, wikis, or implemented as executable scripts and automated steps.
78
+
assessment: |
79
+
- Deployment process is documented and available to relevant staff
80
+
- Logs of deployments are documented and availabe to relevant staff
81
+
level: 1
82
+
difficultyOfImplementation:
83
+
knowledge: 1
84
+
time: 1
85
+
resources: 1
86
+
usefulness: 1
87
+
dependsOn:
88
+
- f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
89
+
- 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control
90
+
implementation:
91
+
references:
92
+
samm2:
93
+
- I-SD-A-1
94
+
iso27001-2017:
95
+
- 12.1.1
96
+
- 14.2.2
97
+
iso27001-2022:
98
+
- 5.37
99
+
- 8.32
100
+
Automated deployment process:
101
+
uuid: 67e1a9aa-9fbf-4ec5-a2de-400f01960c51
102
+
description: |
103
+
An *automated deployment process* implements the defined deployment steps using automation tools, ensuring consistency, auditability, and minimizing the risk of human errors or unauthorized changes.
104
+
risk: >-
105
+
Deployments relying on manual routines increase the risk of errors, insecure configurations, or deploying malfunctioning artifacts.
106
+
measure: >-
107
+
Automating the deployment process enforces predefined criteria for security, compliance, and performance, ensuring reliable artifact delivery.
108
+
assessment: |
109
+
- Deployment process is documented and available to relevant staff
110
+
- All deployment steps are automated
111
+
- Provide audit logs or evidence of deployments
112
+
level: 1
79
113
difficultyOfImplementation:
80
114
knowledge: 2
81
115
time: 2
82
-
resources: 1
116
+
resources: 2
83
117
usefulness: 4
84
-
level: 1
85
118
dependsOn:
86
119
- f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
120
+
- 74938a3f-1269-49b9-9d0f-c43a79a1985a # Def. Deployment Process
An inventory of production components is a complete, up-to-date list of all applications running in production. This enables effective vulnerability management, incident response, and compliance. Without it, organizations risk running unmaintained or unauthorized software.
214
250
risk: |-
215
251
An organization is unaware of components like applications in production. Not knowing existing applications in production leads to not assessing it.
216
252
measure: |-
217
253
A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production.
218
254
In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track.
255
+
assessment: |
256
+
- Inventory of all production applications with application name, owner, and date of last review
257
+
- Inventory is accessible to development, security and operations teams
219
258
dependsOn:
220
-
- Defined deployment process
259
+
- 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
Copy file name to clipboardExpand all lines: src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml
+26-15Lines changed: 26 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -4,16 +4,23 @@ Build and Deployment:
4
4
Patch Management:
5
5
A patch policy is defined:
6
6
uuid: 99415139-6b50-441b-89e1-0aa59accd43d
7
-
risk: Vulnerabilities in running artifacts stay for long and might get exploited.
7
+
description: |
8
+
A patch policy defines how and when software components, images, and dependencies are updated. A patch policy ensures that all these artifacts are regularly reviewed and updated, reducing the window of exposure to known threats. The policy should specify the frequency, responsibilities, and documentation requirements for patching.
9
+
risk: Vulnerabilities in running artifacts may persist for a long time and might be exploited.
8
10
measure:
9
-
A patch policy for all artifacts (e.g. in images) is defined. How often
11
+
Define a patch policy for all artifacts (e.g. in images) is defined. How often
10
12
is an image rebuilt?
13
+
assessment: |
14
+
- Patch policy is documented and accessible to relevant staff.
15
+
- The policy defines patch frequency and responsible roles.
16
+
- Patch actions and exceptions are logged and reviewed.
17
+
- Evidence of regular patching and policy review is available.
18
+
level: 1
11
19
difficultyOfImplementation:
12
20
knowledge: 3
13
21
time: 1
14
22
resources: 2
15
23
usefulness: 4
16
-
level: 1
17
24
implementation: []
18
25
references:
19
26
samm2:
@@ -33,23 +40,27 @@ Build and Deployment:
33
40
- patching
34
41
Automated PRs for patches:
35
42
uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488
36
-
risk:
37
-
Components with known (or unknown) vulnerabilities might stay for long and get exploited,
38
-
even when a patch is available.
39
-
measure:
40
-
Fast patching of third party component is needed. The DevOps way is
41
-
to have an automated pull request for new components. This includes
42
-
43
+
description: |
44
+
Automated PRs for patches ensure that updates for outdated or vulnerable dependencies are created and proposed without manual intervention. Tools continuously monitor for new versions or security advisories and immediately generate pull requests to update affected components in code, container images, or infrastructure. This process ensures that available patches are quickly visible to developers and can be reviewed and merged with minimal delay, reducing the risk window for known vulnerabilities.
45
+
risk: |
46
+
Components with known vulnerabilities might persist for a long time and be exploited, even when a patch is available.
47
+
measure: |
48
+
Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes:
43
49
* Applications
44
-
* Virtualized operating system components (e.g. container images)
45
-
* Operating Systems
46
-
* Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform)
50
+
* Virtualized operating system components (e.g., container images)
51
+
* Operating systems
52
+
* Infrastructure as Code/GitOps (e.g., ArgoCD based on a git repository or Terraform)
53
+
assessment: |
54
+
- Automated PR tooling is enabled for all relevant repositories.
55
+
- PRs are created automatically for outdated or vulnerable dependencies.
56
+
- PRs are reviewed and merged according to the defined patch policy.
57
+
- Evidence of automated PRs and patching activity is available.
Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment.
@@ -150,6 +131,26 @@ Culture and Organization:
150
131
GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes.
151
132
152
133
Source: OWASP Project Integration Project
134
+
risk:
135
+
Technical related threats are discovered too late in the development and deployment process.
136
+
measure: |
137
+
Perform threat modeling of technical features during product sprint planning using simple checklists and diagrams. Document identified threats and mitigations for new or changed functionality.
138
+
assessment: |
139
+
- Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations.
140
+
- Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review.
0 commit comments