Merge branch 'feat/Q2.2'

feat: update pre-commit hooks and answered questions

See merge request Klagarge/mse2425-grp09!16

.pre-commit-config.yaml

@@ -1,6 +1,6 @@
 repos:
   - repo: https://github.com/pycqa/flake8
-    rev: '6.1.0'  # Use the latest stable version
+    rev: '7.2.0'  # Use the latest stable version
     hooks:
       - id: flake8
         additional_dependencies: []
@@ -13,7 +13,7 @@ repos:
           args: ["./src"]
 
   - repo: https://github.com/gitleaks/gitleaks
-    rev: v8.24.2
+    rev: v8.24.3
     hooks:
       - id: gitleaks
 

docs/questions-part2.md

@@ -10,5 +10,37 @@
 ## Q2.1
 Solution is to add a `rule` section to add condition to trigger the pipeline. It's what is implemented for the `docker-build` job. Another option is to use an `only` section to trigger the pipeline only if the change is made in a specific branch. It's what is implemented for the `pages` job.
 
+## Q2.2
+
+### Example 1 - 3.6 Encrypt Data on End-User Devices
+
+**description**
+Sensible data is everywhere. It is also on the end user's device. It is primordial to keep it secure.
+
+**mitigation**
+There is multiple ways to secure data. CIS suggests the following : Windows BitLocker®, Apple FileVault®, Linux® dm-crypt.
+
+### Example 2 -  4.3 Configure Automatic Session Locking on Enterprise Assets
+
+**description**
+A logged in computer doesn't check permanantly for the user's identity. A user could by mistake leave his computer open and logged in, give way for anyone ill-intentionned with physical access to use the computer with it's permissions.
+
+**mitigation**
+Forcing an auto-logout after a few minutes.
+
+### Example 3 - 5.2 Use Unique Passwords
+
+**description**
+If a user uses the same password everywhere, it only needs one to get compromised and everything is equally compromised.
+
+**mitigation**
+Usage of unique passwords and for users use 2FA at least.
+
+### Example 4 & 5 with implementation
+
+Unfortunately, due to the amount of work we both had, from work and from school, we didn't have enough time to do those last two points.
+We did the rest (except for optionals) though.
+
 ## Q2.3
+
 We can use a pre-commit that runs the linter before committing. This ensures that the code is linted before it is committed, which can help catch errors and improve code quality. However, this approach can be time-consuming and may require additional setup.