diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml
index 39f7bdd..6f61666 100755
--- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml
+++ b/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
@@ -156,6 +160,7 @@ Build and Deployment:
           - 5.9
           - 5.12
       isImplemented: false
+      tags: ["inventory", "scanning", "sca"]
       evidence: ""
       comments: ""
     Signing of artifacts:
diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml
index e6f76a0..451abfc 100755
--- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml
+++ b/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: >-
@@ -209,21 +241,28 @@ Build and Deployment:
       tags:
         - inventory
         - sbom
+        - scanning
+        - sca
     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 +287,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 +326,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
diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml
index 321ac62..3360754 100755
--- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml
+++ b/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
@@ -245,7 +256,7 @@ Build and Deployment:
       comments: ""
       tags:
         - patching
-    Automated deployment of automated PRs:
+    Automated deployment of automated PRs: &automerge-PR
       uuid: 08f27c26-2c6a-47fe-9458-5e88f188085d
       <<: *automerge-PR
       risk:
diff --git a/src/assets/YAML/default/CultureAndOrganization/Design.yaml b/src/assets/YAML/default/CultureAndOrganization/Design.yaml
index 5925ae9..62fc8b8 100755
--- a/src/assets/YAML/default/CultureAndOrganization/Design.yaml
+++ b/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
diff --git a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
index 3e1cd42..4395b7b 100755
--- a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml
+++ b/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:
diff --git a/src/assets/YAML/default/CultureAndOrganization/Process.yaml b/src/assets/YAML/default/CultureAndOrganization/Process.yaml
index dace513..b769977 100755
--- a/src/assets/YAML/default/CultureAndOrganization/Process.yaml
+++ b/src/assets/YAML/default/CultureAndOrganization/Process.yaml
@@ -58,24 +58,23 @@ Culture and Organization:
       comments: ""
     Definition of simple BCDR practices for critical components:
       uuid: c72da779-86cc-45b1-a339-190ce5093171
-      description:
-        A _Business Continuity and Disaster Recovery_ (BCDR) is a plan and a process
-        that helps a business to return to normal operations if a disaster occurs.
-      risk:
+      description: |
+        Business Continuity and Disaster Recovery (BCDR) is a plan and a process that enable an organization to quickly restore normal operations after a disruptive event, such as a cyberattack or natural disaster.
+      risk: |
         If the disaster recovery actions are not clear, you risk slow reaction and remediation delays.
         This applies to cyber attacks as well as natural emergencies, such as a power outage.
-      measure:
-        By understanding and documenting a business continuity and disaster
-        recovery (BCDR) plan, the overall availability of systems and applications
-        is increased. Success factors like responsibilities, Service Level Agreements,
-        Recovery Point Objectives, Recovery Time Objectives or Failover must be fully
-        documented and understood by the people involved in the recovery.
+      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: |
+        - 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
       difficultyOfImplementation:
         knowledge: 4
         time: 3
         resources: 2
       usefulness: 4
-      level: 1
       implementation: []
       references:
         samm2:
diff --git a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml
index d1e9555..fde532a 100755
--- a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml
+++ b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml
@@ -40,6 +40,7 @@ Implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apimaturity
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - D-SR-A-2
@@ -172,6 +173,7 @@ Implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apimaturity
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - D-SR-A-3
@@ -202,6 +204,7 @@ Implementation:
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - D-SR-A-3
diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml
index 3d02cb1..9a49570 100755
--- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml
+++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml
@@ -16,7 +16,8 @@ Implementation:
       description: ""
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/stylecop
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube-lint
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eslint
       references:
         samm2:
           - V-ST-A-1
@@ -84,12 +85,17 @@ Implementation:
           - Peer review - four eyes principle is not explicitly required by ISO 27001
           - 5.3
           - 8.25
-    Versioning:
+    Version control:
       uuid: 066084c6-1135-4635-9cc5-9e75c7c5459f
-      risk: Deployment of untracked artifacts.
-      description: Use a version control system platform like Github, Gitlab, Bitbucket, gittea,... to version your code.
+      description: 
+        Use a _version control system_ like Github, Gitlab, Bitbucket, etc to version your source code.
+
+        Also known as _source control_, _revision control_, or _source code management_.
+      risk:
+        Without version control, it is challenging to track changes, collaborate effectively, and maintain a history of code modifications. 
+        Rollback to earlier versions is hard.
       measure: >-
-        Version artifacts in order to identify deployed features and issues.
+        Version your source code in order to identify deployed features and issues.
         This includes application and infrastructure code, jenkins configuration, container and virtual machine images definitions.
       difficultyOfImplementation:
         knowledge: 3
