feat: add patching

Author: wurstbrot

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

@@ -4,7 +4,7 @@ Build and Deployment:
   Patch Management:
     A patch policy is defined:
       uuid: 99415139-6b50-441b-89e1-0aa59accd43d
-      risk: Vulnerabilities in running containers stay for long and might get exploited.
+      risk: Vulnerabilities in running artifacts stay for long and might get exploited.
       measure:
         A patch policy for all artifacts (e.g. in images) is defined. How often
         is an image rebuilt?
@@ -29,6 +29,8 @@ Build and Deployment:
       isImplemented: false
       evidence: ""
       comments: ""
+      tags:
+        - patching
     Automated PRs for patches:
       uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488
       risk:
@@ -52,6 +54,7 @@ Build and Deployment:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
         # - $ref: src/assets/YAML/default/implementations.yaml#/implementations/argocd TODO
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/terraform
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/renovate
       references:
         samm2:
           - O-EM-1-B
@@ -61,9 +64,9 @@ Build and Deployment:
         iso27001-2022:
           - 8.8
           - 8.27
-      isImplemented: false
-      evidence: ""
       comments: ""
+      tags:
+        - patching
     Nightly build of images (base images):
       uuid: 34869eaf-f2e1-4926-b0bd-28c43402f057
       description: |-
@@ -97,6 +100,8 @@ Build and Deployment:
       isImplemented: false
       evidence: ""
       comments: ""
+      tags:
+        - patching
     Reduction of the attack surface:
       uuid: 16e39c8f-5336-4001-88ed-a552d2447531
       description: |-
@@ -129,9 +134,10 @@ Build and Deployment:
           - 14.2.1
         iso27001-2022:
           - 8.25
-      isImplemented: false
       evidence: ""
       comments: ""
+      tags:
+        - patching
     Usage of a maximum lifetime for images:
       uuid: 485a3383-7f2e-4dba-bb84-479377070904
       description: |-
@@ -167,9 +173,10 @@ Build and Deployment:
           - 12.6.1
         iso27001-2022:
           - 8.8
-      isImplemented: false
       evidence: ""
       comments: ""
+      tags:
+        - patching
     Usage of a short maximum lifetime for images:
       uuid: 6b96e5a0-ce34-4ea4-a88f-469d3b84546e
       description: |-
@@ -204,17 +211,18 @@ Build and Deployment:
       isImplemented: false
       evidence: ""
       comments: ""
+      tags:
+        - patching
     Automated merge of automated PRs:
       uuid: f2594f8f-1cd6-45f9-af29-eaf3315698eb
       description: |-
         Automated merges of automated created PRs for outdated dependencies.
       risk:
-        Vulnerabilities in running containers stay for too long and might get
-        exploited.
+        Vulnerabilities in running artifacts stay for too long and might get exploited.
       measure: |
         A good practice is to merge trusted dependencies (e.g. spring boot) after a grace period like one week.
         Often, patches, fixes and minor updates are automatically merged. Be aware that automated merging requires a high
-        automated test coverage.
+        automated test coverage. Enforcement of merging of pull requests after a grace period.
       difficultyOfImplementation:
         knowledge: 2
         time: 1
@@ -232,3 +240,5 @@ Build and Deployment:
         iso27001-2022:
           - 8.8
       comments: ""
+      tags:
+        - patching

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

@@ -27,9 +27,65 @@ Test and Verification:
           - Not explicitly covered by ISO 27001 - too specific
           - 8.25
           - 8.27
-      isImplemented: false
-      evidence: ""
       comments: ""
+    Test libyear:
+      <<: *Exclusion-of-source-code-duplicates
+      risk: Vulnerabilities in running artifacts stay for long and might get exploited.
+      measure: |-
+        Test `libyear`, which provides a good insight how good patch management is.
+      usefulness: 3
+      level: 2
+      difficultyOfImplementation:
+        knowledge: 1
+        time: 1
+        resources: 1
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/libyear
+      meta:
+        implementationGuide: |
+          `libyear` can be integrated into the build process and flag or even better break the build in case the defined threshold (e.g. 30 years) is reached.
+          An alternative approach is to determine `libyear` based on deployed artifacts (which requires more effort in implementation).
+      tags:
+        - patching
+    Test for Time to Patch:
+      <<: *Exclusion-of-source-code-duplicates
+      risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts.
+      measure: |-
+        Test of the Time to Patch (e.g. based on Mean Time to Close automatic PRs)
+        This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.
+      usefulness: 3
+      level: 2
+      difficultyOfImplementation:
+        knowledge: 1
+        time: 1
+        resources: 1
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependabot
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/renovate
+      meta:
+        implementationGuide:
+          Usage of a version control platform API (e.g. github API) can be used to fetch the information.
+          Consider that `Measure libyears` might be an alternative to this activity.
+      tags:
+        - patching
+    Test for Patch Deployment Time:
+      <<: *Exclusion-of-source-code-duplicates
+      risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts.
+      measure: |
+        Test of the Patch Deployment Time.
+        This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.
+      usefulness: 3
+      difficultyOfImplementation:
+        knowledge: 2
+        time: 2
+        resources: 1
+      level: 3
+      meta:
+        implementationGuide:
+          Self implementation.
+          This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well.
+      tags:
+        - patching
     Dead code elimination:
       <<: *Exclusion-of-source-code-duplicates
       uuid: d17dbff0-1f10-492a-b4c7-17bb59a0a711

src/assets/YAML/default/implementations.yaml

@@ -164,6 +164,13 @@ implementations:
     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](http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)"
+  libyear:
+    uuid: 2fff917f-205e-4eab-2e0e-1fab8c04bf33
+    name: libyear
+    tags: [patching, build]
+    url: https://libyear.com/
+    description: |-
+      A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are.
   owasp-juice-shop:
     uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a
     name: OWASP Juice Shop