fix links

docs/CI-CD/dev-sec-ops/README.md

@@ -13,9 +13,9 @@ By embracing shift-left mentality, DevSecOps encourages organizations to bridge
 This section covers different tools, frameworks and resources allowing introduction of DevSecOps best practices to your project at early stages of development.
 Topics covered:
 
-1. [Credential Scanning](./secret-management/credential_scanning.md) - automatically inspecting a project to ensure that no secrets are included in the project's source code.
-1. [Secrets Rotation](./secret-management/secrets_rotation.md) - automated process by which the secret, used by the application, is refreshed and replaced by a new secret.
-1. [Static Code Analysis](./secret-management/static-code-analysis.md) - analyze source code or compiled versions of code to help find security flaws.
+1. [Credential Scanning](./secrets-management/credential_scanning.md) - automatically inspecting a project to ensure that no secrets are included in the project's source code.
+1. [Secrets Rotation](./secrets-management/secrets_rotation.md) - automated process by which the secret, used by the application, is refreshed and replaced by a new secret.
+1. [Static Code Analysis](./secrets-management/static-code-analysis.md) - analyze source code or compiled versions of code to help find security flaws.
 1. [Penetration Testing](./penetration-testing.md) - a simulated attack against your application to check for exploitable vulnerabilities.
 1. [Container Dependencies Scanning](./dependency-and-container-scanning.md) - search for vulnerabilities in container operating systems, language packages and application dependencies.
 1. [Evaluation of Open Source Libraries](./evaluate-open-source-software.md) - make it harder to apply open source supply chain attacks by evaluating the libraries you use.

docs/CI-CD/dev-sec-ops/secrets-management/README.md

@@ -31,7 +31,7 @@ the Azure CLI to do the same is a useful time-saving utility. See [az webapp con
 
 It's best practice to maintain separate secrets configurations for each environment that you run. e.g. dev, test, prod, local etc
 
-The [secrets-per-branch recipe](../gitops/secret-management/azure-devops-secret-management-per-branch.md) describes a simple way to manage separate secrets configurations for each environment.
+The [secrets-per-branch recipe](../../gitops/secret-management/azure-devops-secret-management-per-branch.md) describes a simple way to manage separate secrets configurations for each environment.
 
 > Note: even if the secret was only pushed to a feature branch and never merged, it's still a part of the git history. Follow [these instructions](https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository) to remove any sensitive data and/or regenerate any keys and other sensitive information added to the repo. If a key or secret made it into the code base, rotate the key/secret so that it's no longer active
 

docs/engineering-fundamentals-checklist.md

@@ -10,7 +10,7 @@ This checklist helps to ensure that our projects meet our Engineering Fundamenta
 - [ ] Commit history is consistent and commit messages are informative (what, why).
 - [ ] Consistent branch naming conventions.
 - [ ] Clear documentation of repository structure.
-- [ ] Secrets are not part of the commit history or made public. (see [Credential scanning](ci-cd/dev-sec-ops/secrets-management/credential_scanning.md))
+- [ ] Secrets are not part of the commit history or made public. (see [Credential scanning](./CI-CD/dev-sec-ops/secrets-management/credential_scanning.md))
 - [ ] Public repositories follow the [OSS guidelines](source-control/README.md#creating-a-new-repository), see `Required files in default branch for public repositories`.
 
 More details on [source control](source-control/README.md)
@@ -35,7 +35,7 @@ More details on [automated testing](automated-testing/README.md)
 - [ ] Project uses CD to manage deployments to a replica environment before PRs are merged.
 - [ ] Main branch is always shippable.
 
-More details on [continuous integration](ci-cd/continuous-integration.md) and [continuous delivery](ci-cd/continuous-delivery.md)
+More details on [continuous integration](./CI-CD/continuous-integration.md) and [continuous delivery](./CI-CD/continuous-delivery.md)
 
 ## Security
 

docs/the-first-week-of-an-ise-project.md

@@ -34,13 +34,13 @@ The purpose of this document is to:
   - Agree on how to separate unit tests from integration, load and smoke tests
   - Design the first test cases
 - [ ] [Decide on branch naming](source-control/naming-branches.md)
-- [ ] [Discuss security needs and verify that secrets are kept out of source control](ci-cd/dev-sec-ops/secrets-management/)
+- [ ] [Discuss security needs and verify that secrets are kept out of source control](./CI-CD/dev-sec-ops/secrets-management/README.md)
 
 ## Day 2
 
 - [ ] [Set up Source Control](source-control/README.md)
   - Agree on [best practices for commits](source-control/git-guidance/README.md#commit-best-practices)
-- [ ] [Set up basic Continuous Integration with linters and automated tests](ci-cd/continuous-integration.md)
+- [ ] [Set up basic Continuous Integration with linters and automated tests](./CI-CD/continuous-integration.md)
 - [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/basics/ceremonies.md#stand-up)
   - Discuss purpose, goals, participants and facilitation guidance
   - Discuss timing, and how to run an efficient stand-up
@@ -55,7 +55,7 @@ The purpose of this document is to:
 
 ## Day 4
 
-- [ ] [Set up Continuous Deployment](ci-cd/continuous-delivery.md)
+- [ ] [Set up Continuous Deployment](./CI-CD/continuous-delivery.md)
   - Determine what environments are appropriate for this solution
   - For each environment discuss purpose, when deployment should trigger, pre-deployment approvers, sing-off for promotion.
 - [ ] [Decide on a versioning strategy](source-control/component-versioning.md)