@@ -97,8 +103,6 @@ Implementation:
         resources: 3
       usefulness: 5
       level: 1
-      dependsOn:
-        - Defined deployment process
       implementation: []
       references:
         samm2:
diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml
index ab2f023..071a863 100755
--- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml
+++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml
@@ -113,7 +113,7 @@ Implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/a-complete-backup-of
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/a-point-in-time-reco
       dependsOn:
-        - Defined deployment process
+        - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Defined deployment process
       references:
         samm2:
           - TODO
@@ -292,7 +292,7 @@ Implementation:
       usefulness: 4
       level: 4
       dependsOn:
-        - Defined deployment process
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
         - Infrastructure as Code
       implementation: []
       references:
@@ -314,7 +314,7 @@ Implementation:
         or to modify information unauthorized on systems.
       measure:
         The usage of a (role based) access control helps to restrict system
-        access to authorized users. And enhancement is to use attribute based access control.
+        access to authorized users. And enhancement is to use *attribute based access control*.
       difficultyOfImplementation:
         knowledge: 2
         time: 3
@@ -324,9 +324,6 @@ Implementation:
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/directory-service
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/plugins
-      dependsOn:
-        - Defined deployment process
-        - Defined build process
       references:
         samm2:
           - O-EM-A-2
@@ -341,14 +338,14 @@ 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
         resources: 3
       usefulness: 5
       level: 1
-      dependsOn:
-        - Defined deployment process
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/http-basic-authentic
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/vpn
@@ -603,7 +600,7 @@ Implementation:
       usefulness: 4
       level: 2
       dependsOn:
-        - Defined deployment process
+        - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Defined deployment process
       implementation: []
       references:
         samm2:
@@ -678,7 +675,8 @@ Implementation:
       level: 3
       dependsOn:
         - Context-aware output encoding
-      implementation: []
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - O-EM-A-1
@@ -716,7 +714,8 @@ Implementation:
       level: 4
       dependsOn:
         - WAF baseline
-      implementation: []
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - O-EM-A-2
@@ -759,7 +758,8 @@ Implementation:
       level: 5
       dependsOn:
         - WAF medium
-      implementation: []
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths
       references:
         samm2:
           - O-EM-A-2
diff --git a/src/assets/YAML/default/InformationGathering/Logging.yaml b/src/assets/YAML/default/InformationGathering/Logging.yaml
index 75d889e..a718b45 100755
--- a/src/assets/YAML/default/InformationGathering/Logging.yaml
+++ b/src/assets/YAML/default/InformationGathering/Logging.yaml
@@ -31,19 +31,20 @@ Information Gathering:
           - 8.15
     Centralized system logging:
       uuid: 4eced38a-7904-4c45-adb0-50b663065540
-      risk:
-        Local stored system logs can be unauthorized manipulated by attackers
-        or might be corrupt after an incident. In addition, it is hard to perform
-        a aggregation of logs.
-      measure:
-        By using centralized logging logs are protected against unauthorized
-        modification.
+      description: |
+        Centralized system logging involves collecting and storing system logs from multiple sources in a secure, central location. This approach improves log integrity, simplifies monitoring, and enables efficient incident response.
+      risk: |
+        Locally stored system logs can be manipulated by attackers unauthorized or might be corrupt or lost after an incident. In addition, it is hard to perform aggregation of logs.
+      measure: |
+        - Implement a centralized logging solution for all critical systems.
+        - System logs must be stored in a central repository, protected from unauthorized access and modification.
+        - Ensure that log collection is automated and covers all relevant system events.
+      level: 1
       difficultyOfImplementation:
         knowledge: 1
         time: 1
         resources: 1
       usefulness: 2
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/rsyslog
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/logstash
diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml
index c1e4fce..2d0b6f8 100755
--- a/src/assets/YAML/default/InformationGathering/Monitoring.yaml
+++ b/src/assets/YAML/default/InformationGathering/Monitoring.yaml
@@ -127,8 +127,7 @@ Information Gathering:
       level: 4
       dependsOn:
         - Visualized metrics
-      implementation:
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/https-ht-transpare
+      implementation: []
       references:
         samm2:
           - O-IM-A-2
@@ -295,8 +294,11 @@ Information Gathering:
       comments: ""
     Simple application metrics:
       uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1
