Review of level 1 activities

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

@@ -28,7 +28,7 @@ Build and Deployment:
       level: 2
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
       references:
         samm2:
           - I-SB-A-2
@@ -42,34 +42,36 @@ Build and Deployment:
     Defined build process:
       uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b
       description: |
-        A *build process* include more than just compiling your source code. 
-        It also includes steps such as managing (third party) dependencies, 
-        environment configuration, running the unit tests, etc. 
-
-        A *defined build process* has automated these steps to ensure consistency.
+        A *build process* includes more than just compiling your source code. It also covers:
+        - Managing (third party) dependencies
+        - Environment configuration
+        - Running unit and integration tests
+        - Security scanning and compliance checks
+        - Artifact creation and storage
+        - Deployment preparation
 
-        This can be done with a Jenkinsfile, Maven, or similar tools.
+        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 process is error prone; for example,
-        as a result of incorrect security related configuration.
+        Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations.
       measure:
-        A well defined build process lowers the possibility of errors during
-        the build process.
+        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
-      level: 1
-      assessment: |
-        - Show your build pipeline and an exemplary job (build + test).
-        - Show that every team member has access.
-        - Show that failed jobs are fixed.
-
-        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-technologi
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
       references:
         samm2:
           - I-SB-A-1
@@ -144,7 +146,9 @@ Build and Deployment:
         resources: 3
       usefulness: 3
       level: 2
-      implementation: []
+      implementation: 
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/syft
       references:
         samm2:
           - I-SB-B-1

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

@@ -69,23 +69,58 @@ Build and Deployment:
       comments: ""
     Defined deployment process:
       uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a
+      description: |
+        A *defined deployment process* is a documented and standardized procedure for releasing software into production, ensuring consistency and reducing the risk of errors.
       risk: >-
-        Deployment of insecure or malfunctioning artifacts.
+        Deployments relying on human memory are prone to errors, making experienced long-ter staff critical.
       measure: >-
-        Defining a deployment process ensures that there are
-        established criteria in terms of functionalities,
-        security, compliance, and performance,
-        and that the artifacts meet them.
+        Establish a written deployment process documented in README files, wikis, or implemented as executable scripts and automated steps.
+      assessment: |
+        - Deployment process is documented and available to relevant staff
+        - Logs of deployments are documented and availabe to relevant staff
+      level: 1
+      difficultyOfImplementation:
+        knowledge: 1
+        time: 1
+        resources: 1
+      usefulness: 1
+      dependsOn:
+        - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
+        - 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control
+      implementation:
+      references:
+        samm2:
+          - I-SD-A-1
+        iso27001-2017:
+          - 12.1.1
+          - 14.2.2
+        iso27001-2022:
+          - 5.37
+          - 8.32
+    Automated deployment process:
+      uuid: 67e1a9aa-9fbf-4ec5-a2de-400f01960c51
+      description: |
+        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.
+      risk: >-
+        Deployments relying on manual routines increase the risk of errors, insecure configurations, or deploying malfunctioning artifacts.
+      measure: >-
+        Automating the deployment process enforces predefined criteria for security, compliance, and performance, ensuring reliable artifact delivery.
+      assessment: |
+        - Deployment process is documented and available to relevant staff
+        - All deployment steps are automated
+        - Provide audit logs or evidence of deployments
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
-        resources: 1
+        resources: 2
       usefulness: 4
-      level: 1
       dependsOn:
         - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
+        - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Def. Deployment Process
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker
       references:
         samm2:
@@ -96,9 +131,6 @@ Build and Deployment:
         iso27001-2022:
           - 5.37
           - 8.32
-      isImplemented: false
-      evidence: ""
-      comments: ""
     Environment depending configuration parameters (secrets):
       uuid: df428c9d-efa0-4226-9f47-a15bb53f822b
       risk: >-
@@ -211,19 +243,24 @@ Build and Deployment:
         - sbom
     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 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
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
+      level: 1
       difficultyOfImplementation:
         knowledge: 1
         time: 1
         resources: 1
       usefulness: 4
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack
@@ -248,7 +285,7 @@ Build and Deployment:
         is deployed.
       measure: A documented inventory of artifacts in production like container images exists (gathered manually or automatically).
       dependsOn:
-        - Defined deployment process
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
         - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components
       difficultyOfImplementation:
         knowledge: 2
@@ -287,7 +324,7 @@ Build and Deployment:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/webserver
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/rolling-update
       dependsOn:
-        - Defined deployment process
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
       references:
         samm2:
           - I-SD-A-2

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

@@ -4,16 +4,23 @@ Build and Deployment:
   Patch Management:
     A patch policy is defined:
       uuid: 99415139-6b50-441b-89e1-0aa59accd43d
