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
+
A *defined build process* automates these steps to ensure consistency, reproducibility, and security. Automation reduces human error and enforces security controls. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process.
52
54
risk:
53
-
Performing builds without a defined process is error prone; for example,
54
-
as a result of incorrect security related configuration.
55
+
Performing builds without a defined and automated process is error-prone and increases the risk of security misconfigurations, unauthorized changes, and supply chain attacks.
55
56
measure:
56
-
A welldefinedbuild process lowers the possibility of errors during
57
-
the build process.
57
+
A well-defined, automated, and auditable build process lowers the possibility of errors and unauthorized changes during the build process. It also enables traceability and rapid response to incidents.
58
+
level: 1
58
59
difficultyOfImplementation:
59
60
knowledge: 2
60
61
time: 3
61
62
resources: 2
62
63
usefulness: 4
63
-
level: 1
64
64
assessment: |
65
-
- Show your build pipeline and an exemplary job (build + test).
66
-
- Show that every team member has access.
67
-
- Show that failed jobs are fixed.
65
+
- Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
66
+
- Demonstrate that every team member has appropriate access (least privilege).
67
+
- Show that failed jobs are investigated and fixed promptly.
68
+
- Provide audit logs or evidence of build runs and changes.
69
+
- Document how security controls are enforced in the build process.
Copy file name to clipboardExpand all lines: src/assets/YAML/default/BuildAndDeployment/Deployment.yaml
+19-3Lines changed: 19 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -69,19 +69,21 @@ 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 automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms.
72
74
risk: >-
73
-
Deployment of insecure or malfunctioning artifacts.
75
+
Deployment based human routines are error prone, and of insecure or malfunctioning artifacts.
74
76
measure: >-
75
77
Defining a deployment process ensures that there are
76
78
established criteria in terms of functionalities,
77
79
security, compliance, and performance,
78
80
and that the artifacts meet them.
81
+
level: 1
79
82
difficultyOfImplementation:
80
83
knowledge: 2
81
84
time: 2
82
85
resources: 1
83
86
usefulness: 4
84
-
level: 1
85
87
dependsOn:
86
88
- uuid:f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
87
89
implementation:
@@ -96,6 +98,12 @@ Build and Deployment:
96
98
iso27001-2022:
97
99
- 5.37
98
100
- 8.32
101
+
assessment: |
102
+
- Deployment process is documented and available to relevant staff
103
+
- All deployment steps are automated and version-controlled
104
+
- Approvals and access controls are enforced for production deployments
105
+
- Rollback procedures are defined and tested
106
+
- Deployment logs and evidence are retained for audit purposes
99
107
isImplemented: false
100
108
evidence: ""
101
109
comments: ""
@@ -211,19 +219,21 @@ Build and Deployment:
211
219
- sbom
212
220
Inventory of production components:
213
221
uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f
222
+
description: |
223
+
An inventory of production components is a complete, up-to-date list of all applications and services running in production. This enables effective vulnerability management, incident response, and compliance. Without it, organizations risk running unmaintained or unauthorized software.
214
224
risk: |-
215
225
An organization is unaware of components like applications in production. Not knowing existing applications in production leads to not assessing it.
216
226
measure: |-
217
227
A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production.
218
228
In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track.
Copy file name to clipboardExpand all lines: src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml
+25-14Lines changed: 25 additions & 14 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 (or unknown) 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 in a timely manner.
57
+
- Evidence of automated PRs and patching activity is available.
0 commit comments