DevSecOps Guidelines Refinement (OWASP#94)

* Rename 2-3-4-Miss-Configuration-Check.md to 2-3-4-Misconfiguration-Check.md

Spellcheck

* Update README.md

* Update README.md

* Add files via upload

* Delete current-version/2-Process/2-4-Operation directory

* Delete current-version/2-Process/2-2-Code directory

* Delete current-version/2-Process/2-2-Develop/2-2-1-Pre-commit directory

* Add files via upload

* Delete current-version/2-Process/2-2-Develop/New Text Document.txt

* Add files via upload

* Add files via upload

* Add files via upload

* Delete current-version/2-Process/2-2-Develop/New Text Document.txt

* Delete current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/New Text Document.txt

* Delete current-version/2-Process/2-3-Build/2-3-1-Dynamic-Application-Security-Testing.md

* Delete current-version/2-Process/2-3-Build/2-3-2-Mobile-Application-Security-Test.md

* Delete current-version/2-Process/2-3-Build/2-3-3-API-Security.md

* Delete current-version/2-Process/2-3-Build/2-3-4-Misconfiguration-Check.md

* Update 2-2-1-1-Pre-commit.md

* Update 2-2-1-2-Secrets-Management.md

* Update 2-2-1-1-Pre-commit.md

* Update 2-2-1-2-Secrets-Management.md

* Create TBD

* Create TBD

* Update 2-2-1-1-Pre-commit.md

* Update 2-2-1-1-Pre-commit.md

* Create 2-3-5-Security-Gates

Author: Doctor2Strange

current-version/2-Process/2-2-Code/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md

@@ -0,0 +1,28 @@
+## Pre-commit
+
+The Pre-commit phase is important because it can prevent security issues before they are submitted to a central (Git) repository.
+
+Making sure that there are no secrets in the code, and that the code follows certain guidelines (According to the Linter rules) will result in a higher quality code.
+
+In the following, we take a look into different types of pre-commit actions that are as follows:
+1. Secrets Management
+2. Linting Code
+
+**Pre-commit** is a git feature that can be leveraged as part of the **shift-left security** approach where the developers are empowered to view the issues in the source code earlier in the SDLC process. When the developer runs a git-commit command to commit the code into their local repository, **pre-commit hook** check can be integrated with a security scanning tool executed to look for code quality issues, hard-coded secrets, insecure code, vulnerable dependencies/opensource libraries, etc..
+
+It is to be noted that pre-commit hooks are at the developer's local repository level and not the remote repository commonly used by all the developers working on the same project/application. In such cases when it's required to prevent security issues before they are submitted to a remote/central (Git) repository **pre-push hook** or **git-push** checks can be configured. Refer: https://git-scm.com/docs/git-push
+
+Another alternative approach to scan the source code for security issues (such as hardcoded-secrets, insecure code and vulnerable dependencies/opensource libraries) is the use of **SAST/SCA IDE plugins**. This works together with the IDEs used by developers while they write the code. Whereas, git-commit and git-push actions are used after the code is written by the developer. It is necessary to discern these distinct use-cases in order to implement the proper security controls at various levels based on the requirement.
+
+The following image can give you a better view of what the pre-commit means and why we must consider it. 
+
+![Pre Commit](/current-version/assets/images/pre-commit.png)
+
+## Tools:
+
++ [Pre-Commit](https://pre-commit.com/) - A framework for managing and maintaining multi-language pre-commit hooks.
+
+
+### References
+
++ [Wikipedia - Lint (software)](https://en.wikipedia.org/wiki/Lint_(software))

current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md

@@ -34,7 +34,7 @@ note that when a credential is leaked, it is already compromised and should be i
 ![Pre Commit](/current-version/assets/images/pre-commit.png)
 
 
-Well, the best location is the **pre-commit** location, This ensure that before a secret actually enters your code base, it is intercepted, and the developer or to committer gets a message. Another location is the build server or the **build** process. The build server retrieves source code, which is already committed and then it can analyze the source code where it contains new secrets or when it contains known secrets that the secrets are actually validated or audited.
+Well, the best location is the **pre-commit** location, This ensure that before a secret actually enters your code base, it is intercepted, and the developer or to committer gets a message. Using **SAST IDE plugins** comes in handy while trying to fix such issues where the IDE warnings can be found as soon as the developer writes an insecure code with security misconfigurations.  Another location is the build server or the **build** process. The build server retrieves source code, which is already committed and then it can analyze the source code where it contains new secrets or when it contains known secrets that the secrets are actually validated or audited.
 
 ---
 Here are some helpful tools to automatically scan repositories for sensitive information.