-      risk: Attacks on an application are not recognized.
-      measure: |-
+      description: |
+        Collecting basic operational data from applications, such as authentication attempts, transaction volumes, and resource usage, will help detect abnormal patterns that may indicate security incidents or system issues.
+      risk: |
+        Without monitoring application metrics, attacks or abnormal behaviors may go undetected, increasing the risk of successful exploitation, data breaches, and delayed incident response.
+      measure: |
         Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include:
           - Authentication attempts (successful/failed logins)
           - Transaction volumes and patterns (e.g. orders, payments)
@@ -307,14 +309,16 @@ Information Gathering:
         Example: An e-commerce application normally processes 100 orders per hour. A sudden spike to 1000 orders per hour could indicate either:
          - A legitimate event (unannounced marketing campaign, viral social media post)
          - A security incident (automated bulk purchase bots, credential stuffing attack)
-        
+
         By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response.
+      assessment: |
+        - Basic application metrics are collected and reviewed.
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 5
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/prometheus
       references:
@@ -327,18 +331,21 @@ Information Gathering:
       comments: ""
     Simple budget metrics:
       uuid: f08a3219-6941-43ec-8762-4aff739f4664
-      risk:
-        Not getting notified about reaching the end of the budget (e.g. due to
-        a denial of service) creates unexpected costs.
-      measure:
-        Cloud providers often provide insight into budgets. A threshold and
-        alarming for the budget is set.
+      description: |
+        Monitoring resource usage and costs to prevent unexpected expenses. This is especially important in cloud environments where resource consumption can quickly exceed planned budgets.
+      risk: |
+        Failure to monitor budget metrics can result in unexpected costs, financial loss, and potential service disruption due to resource exhaustion or denial-of-service attacks.
+      measure: |
+        Set up budget monitoring and alerting for all critical resources. Use provider tools to track spending and configure alerts when thresholds are reached. Implement hard limits where possible to prevent budget overruns.
+      assessment: |
+        - The organization regularly monitors budget metrics
+        - Alerting outside given thresholds are implemented
+      level: 1
       difficultyOfImplementation:
         knowledge: 1
         time: 1
         resources: 1
       usefulness: 5
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/collected
       references:
@@ -353,21 +360,20 @@ Information Gathering:
       comments: ""
     Simple system metrics:
       uuid: 3d1f4c3b-f713-46d9-933a-54a014a26c03
-      risk:
-        Without simple metrics analysis of incidents are hard. In case an application
-        uses a lot of CPU from time to time, it is hard for a developer to find out
-        the source with Linux commands.
-      measure:
-        Gathering of system metrics helps to identify incidents and specially
-        bottlenecks like in CPU usage, memory usage and hard disk usage.
+      description: |
+        Monitoring basic system performance data, such as CPU, memory, and disk usage, will help identify performance bottlenecks and potential security incidents.
+      risk: |
+        Without monitoring system metrics, it is difficult to detect incidents or performance issues, leading to delayed response, reduced availability, and increased risk of undetected attacks.
+      measure: |
+        Collect and monitor key system metrics, including CPU, memory, and disk usage.
+      assessment: |
+        - Basic system metrics are monitored and reviewed regularly
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 5
-      assessment: |
-        Are system metrics gathered?
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/collected
       references:
diff --git a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml
index b4bb808..4266f36 100755
--- a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml
+++ b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml
@@ -100,7 +100,7 @@ Test and Verification:
       level: 4
       implementation: []
       dependsOn:
-        - Defined deployment process
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
       references:
         samm2:
           - V-RT-A-3
diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml
index 1b87b98..c012cca 100755
--- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml
+++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml
@@ -137,10 +137,17 @@ Test and Verification:
       comments: ""
     Simple false positive treatment:
       uuid: c1acc8af-312e-4503-a817-a26220c993a0
-      risk:
-        As false positive occur during each test, all vulnerabilities might be
-        ignored. Specially, if tests are automated an run daily.
-      measure: |-
+      description: |
+        Security tests may produce false positives (or _"false alarms"_), findings that are incorrectly identified as vulnerabilities.
+
+        It is important distinguish these from true positive vulnerabilities to avoid wasting time and resources on non-issues.
+
+        False positive treatment ensures that findings from security tests are triaged and documented, allowing teams to distinguish between real vulnerabilities and false positives. This reduces unnecessary work and helps maintain focus on true risks.
+
+        Some positive findings might be considered an _accepted risk_ by the organization. This must also be documented.
+      risk: |
+        If false positives are not managed, teams may ignore all findings, leading to real vulnerabilities being overlooked and increasing the risk of exploitation. Specially, if tests are automated an run daily.
+      measure: |
         Findings from security tests must be triaged and outcomes persisted/documented to:
           - Prevent re-analysis of known issues in subsequent test runs
           - Track accepted risks vs false positives
