Merge branch 'feat/Q2.2'

feat: update pre-commit hooks and answered questions

See merge request Klagarge/mse2425-grp09!16

.gitlab-ci.yml

@@ -6,11 +6,9 @@ default:
   image: $DOCKER_IMAGE_TEST
 
 stages:
-  - build-docker-test
-  - build-docker-app
+  - build-docker
   - lint
   - test
-  - dast
 
 .setup_env: &setup_env
   before_script:
@@ -59,7 +57,7 @@ pages:
 # This job runs only when Dockerfile changes
 docker-build-test:
   image: docker:latest
-  stage: build-docker-test
+  stage: build-docker
   services:
     - docker:dind
   script:
@@ -76,7 +74,7 @@ docker-build-test:
 
 docker-build-app:
   image: docker:latest
-  stage: build-docker-app
+  stage: build-docker
   services:
     - docker:dind
   script:
@@ -88,7 +86,7 @@ include:
   - template: Jobs/SAST.gitlab-ci.yml
 
 dast:
-  stage: dast
+  stage: test
   image: ghcr.io/zaproxy/zaproxy:stable
   services:
     - name: $DOCKER_IMAGE_APP
@@ -97,3 +95,11 @@ dast:
     - echo "Waiting for the app to start on http://app:5000"
     - timeout 60 bash -c 'until curl -s http://app:5000; do echo "Waiting..."; sleep 3; done'
     - zap-full-scan.py -t http://app:5000 -I
+
+gitleaks:
+  stage: test
+  image:
+    name: zricethezav/gitleaks:latest
+    entrypoint: [""]
+  script:
+      - gitleaks dir -v --redact=75 .

.pre-commit-config.yaml

@@ -1,7 +1,23 @@
 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: []
         args: [--config=tox.ini]  # Use the same config as in CI
+  
+  - repo: https://github.com/pypa/pip-audit
+    rev: v2.9.0
+    hooks:
+      -   id: pip-audit
+          args: ["./src"]
+
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.24.3
+    hooks:
+      - id: gitleaks
+
+ci:
+  # Leave pip-audit to only run locally and not in CI
+  # pre-commit.ci does not allow network calls
+  skip: [pip-audit]

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.

docs/questions-part4.md

@@ -5,3 +5,22 @@
 - **Q4.1**: Often secrets are committed in a repository. Different research tools exist and help to detect this kind of dangerous forgotten credentials. Integrate a check in your pipeline for these kinds of problems. Have a look at <https://github.com/zricethezav/gitleaks>. What kind of leaked secrets can you find in the git repo? Did the tool not find something that it should have found? Why? What possibilities exist to prevent this kind of leakage?
 - **Q4.2**: Try to find any possible problems in our used libraries (e.g. flask). The `pyproject.toml` describes all the additional libraries used by the application. You can use a dependency scanning (have a look here: <https://docs.gitlab.com/ee/user/application_security/dependency_scanning/>) to see if all imported libraries are safe. Do you find any problems? Integrate the scanning in your pipeline.
 - **Q4.3 (optional)**: API Fuzzing (and other kinds of DAST) is described at this page: <https://docs.gitlab.com/ee/user/application_security/api_fuzzing/>. Choose one of the different description possibilities for your *calculator* API. Integrate it in your pipeline.
+
+
+# Answers - Part 4
+## Q4.1
+GitLeaks can find strings like API keys, passwords, and other sensitive information that might be accidentally committed to a repository. This tool can only recognize them if they look like sensitive information.
+
+The scan of the git repository didn't detect the previous flask key because it was not in the format that GitLeaks recognizes.
+
+Usually, the best practice is to use environment variables to store sensitive information. This way, the information is not exposed in the code.
+
+## Q4.2
+The Dependency scanning tool from GitLab linked by the teacher in the exercise cannot be used as it is limited to Gitlab Ultimate. I am looking into using an open-source solution
+
+After using three different scanning tools, no known vulnerabilities were found.
+
+Tools used :
+- pyscan
+- safety
+- pip-audit