Revision after feedback

Author: vbakke

src/assets/YAML/default/BuildAndDeployment/Build.yaml

@@ -50,26 +50,26 @@ Build and Deployment:
         - Artifact creation and storage
         - Deployment preparation
 
-        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.
+        Basing the build process on human memory may lead to inconsistencies and security misconfigurations.
+
+        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.
+
+        A simplified, but still a *defined build process*, may be a checklist of the steps to be performed.
       risk:
-        Performing builds without a defined and automated process is error-prone and increases the risk of security misconfigurations, unauthorized changes, and supply chain attacks.
+        Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations.
       measure:
-        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.
+        Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
+      assessment: |
+        - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
       level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 3
         resources: 2
       usefulness: 4
-      assessment: |
-        - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
-        - Demonstrate that every team member has appropriate access (least privilege).
-        - Show that failed jobs are investigated and fixed promptly.
-        - Provide audit logs or evidence of build runs and changes.
-        - Document how security controls are enforced in the build process.
-
-        Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/)
       implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/maven
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
       references:

src/assets/YAML/default/BuildAndDeployment/Deployment.yaml

@@ -100,10 +100,9 @@ Build and Deployment:
           - 8.32
       assessment: |
         - Deployment process is documented and available to relevant staff
-        - All deployment steps are automated and version-controlled
-        - Approvals and access controls are enforced for production deployments
-        - Rollback procedures are defined and tested
-        - Deployment logs and evidence are retained for audit purposes
+        - All deployment steps are automated
+        - Rollback procedures are defined and tested [Keep??? Delete???]
+        - Provide audit logs or evidence of deployments
       isImplemented: false
       evidence: ""
       comments: ""
@@ -220,12 +219,15 @@ Build and Deployment:
     Inventory of production components:
       uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f
       description: |
-        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.
+        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.
       risk: |-
         An organization is unaware of components like applications in production. Not knowing existing applications in production leads to not assessing it.
       measure: |-
         A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production.
         In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track.
+      assessment: |
+        - Inventory of all production applications with application name, owner, and date of last review
+        - Inventory is accessible to development, security and operations teams
       dependsOn:
         - Defined deployment process
       level: 1
@@ -247,12 +249,6 @@ Build and Deployment:
         iso27001-2022:
           - 5.9
           - 5.12
-      assessment: |
-        - Inventory of all production components exists and is regularly updated
-        - Inventory includes key metadata (e.g., version, owner, deployment date)
-        - Inventory is accessible to security and operations teams
-        - There is a process for adding, updating, and removing components
-        - Inventory reviews are performed and documented
       tags:
         - inventory
     Inventory of production artifacts:

src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml

@@ -43,7 +43,7 @@ Build and Deployment:
       description: |
         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.
       risk: |
-        Components with known (or unknown) vulnerabilities might persist for a long time and be exploited, even when a patch is available.
+        Components with known vulnerabilities might persist for a long time and be exploited, even when a patch is available.
       measure: |
         Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes:
         * Applications
@@ -53,7 +53,7 @@ Build and Deployment:
       assessment: |
         - Automated PR tooling is enabled for all relevant repositories.
         - PRs are created automatically for outdated or vulnerable dependencies.
-        - PRs are reviewed and merged in a timely manner.
+        - PRs are reviewed and merged according to the defined patch policy.
         - Evidence of automated PRs and patching activity is available.
       level: 1
       difficultyOfImplementation:

src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml

@@ -12,7 +12,6 @@ Culture and Organization:
         Provide security awareness training for all personnel involved in software development on an ad-hoc basis, ensuring that relevant topics are covered when new risks or needs are identified.
       assessment: |
         - Conduct security training for developers and relevant personnel
-        - Participants can identify common software security risks addressed in the training
         - Training materials are available
         - Attendance records are available
       level: 1

src/assets/YAML/default/CultureAndOrganization/Process.yaml

@@ -66,7 +66,7 @@ Culture and Organization:
       measure: |
         Develop, document, and communicate a BCDR plan for all critical components. The plan must define roles and responsibilities, Service Level Agreements (SLAs), Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs), and failover procedures. Ensure all relevant personnel are trained and the plan is reviewed and updated regularly.
       assessment: |
-        - The organization has a documented BCDR plan covering all critical components.
+        - There is a documented BCDR plan covering all critical components of the application(s).
         - The plan clearly defines responsibilities, SLAs, RPOs, RTOs, and failover steps. 
         - Relevant staff are aware of the plan, and evidence of regular review and testing is available.
       level: 1

src/assets/YAML/default/Implementation/InfrastructureHardening.yaml

@@ -366,6 +366,8 @@ Implementation:
       uuid: 82e499d1-f463-4a4b-be90-68812a874af6
       risk: Attackers a gaining access to internal systems and application interfaces
       measure: All internal systems are using simple authentication
+      assessment: |
+        - Demonstrate that every team member has appropriate access (least privilege).        
       difficultyOfImplementation:
         knowledge: 3
         time: 3

src/assets/YAML/default/TestAndVerification/Consolidation.yaml

@@ -162,7 +162,7 @@ Test and Verification:
           - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/)
           - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status)
       assessment: |
-        The organization has a process for triaging and documenting false positives and accepted risks
+        A process is defined for triaging and documenting false positives and accepted risks
       level: 1
       difficultyOfImplementation:
         knowledge: 1

src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml

@@ -1,7 +1,7 @@
 # yaml-language-server: $schema=../../schemas/dsomm-schema-test-and-verification.json
 ---
 Test and Verification:
-  Test-Intensity:
+  Test Intensity:
     Creation and application of a testing concept:
       uuid: 79ef8103-e1ed-4055-8df8-fd2b2015bebe
       risk: Scans might use a too small or too high test intensity.

src/assets/YAML/default/implementations.yaml

@@ -111,9 +111,14 @@ implementations:
     name: Jenkins
     tags: []
     url: https://www.jenkins.io/
+  maven:
+    uuid: eb6de6b9-e060-4902-ae6f-604ffc386b63
+    name: Maven
+    tags: []
+    url: https://maven.apache.org/
   sample-concept-1:
     uuid: 1a463242-b480-46f6-a912-b51ec1c1558d
-    name: "Sample concept:  \n(1"
+    name: "Sample concept"
     tags: []
     description:
       "Sample concept:  \n(1) each container has a set lifetime and is\
@@ -716,7 +721,7 @@ implementations:
     tags: [sbom, dependency]
     url: https://github.com/anchore/syft
   grype:
-    uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b
+    uuid: 7970af6e-a7d3-4359-a6ea-301d26b16329
     name: Grype
     tags: [sbom, dependency, vulnerability]
     url: https://github.com/anchore/grype