@@ -152,12 +159,14 @@ Test and Verification:
           - [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html)
           - [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: |
+        A process is defined for triaging and documenting false positives and accepted risks
+      level: 1
       difficultyOfImplementation:
         knowledge: 1
         time: 1
         resources: 1
       usefulness: 4
-      level: 1
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-defectdojo
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/purify
@@ -171,6 +180,7 @@ Test and Verification:
           - Not explicitly covered by ISO 27001 - too specific
           - 5.27
       isImplemented: false
+      tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"]
       evidence: ""
       comments: ""
     Artifact-based false positive treatment:
@@ -212,7 +222,7 @@ Test and Verification:
         iso27001-2022:
           - 5.25
           - 5.27
-      tags: ["false-positive", "defect-management"]
+      tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"]
     Simple visualization of defects:
       uuid: 55f4c916-3a34-474d-ad96-9a9f7a4f6a83
       risk:
@@ -269,19 +279,24 @@ Test and Verification:
           - 5.25
       tags: ["vuln-action", "defect-management"]
       comments: ""
-    Treatment of defects with severity high or higher:
+    Treatment of defects with high or critical severity:
       uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385
-      risk: Vulnerabilities with severity high or higher are not visible.
-      measure:
-        Vulnerabilities with severity high or higher are added to the quality
-        gate.
+      description: |
+        All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed.
+      risk: |
+        If serious security problems are not fixed, attackers could exploit them to steal data, disrupt services, or cause other harm. Ignoring these issues puts the organization, its customers, and its reputation at risk.
+      measure: |
+        - Make it a rule that all _high_ or _critical_ security findings must be fixed before the software is approved for release or use.
+        - Track these issues and make sure they are resolved quickly.
+      assessment: |
+        - Provide evidence that vulnerabilities are treated within the defined time frame in production. For example via the DSOMM activity [Number of vulnerabilities/severity](./activity-description?uuid=bc548cba-cb82-4f76-bd4b-325d9d256279) or [Patching mean time to resolution via PR](./activity-description?uuid=86d490b9-d798-4a5b-a011-ab9688014c46) with extra deployment statistics.
+      comments: False positive analysis, specially for static analysis, is time consuming.
+      level: 1
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 1
       usefulness: 4
-      level: 1
-      comments: False positive analysis, specially for static analysis, is time consuming.
       references:
         samm2:
           - I-DM-A-2
@@ -291,10 +306,12 @@ Test and Verification:
         iso27001-2022:
           - 8.8
           - 5.25
-      implementation: []
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/grype
       tags: ["vuln-action", "defect-management"]
       evidence: ""
-    Treatment of defects with severity middle:
+    Treatment of defects with medium severity:
       uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594
       risk: Vulnerabilities with severity middle are not visible.
       measure: Vulnerabilities with severity middle are added to the quality gate.
diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml
index 0388402..21a7637 100755
--- a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml
+++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml
@@ -304,7 +304,8 @@ Test and Verification:
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/pmd
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/stylecop
-        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eslint
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube-lint
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/github-super-linter
       references:
         samm2:
@@ -322,16 +323,21 @@ Test and Verification:
       comments: ""
     Exploit likelihood estimation:
       uuid: f2f0f274-c1a0-4501-92fe-7fc4452bc8ad
-      risk: |-
+      description: |
+        Severity-based vulnerability triage alone generates a lot false positives, requiring a more refined approach.
+        
+        Use the likelihood of exploitation by using *known exploited vulnerabilities* (CISA KEV), or prediction models such as 
+        *Exploit Prediction Scoring System* (EPSS).
+      risk: |
         Without proper prioritization, organizations may waste time and effort on low-risk vulnerabilities while neglecting critical ones.
-      measure: Estimate the likelihood of exploitation by using data (CISA KEV) from the past or prediction models (e.g. Exploit Prediction Scoring System, EPSS).
-      description: Severity-based vulnerability triage alone generates a lot false positives, requiring a more refined approach.
+      measure: |
+        Use CISA KEV and EPSS to prioritize vulnerabilities that are more likely to be exploited.
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 4
-      level: 3
+      level: 2
       dependsOn:
         - d918cd44-a972-43e9-a974-eff3f4a5dcfe # SCA for server
       implementation:
@@ -373,6 +379,7 @@ Test and Verification:
         iso27001-2022:
           - 8.8
       isImplemented: false
+      tags: ["defect-management", "sca"]
       evidence: ""
       comments: ""
     Software Composition Analysis (server side):
@@ -408,6 +415,7 @@ Test and Verification:
           - 8.8
       tags:
         - vmm-testing
+      tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"]
     Usage of multiple analyzers:
       uuid: 297be001-8d94-41ee-ab29-207020d423c0
       risk:
diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml
index c0d569d..47e6d25 100755
--- a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml
+++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml
@@ -53,6 +53,7 @@ Test and Verification:
         iso27001-2022:
           - 8.8
       isImplemented: false
+      tags: ["scanning", "sca"]
       evidence: ""
       comments: ""
     Test for malware:
diff --git a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml
index d9f1566..398d2cf 100755
--- a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml
+++ b/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.
diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml
index 9e4fb4c..6a25607 100755
--- a/src/assets/YAML/default/implementations.yaml
+++ b/src/assets/YAML/default/implementations.yaml
@@ -9,7 +9,7 @@ implementations:
     uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4
     name: Enforcement of commit signing
     tags: [signing]
-    url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
+    url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule
     description: |-
       Usage of branch protection rules
   signing-of-commits:
@@ -37,7 +37,7 @@ implementations:
     name: API Security Maturity Model for Authorization
     tags: [api]
     url: https://curity.io/resources/learn/the-api-security-maturity-model/
-  container-technologi:
+  container-technology:
     uuid: ed6b6340-6c7f-4e13-8937-f560d3f5db11
     name: Container technologies and orchestration like Docker, Kubernetes
     tags: []
@@ -92,15 +92,15 @@ implementations:
   kubernetes-admission:
     uuid: 2a76300f-6b1f-4a51-b925-134c36b723af
     name:
-      Kubernetes Admission Controller can whitelist registries and/or whitelist
-      a signing key.
+      Kubernetes Admission Controller can whitelist registries and/or whitelist a signing key.
     tags: []
     url: https://medium.com/slalom-technology/build-a-kubernetes-dynamic-admission-controller-for-container-registry-whitelisting-b46fe020e22d
+    test-url-expects: [403]
   dependabot:
     uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4
     name: dependabot
     tags: ["auto-pr", "patching"]
-    url: https://dependabot.com/
+    url: https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide
   renovate:
     uuid: 8228266e-e04f-40ba-94c8-bfadc5310920
     name: renovate
@@ -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\
@@ -136,12 +141,13 @@ implementations:
     uuid: be757cb3-63d6-4a63-9c4e-e10b746fd47a
     name: Fedora CoreOS
     tags: []
-    url: https://getfedora.org/coreos
+    url: https://fedoraproject.org/coreos/
   distroless-usage:
     uuid: a92c4f8f-a918-406a-b1e5-70acfc0477bd
     name: Distroless or Alpine
     tags: []
     url: https://itnext.io/which-container-images-to-use-distroless-or-alpine-96e3dab43a22
+    test-url-expects: [403]
   threat-modeling-play:
     uuid: fd0f282b-a065-4464-beed-770c604a5f52
     name: Threat Modeling Playbook
@@ -176,10 +182,10 @@ implementations:
     uuid: bb5b8988-021b-452a-a914-bd36887b6860
     name: "Don't Forget EVIL User stories"
     tags: []
-    url: https://www.owasp.org/index.php/Agile_Software_Development
+    url: https://medium.com/serious-scrum/evil-user-storys-story-telling-for-it-security-e4a9ec94193c
+    test-url-expects: [403]
     description:
-      "[Do not Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories)\
-      \ and [Practical Security Stories and Security Tasks for Agile Development Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)"
+      "Do not Forget _Evil_ User Stories and [Practical Security Stories and Security Tasks for Agile Development Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)"
   libyear:
     uuid: 2fff917f-205e-4eab-2e0e-1fab8c04bf33
     name: libyear
@@ -191,7 +197,7 @@ implementations:
     uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a
     name: OWASP Juice Shop
     tags: [training]
-    url: https://github.com/bkimminich/juice-shop
+    url: https://github.com/juice-shop/juice-shop
     description: |-
       In case you do not have the budget to hire an external security expert, an option is to use the OWASP JuiceShop on a "hacking Friday"
   owasp-cheatsheet-series:
@@ -248,7 +254,7 @@ implementations:
     uuid: 7bf90650-a53a-4581-a214-1afd5de3a059
     name: OWASP MASVS
     tags: []
-    url: https://github.com/OWASP/owasp-masvs
+    url: https://github.com/OWASP/masvs
   cis-kubernetes-benchmark:
     uuid: edaec98d-dac7-4dfd-8ab3-42c471d5b9ff
     name: CIS Kubernetes Benchmark for Security
@@ -285,7 +291,7 @@ implementations:
     uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935
     name: Attack Matrix Kubernetes
     tags: [mitre]
-    url: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
+    url: https://www.microsoft.com/en-US/security/blog/2020/04/02/attack-matrix-kubernetes/
     description: |-
       Attack matrix for kubernetes
   istio:
@@ -373,12 +379,12 @@ implementations:
     uuid: 41fda224-2980-443c-bfd4-0a1d4b520cb9
     name: HTTP-Basic Authentication
     tags: []
-    url: https://d3fend.mitre.org/dao/artifact/d3f:WebAuthentication/
+    url: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication
   vpn:
     uuid: e506f60b-747b-44b1-8fe8-f67ccd8f290e
     name: VPN
     tags: []
-    url: https://d3fend.mitre.org/dao/artifact/d3f:VPN/
+    url: https://d3fend.mitre.org/dao/artifact/d3f:VPNServer/
   for-applications-ch:
     uuid: d7fb1f5a-05e3-49f7-ae67-00bfb8f8410c
     name: "For applications: Check default encoding"
@@ -396,7 +402,7 @@ implementations:
     uuid: ba6bd46c-2069-4f4d-b26c-7334a7553339
     name: authentication
     tags: []
-    url: https://d3fend.mitre.org/dao/artifact/d3f:Authentication/
+    url: https://d3fend.mitre.org/dao/artifact/d3f:AuthenticationServer/
   rsyslog:
     uuid: 79f88310-d63e-471d-8e63-8c77f2281b66
     name: rsyslog
@@ -405,7 +411,7 @@ implementations:
   logstash:
     uuid: 7a8fad2e-d642-4972-8501-74591b23feab
     name: logstash
-    url: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html
+    url: https://www.elastic.co/docs/reference/logstash/getting-started-with-logstash
     tags: [tool, logging]
   fluentd:
     uuid: f5da3a20-ab64-4ecf-b4e1-660c80036e45
@@ -436,13 +442,7 @@ implementations:
     uuid: 38fe9d00-df8b-44b6-910d-ca0f02b5c5d3
     name: ELK-Stack
     tags: []
-    url: https://www.elastic.co/elk-stack
-  https-ht-transpare:
-    uuid: 84ef86ea-ada4-4e10-ae4f-a5bb77dcae5d
-    name: https://ht.transpare
-    tags: []
-    url: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD
-    description: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD%20Fileserver/books/SICUREZZA/Addison.Wesley.Security.Metrics.Mar.2007.pdf
+    url: https://www.elastic.co/elastic-stack/
   prometheus:
     uuid: ddf221df-3517-42e4-b23d-c1d9a162744c
     name: Prometheus
@@ -456,7 +456,7 @@ implementations:
     uuid: cc2eec82-f3a7-4ae5-9ccb-3d75352b2e4d
     name: JUnit
     tags: [unittest]
-    url: https://junit.org/junit5/
+    url: https://junit.org/
   karma:
     uuid: fd56720a-ad4b-487c-b4c3-897a688672c4
     name: Karma
@@ -513,7 +513,7 @@ implementations:
     uuid: 7063cf8c-cd98-480f-8ef7-11cf241d2366
     name: OWASP Code Pulse
     tags: []
-    url: https://www.owasp.org/index.php/OWASP_Code_Pulse
+    url: https://owasp.org/www-project-code-pulse/
   ajax-spider:
     uuid: 6583fd5f-4314-4b39-9265-de72f861c8cb
     name: Ajax Spider
@@ -568,7 +568,7 @@ implementations:
     uuid: b99c9d52-dd1a-4aef-8699-65173cf978ce
     name: HTC Hydra
     tags: [password]
-    url: https://www.htc-cs.com/en/products/htc-hydra/
+    url: https://github.com/vanhauser-thc/thc-hydra
   netassert:
     uuid: fffa6fb9-1fae-4852-88dc-c7086961330c
     name: netassert
@@ -583,7 +583,7 @@ implementations:
     uuid: f085295e-46a3-4c8d-bbc3-1ac6b9dfcf2a
     name: OWASP Amass
     tags: []
-    url: https://github.com/OWASP/Amass
+    url: https://github.com/owasp-amass/amass
   k8spurger:
     uuid: 8fea20ad-e332-4aa8-b1f1-aa9deb635dc1
     name: K8sPurger
@@ -625,6 +625,7 @@ implementations:
     name: npm audit
     tags: []
     url: https://docs.npmjs.com/cli/audit
+    test-url-expects: [301]
   sigmahq:
     uuid: 1adf1ac0-8572-407b-a358-3976d9a225e2
     name: SigmaHQ
@@ -636,7 +637,7 @@ implementations:
     tags: []
     url: https://github.com/wagoodman/dive
   clusterscanner:
-    url: https://github.com/SDA-SE/clusterscanner
+    url: https://github.com/SDA-SE/cluster-image-scanner
     uuid: 3c9ac78c-0fd4-43f4-8211-c915f9ef685f
     name: ClusterScanner
     tags:
@@ -694,7 +695,7 @@ implementations:
     uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6
     name: truffleHog
     tags: []
-    url: https://github.com/dxa4481/truffleHog
+    url: https://github.com/trufflesecurity/trufflehog
   go-pillage-registrie:
     uuid: 382873e2-8604-4410-ae5e-b0f5ccdee835
     name: go-pillage-registries
@@ -702,9 +703,19 @@ implementations:
     url: https://github.com/nccgroup/go-pillage-registries
   trivy:
     uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b
-    name: https://github.com/aquasecurity/trivy
+    name: Trivy
     tags: []
     url: https://github.com/aquasecurity/trivy
+  syft:
+    uuid: 7543a6f2-3850-47a9-bb2f-0987e2af6f6a
+    name: Syft
+    tags: [sbom, dependency]
+    url: https://github.com/anchore/syft
+  grype:
+    uuid: 7970af6e-a7d3-4359-a6ea-301d26b16329
+    name: Grype
+    tags: [sbom, dependency, vulnerability]
+    url: https://github.com/anchore/grype
   registries-like-quay:
     uuid: 8737c6c0-4e90-400a-bf9a-f8e399913b57
     name: Registries like quay
@@ -721,38 +732,40 @@ implementations:
   threat-matrix-for-storage:
     uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617
     name: Threat Matrix for Storage
-    url: https://www.microsoft.com/security/blog/2021/04/08/threat-matrix-for-storage/
+    url: https://www.microsoft.com/en-US/security/blog/2021/04/08/threat-matrix-for-storage/
     tags: [documentation, storage, cluster, kubernetes]
   defend-the-core-kubernetes:
     uuid: b7a92886-aec9-4bf4-94c4-07cc191a97af
     name: Defend the core kubernetes security at every layer
-    url: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/
+    url:  https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/
     tags: [documentation, cluster, kubernetes]
   business-friendly-vulnerability-metrics:
     uuid: 3b99799c-e875-4cc2-aad7-5ce4564a1cde
     name: Business friendly vulnerability management metrics
     url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705
+    test-url-expects: [403]
     tags: [documentation, vulnerability, vulnerability management system]
   kubescape:
     uuid: 893d9f37-2142-4490-996c-e43b55064d3d
     name: kubescape
-    url: https://github.com/armosec/kubescape
+    url: https://github.com/kubescape/kubescape
     tags: [kubernetes, vulnerability, misconfiguration]
     description: _Testing if Kubernetes is deployed securely as defined in Kubernetes Hardening Guidance by to NSA and CISA_
   azuredevops:
     uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a
     name: Improve code quality with branch policies
-    url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops
+    url:  https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops
     tags: [source-code-protection, scm]
   github-policies:
     uuid: 99211481-de9c-4358-880e-628366416a27
     name: About protected branches
-    url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
+    url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
     tags: [source-code-protection, scm]
-  sonarqube:
+  sonarqube-lint:
     uuid: aa5ded61-5380-4da6-9474-afc36a397682
     name: In-Depth Linting of Your TypeScript While Coding
-    url: https://blog.sonarsource.com/in-depth-linting-of-your-typescript-while-coding
+    url: https://medium.com/@elenavilchik/in-depth-linting-of-your-typescript-while-coding-1d084affbf0
+    test-url-expects: [403]
     tags: [ide, linting]
   stylecop:
     uuid: 0b7ec352-0c36-4de1-8912-617fc6c608fe
@@ -763,26 +776,29 @@ implementations:
     uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398
     name: Fortify Extension for Visual Studio Code
     url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code
+    test-url-expects: [404]
     tags: [ide, sast]
   appscan-vscode-extension:
     uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb
     name: HCL AppScan CodeSweep
     url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep
+    test-url-expects: [404]
     tags: [ide, sast]
   checkmarx-vscode-extension:
     uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005
     name: Setting Up the Visual Studio Code Extension Plugin
     url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin
+    test-url-expects: [302]
     tags: [ide, sast]
   pre-commit-microsoft:
     uuid: 58ac9dea-b6c7-4698-904e-df89a9451c82
     name: DevSecOps control Pre-commit
-    url: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls#plan-and-develop
+    url: https://learn.microsoft.com/en-us/security/zero-trust/develop/secure-devops-environments-zero-trust
     tags: [pre-commit]
   pre-commit-synopsis:
     uuid: 8da8d115-0f4e-40f0-a3ce-484a49e845fb
     name: Building your DevSecOps pipeline 5 essential activities
-    url: https://www.synopsys.com/blogs/software-security/devsecops-pipeline-checklist/
+    url: https://www.blackduck.com/blog/devsecops-pipeline-checklist/
     tags: [pre-commit]
   dependencyTrack:
     uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9
@@ -816,7 +832,7 @@ implementations:
     uuid: f011de6e-ab7c-4ec7-af55-03427271ab32
     name: Coverage.py
     tags: [testing, coverage]
-    url: https://github.com/nedbat/coveragepy
+    url: https://github.com/coveragepy/coveragepy
     description: |
       Code coverage measurement for Python
   github-dependabot:
@@ -873,6 +889,7 @@ implementations:
     name: terraform
     tags: [IaC]
     url: https://www.terraform.io/
+    test-url-expects: [308]
     description: |
       Terraform enables infrastructure automation for provisioning, compliance, and management of any cloud, datacenter, and service.
   packj:
@@ -882,7 +899,7 @@ implementations:
     url: https://github.com/ossillate-inc/packj
     description: |
       Packj is a tool to detect software supply chain attacks. It can detect malicious, vulnerable, abandoned, typo-squatting, and other "risky" packages from popular open-source package registries, such as NPM, RubyGems, and PyPI.
-  apiMyth:
+  api-myths:
     uuid: 6150533e-58ca-4b52-a9b2-6226545d9ea0
     name: Top 5 API Security Myths That Are Crushing Your Business
     tags: [documentation, waf]
diff --git a/yaml-generation/generateDimensions.php b/yaml-generation/generateDimensions.php
index a45d121..da49b30 100644
--- a/yaml-generation/generateDimensions.php
+++ b/yaml-generation/generateDimensions.php
@@ -234,7 +234,7 @@ function assertUniqueRefByKey($references, $keyToAssert, &$errorMsg) {
             $value = $reference[$keyToAssert];
             // echo "$key: $value\n";
             if (array_key_exists($value, $all_values)) {
-                array_push($errorMsg, "Duplicate '$keyToAssert' in reference file: " . $all_values[$value] . " and $key: $printable_keyToAssert='$value'");
+                array_push($errorMsg, "Duplicate '$keyToAssert' in reference file: '" . $all_values[$value] . "' and '$key': $printable_keyToAssert='$value'");
             } else {
                 $all_values[$value] = $key;
             }
@@ -267,7 +267,7 @@ function assertLiveUrlsInRefs($all_references, &$errorMsg) {
                 if (array_key_exists('url', $reference)) {
                     $url = $reference['url'];
                     echo "  $key: $url\n";
-                    $err = assertLiveUrl($reference['url']);
+                    $err = assertLiveUrl($reference['url'], $reference['test-url-expects'] ?? []);
                     if ($err) {
                         echo "    # $err\n";
                         array_push($errorMsg, "Dead ref URL ($key): $err");
@@ -280,11 +280,12 @@ function assertLiveUrlsInRefs($all_references, &$errorMsg) {
 }
 
 
-function assertLiveUrl($url):string {
+function assertLiveUrl($url, $expectedStatusCodes = []):string {
     $useragent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0';
 
     $curl = curl_init($url);
     curl_setopt($curl, CURLOPT_USERAGENT, $useragent);
+    curl_setopt($curl, CURLOPT_HTTPHEADER, ['Accept-Language: en-US,en']);
     curl_setopt($curl, CURLOPT_NOBODY, true);
     curl_setopt($curl, CURLOPT_HEADER, true);
     curl_setopt($curl, CURLOPT_FOLLOWLOCATION, false);
@@ -305,7 +306,7 @@ function assertLiveUrl($url):string {
 
     curl_close($curl);
 
-    if ($statusCode == 200) {   
+    if (isExpectedStatusCode($statusCode, $expectedStatusCodes)) {   
         return "";
     }
     if ($statusCode == 301 || $statusCode == 302) {   
@@ -314,6 +315,19 @@ function assertLiveUrl($url):string {
     return "Status code: $statusCode: $url";
 }
 
+function isExpectedStatusCode($statusCode, $expectedStatusCodes) {
+    if (count($expectedStatusCodes) == 0) {
+        return $statusCode == 200;
+    }
+
+    foreach ($expectedStatusCodes as $expectedStatusCode) {
+        if ($statusCode == $expectedStatusCode) {
+            return true;
+        }
+    }
+    return false;
+}
+
 
 
 /**