-      risk: Vulnerabilities in running artifacts stay for long and might get exploited.
+      description: |
+        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.
+      risk: Vulnerabilities in running artifacts may persist for a long time and might be exploited.
       measure:
-        A patch policy for all artifacts (e.g. in images) is defined. How often
+        Define a patch policy for all artifacts (e.g. in images) is defined. How often
         is an image rebuilt?
+      assessment: |
+        - Patch policy is documented and accessible to relevant staff.
+        - The policy defines patch frequency and responsible roles.
+        - Patch actions and exceptions are logged and reviewed.
+        - Evidence of regular patching and policy review is available.
+      level: 1
       difficultyOfImplementation:
         knowledge: 3
         time: 1
         resources: 2
       usefulness: 4
-      level: 1
       implementation: []
       references:
         samm2:
@@ -33,23 +40,27 @@ Build and Deployment:
         - patching
     Automated PRs for patches:
       uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488
-      risk:
-        Components with known (or unknown) vulnerabilities might stay for long and get exploited,
-        even when a patch is available.
-      measure:
-        Fast patching of third party component is needed. The DevOps way is
-        to have an automated pull request for new components. This includes
-
+      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 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
-        * Virtualized operating system components (e.g. container images)
-        * Operating Systems
-        * Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform)
+        * Virtualized operating system components (e.g., container images)
+        * Operating systems
+        * Infrastructure as Code/GitOps (e.g., ArgoCD based on a git repository or Terraform)
+      assessment: |
+        - Automated PR tooling is enabled for all relevant repositories.
+        - PRs are created automatically for outdated or vulnerable dependencies.
+        - PRs are reviewed and merged according to the defined patch policy.
+        - Evidence of automated PRs and patching activity is available.
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 4
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependabot
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins

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

@@ -88,25 +88,6 @@ Culture and Organization:
       comments: ""
     Conduction of simple threat modeling on technical level:
       uuid: 47419324-e263-415b-815d-e7161b6b905e
-      risk:
-        Technical related threats are discovered too late in the development and
-        deployment process.
-      measure:
-        Threat modeling of technical features is performed during the product
-        sprint planning.
-      difficultyOfImplementation:
-        knowledge: 2
-        time: 3
-        resources: 1
-      usefulness: 3
-      level: 1
-      implementation:
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
       description: |
         # OWASP SAMM Description
         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:
         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.
 
         Source: OWASP Project Integration Project
+      risk:
+        Technical related threats are discovered too late in the development and deployment process.
+      measure: |
+        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.
+      assessment: |
+        - Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations.
+        - Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review.
+      level: 1
+      difficultyOfImplementation:
+        knowledge: 2
+        time: 3
+        resources: 1
+      usefulness: 3
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
       references:
         samm2:
           - D-TA-B-2

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

@@ -4,19 +4,22 @@ Culture and Organization:
   Education and Guidance:
     Ad-Hoc Security trainings for software developers:
       uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298
-      risk:
-        Understanding security is hard and personnel needs to be trained on it.
-        Otherwise, flaws like an SQL Injection might be introduced into the software
-        which might get exploited.
-      measure:
-        Provide security awareness training for all personnel involved in software
-        development Ad-Hoc.
+      description: |
+        Ad-hoc security training provides basic awareness of software security risks and best practices to developers and other personnel involved in software development. These trainings are delivered as needed, without a fixed schedule, to address immediate knowledge gaps or respond to emerging threats.
+      risk: |
+        Without any security training, personnel may lack awareness of common software vulnerabilities (such as SQL Injection and vulnerable dependencies), increasing the risk of introducing exploitable flaws into applications.
+      measure: |
+        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
+        - Training materials are available
+        - Attendance records are available
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 1
         resources: 1
       usefulness: 3
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-juice-shop
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series
@@ -409,18 +412,21 @@ Culture and Organization:
       comments: ""
     Security consulting on request:
       uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0
-      risk:
-        Not asking a security expert when questions regarding security appear
-        might lead to flaws.
-      measure:
-        Security consulting to teams is given on request. The security consultants
-        can be internal or external.
+      level: 1
+      description: |
+        Security consulting on request allows teams to seek expert advice on security-related questions or challenges as they arise. This support can be provided by internal or external security consultants and helps address specific concerns during software development.
+      risk: |
+        If teams do not consult security experts when questions arise, security flaws may be introduced or remain undetected, increasing the risk of vulnerabilities in the software.
+      measure: |
+        Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development.
+      assessment: |
+        - Show evidence that an it security expert is available for questions at least quarterly.
+        - Documentation of consultations and resulting actions is available for review.
       difficultyOfImplementation:
         knowledge: 3
         time: 1
         resources: 1
       usefulness: 3
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series
       references: